There are several things intertwined here.
* CPACF is the "crypto on the chip" - z Systems instructions that do AES et al. * CEX is the z HSM. * ICSF is, of course, the z/OS service that talks to both (though you can do CPACF operations directly as well). With just CPACF, you're forced to use what's called Clear Key operation: keys are stored (somewhere, somehow-perhaps in CKDS), are fetched, and are passed to CPACF to do operations. With CEX in the mix, you add two more options: Secure Key and Protected Key. Secure Key means that keys are generated by the CEX, wrapped (encrypted) using keys known only to the CEX, and then passed to z/OS, which stores them (usually in CKDS). When an operation is performed, that wrapped key and the data are passed to the CEX, which unwraps the key, does the operation, and returns the result. Very secure, if relatively slow. Protected Key means that keys are generated by the CEX, wrapped, and stored in CKDS, like Secure Key. BUT when an operation is needed, an ICSF call takes that wrapped key and passes it to the CEX, where it is unwrapped, rewrapped using an ephemeral key generated just for the current IPL, and that key is returned. That ephemeral key is also passed to the firmware, so it's available to CPACF. Then the actual operation is performed by passing the rewrapped key: CPACF unwraps it using that ephemeral key, does the operation, returns the result. And ICSF remembers that it's done this, so the next operation using that key doesn't talk to the HSM at all. This gets you almost all of the performance and pretty well all of the security of Secure Key (arguably the firmware is slightly less secure than the tamper-resistant HSM, but the memory used in the firmware to hold that key is protected-it's apparently not even visible in HMC dumps). So your customer can switch to using Protected Key, at least in theory. How hard this is will depend on how keys are generated and managed now, as well as whether they're using ICSF or 'raw' CPACF now, as well as whether they're up for reprotecting all of their existing data with the new key. Does this help? -- ...phsiii Phil Smith III Senior Architect & Product Manager, Mainframe & Enterprise Distinguished Technologist HPE Data Security phs...@hpe.com<mailto:phs...@hpe.com> T 703-476-4511 M 703-568-6662 Hewlett Packard Enterprise Herndon, VA ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
