CPACF operation (protected key)

These are details for Central Processor Assist for Cryptographic Functions (CPACF) usage by the host library.

At system power-on, the CPACF generates a new Key Encryption Key (KEK, kek-t) for wrapping translated keys.

Figure 1 illustrates the CPACF layer as it relates to the security access API and cryptographic engine. The CPACF exploitation layer examines commands received by the security server to see if they can be redirected to the CPACF. If so, this layer makes preparations (including translating secure keys to protected keys), and then call the CPACF directly. If all preparations and the CPACF operations are successful, the results are returned as a normal return through the security server. For any errors, the command is redirected back through the security server to the normal path, using the allocated CEX*C for the thread making the call.

Clear key or No key: For operations that do not use keys (such as hash algorithms) or operations that use keys that are not encrypted under the card master key, (called clear keys), no translation is necessary and the CPACF is used immediately. However, the generation of clear keys requires an available CEX*C feature.

Protected key: The device driver and the other layers are used for protected key support, for translating keys. This relationship is similar to the 'directory server' relationship: a translation layer invisible to the customer. After translation the 'translated-key' is stored in an invisible runtime cache so that the next use of the key can avoid the translation step. For protected key usage, a CEX*C feature must be available and allocated for use by the thread.

CPACF service actions and running applications: The CPACF is an independent hardware unit, like the CEX*C itself, and can be independently configured available or unavailable while a Linux instance is running by service technicians performing service actions. If the CPACF is cycled it will generate a new wrapping key for translated keys, invalidating all of the keys in the CCA library key translation cache. Therefore, it is never advisable to attempt such a service action while there are system instances with applications running that use the CPACF.

If such an action is undertaken, applications should be stopped and restarted so that the libcsulcca.so is unloaded from memory and reloaded. This will cause the key cache to be cycled. A more complete measure would be to reboot system images. If these precautions are disregarded and a CPACF service action is undertaken as described, application crashes may ensue with a SIGSEGV error. This could occur due to translated keys wrapped under outdated CPACF wrapping keys being used.

A normal system-wide power cycle will cause the CPACF to generate a new wrapping key by design, however, this action also of course cycles all of the hosted system LPARs and VM system images so there is no problem; translated keys are not cached in permanent storage.