KGUP generates keys that are complementary keys. Complementary keys have the same clear key value for corresponding key types. KGUP generates and maintains these types of complementary keys:

• Data-encrypting (DATA) and data-translation (DATAXLAT) keys
• Importer key-encrypting key and exporter key-encrypting key
• Input PIN-encrypting key and output PIN-encrypting key
• MAC generation key and MAC verification key
• PIN generation key and PIN verification key

Restriction: DATAXLAT keys are only supported on the IBM zSeries 900.

When you distribute keys or PINs, your system has one key, and the other system has the complementary key. For example, when your system sends a DATA key to another system, the importer and exporter key-encrypting keys at the systems complement each other. The DATA key is encrypted under an exporter key-encrypting key at your system. The DATA key is decrypted by the complementary importer key-encrypting key at the receiving system.

When KGUP generates a key, the other system involved in the key or PIN exchange needs the complement of the key. When KGUP generates a key, the program also generates a control statement to create the complement of the key. You send the control statement to the other system which uses the statement to create the complementary key.

For example, when you use KGUP to create an input PIN-encrypting key, KGUP also creates a control statement for the complementary output PIN-encrypting key. You send the control statement to another system. The other system uses the control statement to create the output PIN-encrypting key. Then your system can send PIN blocks to the other system.

For some key types you can choose the output key type by specifying the OUTTYPE parameter on a KGUP ADD statement. For example, you can generate a DATA key for inclusion into the CKDS and export a copy of the key as either a DATA key or a DATAXLAT key. If you export the copy of the DATA key as a DATA key, the receiver of the key can use it to decipher data. If you export the copy of the DATA key as a DATAXLAT key, the receiver can use the key only to translate cipher text from one DATAXLAT key to another. The receiver of the DATAXLAT key cannot use the key to actually decipher the data.

KGUP stores the complementary key control statement in a data set. Because some cryptographic systems may not use KGUP control statements, KGUP also stores complementary key information as a record in a different data set. The information is not in the form of a control statement. You process and send the information to a system which creates the complementary key.

When KGUP generates a key, the program also generates information to create the complementary key. This information includes the complementary key value. The value is either a clear key value or encrypted key value. For an encrypted key value, the program encrypts the value under an exporter key. The importer key that complements this exporter key already exists at the other system. The importer key is one key in a complementary transport key pair that your system already established with the other system. The pair would be an importer key on the other system and an exporter key on your system. The other system reenciphers the value from under the importer key to under its master key to generate the complementary key.

Besides generating keys and complementary key information, KGUP imports key values that are sent from other systems. The program can receive a control statement to create a key that is the complement of a key on another system. The key value your KGUP receives may be encrypted under a transport key. The transport key would be one key of a complementary transport key pair that you already established with the other system. The pair would be an exporter key on the other system and an importer key on your system. KGUP reenciphers the complementary key from under the importer key to under the master key and places the key in the CKDS.

For KGUP to send or receive keys in a key exchange with another system, the systems must previously establish a pair of complementary transport keys. For example, KGUP on one system defines the pair and generates the importer key in the clear. KGUP on the other system uses this value to define a pair of keys that are complements of the keys at the original site. For an example of how two ICSF systems establish pairs of complementary transport keys for key exchange, see Scenario of Two ICSF Systems Establishing Initial Transport Keys.

The cryptographic facility exclusive ORs a transport key with a control vector when using the transport key to encipher a key. A transport key exclusive ORed with a control vector is called a transport key variant. ICSF uses the control vector associated with the key type that the transport key will encipher. The control vector ensures that when another site imports the key, the resulting operational key can only be the type that the control vector indicates. For example, the control vector for a PIN verification key ensures that the system that receives the key can import the key only as a PIN verification key.

When KGUP generates a PIN generation key, the program generates a key value to create a PIN verification key. You can specify that the key value be an encrypted key value. When you do this, ICSF exclusive ORs the transport key with the control vector for a PIN verification key to create the transport key variant. Then the cryptographic facility enciphers the PIN verification key under the transport key variant.

To view the specific control vector value that is associated with each type of key to create master key variants and transport key variants, see Appendix B. Control Vector Table.

Transport key variants ensure that the receiving system uses the key as the type of key that the sending system intended. However transport key variants can only be used if both systems recognize transport key variants. You should use transport key variants when exchanging keys with the 4758 PCI Cryptographic Coprocessor. However, systems with some cryptographic products, such as PCF, do not recognize control vectors. When you exchange keys with such a system, a key that you send or receive is enciphered under a transport key rather than a transport key variant. You just specify to KGUP that the transport key should not be exclusive ORed with a control vector.

You can define a pair of complementary transport keys with another system so your system and the other system can exchange keys without control vectors. You use a control statement to indicate to KGUP to produce these keys. Then send the clear value that KGUP produced to the PCF system so the system can generate the corresponding complementary pair of keys. Then you use the transport keys to exchange other keys. Refer to Scenario of an ICSF System and a PCF System Establishing Initial Transport Keys for an example of how to establish pairs of complementary transport keys for key exchange between an ICSF system and a PCF system.

You can also use KGUP to create complementary keys that are used by two different systems. Neither key would be operational on your system so KGUP would not update your CKDS. When KGUP generates the complementary key information, you send it to the two systems that need to share complementary keys.