z/OS Cryptographic Services ICSF Administrator's Guide
Previous topic | Next topic | Contents | Index | Contact z/OS | Library | PDF


Common Cryptographic Architecture Key Distribution

z/OS Cryptographic Services ICSF Administrator's Guide
SA22-7521-17

ICSF provides protection for keys when the keys are sent outside your system. You must generate complementary keys for key distribution. A complementary pair of keys has these characteristics:

  • The keys have the same clear key value.
  • The key types are different but complementary.
  • Each key usually exists on a different system.

Complementary keys apply only to DES keys. AES keys can be distributed to other systems using RSA key pairs.

Complementary keys are these types:

  • Importer key-encrypting key and exporter key-encrypting key (transport keys)
  • PIN generation key and PIN verification key
  • Input PIN-encrypting key and output PIN-encrypting key
  • MAC generation key and MAC verification key
  • Data-encrypting key and data-translation key (Restriction: Data-translation keys are only supported on the IBM eServer zSeries 900).
  • Input key translate and output key translate keys

When protected data is sent between intermediate systems, these keys exist as complementary keys:

  • Data-encrypting key and data-translation key (Restriction: Data-translation keys are only supported on the IBM eServer zSeries 900).
  • Data-translation key and data-translation key (Restriction: Data-translation keys are only supported on the IBM eServer zSeries 900).

For more information about this situation, see Protection of Data.

The same data-encrypting key can also exist on two different systems so that both systems can encipher and decipher the data.

You can use ICSF to protect keys that are distributed across networks. You distribute keys across a network for some of these reasons:

  • When you send encrypted data to another system, you send the data-encrypting key with the data or before it.
  • When you share complementary keys with another system.

Transport keys protect keys being sent to another system. When a key leaves your system, an exporter key-encrypting key encrypts the key. When another system receives the key, the key is still encrypted under the same key-encrypting key, but the key-encrypting key is now considered an importer key-encrypting key. The exporter key-encrypting key at the sending system and the importer key-encrypting key at the receiving system must have the same clear value. For two systems to exchange keys, they must establish pairs of transport keys.

In Figure 7 System A wants to send an output PIN-encrypting key to System B.

To send the key, System A and System B must establish a pair of transport keys between them. System A has an exporter key-encrypting key called Exporter ATOB, which has the same key value as the importer key-encrypting key called Importer ATOB at System B. This pair of transport keys is unidirectional, because they are used only for distributing keys from System A to System B.

When System A generates the input PIN-encrypting key, the system also creates a complementary output PIN-encrypting key. System A enciphers the input PIN-encrypting key under System A's master key and stores the input PIN-encrypting key in the CKDS. It encrypts the complementary output PIN-encrypting key under the Exporter ATOB key so it can send the output PIN-encrypting key to System B. System B decrypts the output PIN-encrypting key using the Importer ATOB key, and encrypts the output PIN-encrypting key under System B's master key.

For the systems to send keys in both directions, they must establish two pairs of transport keys at each site, as in Figure 8.

To send keys from System A to System B, use the key generator utility program (KGUP) to establish an importer and exporter complementary key pair. You establish an exporter key, Exporter ATOB key, on System A and establish the complementary importer key, Importer ATOB key, on System B. Then when System A sends a key to System B, System A sends the key in exportable form encrypted under Exporter ATOB key. When System B receives the key, System B considers the key in importable form encrypted under Importer ATOB key.

To send keys from System B to System A, use KGUP to establish an importer and exporter complementary key pair. You establish an exporter key, Exporter BTOA key, on System B and the complementary importer key, Importer BTOA key, on System A. When System B sends a key to System A, System B sends the key in exportable form encrypted under Exporter BTOA key. When System A receives the key, System A considers the key in importable form encrypted under Importer BTOA key.

KGUP can create a pair of complementary keys, one key in operational form, and its complement in exportable form. You can also use KGUP to receive keys that are in importable form. When you want KGUP to create a key value in exportable form or import a key value in importable form, you specify the transport key that encrypts the key value. For more information about using KGUP for key distribution, see Managing Cryptographic Keys Using the Key Generator Utility Program.

You can also use one of two callable services to reencipher a key from operational form into exportable form. Both the key export callable service and the data key export callable service reencipher a key from encryption under the master key to encryption under an exporter key-encrypting key.

You can call the key import callable service to convert a key from importable form to operational form. The key import callable service reenciphers a key from encryption under an importer key-encrypting key to encryption under the system's master key.

With interlinked computer networks, sensitive data passes through multiple nodes before reaching its final destination. The originator and the receiver do not share a common key. Data-translation keys are shared between the originator and an intermediate system, between two intermediate systems, and between an intermediate system and the receiver system. As the data is passed along between these systems, they must reencipher it under the different data-translation keys without it ever appearing in the clear. Each system can call the ciphertext translate callable service to do this function. For a description of sending data between intermediate systems, see Protection of Data.

Go to the previous page Go to the next page




Copyright IBM Corporation 1990, 2014