Thank you all for your contribution and time. It sure gave me a lot to think of.
thanks, Arye. On Mon, Jun 12, 2017 at 6:44 PM, Phil Smith <p...@voltage.com> wrote: > 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 > ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN