Yep. By using ICSF plus CEX, and using protected key.. you get more of the performance characteristics of CPACF but retain the more secure nature of secure key.
Yes the exposure is less.. but it will always be suspect. Ultimately, the protected key is dependent on the "source" key material being "secure" or "not secure"... I don't see a category for "sort of secure" <VBG>. And yet.. less exposure is always a better idea. In the case of encrypting things like PINs .. I don't think securing under protected key without the original key material resting in ICSF under CEX MK is a good idea. (dang.. I think I fell into a "not logic" sentence) Rob Schramm Senior Systems Consultant Imperium Group On Mon, Jul 9, 2012 at 1:38 PM, David Stokes <sto...@interchip.de> wrote: > If I understand correctly what you are asking, that key comes from your > program, which is why it is not an ultimately secure way of doing things. > Although if you are holding the protected key in storage for a > communication session it does reduce the exposure, of course. There's a > little document I found > > TechDocID: WP100647 > www.ibm.com/support/techdocs > > which says (amongst other things) re CPACF protected key > > Alternatively, if no CEX3C is available, an application could use a clear > key as the source for a protected key without using ICSF. In this case, > the application is responsible for creating or loading a clear key value > and then using the new PCKMO instruction (new on z10 GA3 - Nov. 2009 or > later microcode) to wrap the key under the appropriate wrapping key. > > Since the wrapping key is unique to each LPAR, a protected key cannot be > shared with another LPAR. Either the original secure key or the clear key > value, not the protected key, would be shared or stored. The underlying > secure key or clear key would need to be retrieved and wrapped with the > wrapping key within each LPAR. > > David Stokes > INTERCHIP AG > Munich > > > -----Ursprüngliche Nachricht----- > Von: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] Im > Auftrag von Rob Schramm > Gesendet: Montag, 9. Juli 2012 19:07 > An: IBM-MAIN@LISTSERV.UA.EDU > Betreff: Re: Secure Encryption Keys vs Protected Keys > > Not that key. The key that will be stored under the "wrapping" key. > > Rob Schramm > Senior Systems Consultant > Imperium Group > > > > On Mon, Jul 9, 2012 at 12:38 PM, David Stokes <sto...@interchip.de> wrote: > > > Well, to quote from POP (for one PCKMO option) (should be Perform > > Cryptographic Key Management Operation, btw) > > > > The 8-byte cryptographic key, K, in byte offsets 0-7 of he parameter > > block is encrypted using the DEA wrapping key. (See the section > > "Protection of Crypto- graphic Key" on page 7-339 for the encryption > > algo- > > rithm.) The result is placed back in byte offsets 0-7 of he parameter > > block. The contents of the DEA wrap- ping-key verification-pattern > > register are placed in byte offsets 8-31 of the parameter block. > > > > So going to 7-339 it says things like > > > > Each time a clear reset is performed, a new set of wrapping keys and > > their associated verification pat- terns are generated. The contents > > of the two wrap- ping-key registers are kept internal to the model so > > that no program, including the operating system, can directly observe > > their clear value. > > > > I.e, they're just generated in the hardware. > > > > Apparently. > > > > (I'm reading this stuff for the first time, out of curiosity mostly. > > It usually takes about ten times nowadays before true enlightenment > dawns). > > > > David Stokes > > INTERCHIP AG > > Munich > > > > > > > > -----Ursprüngliche Nachricht----- > > Von: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] > > Im Auftrag von Rob Schramm > > Gesendet: Montag, 9. Juli 2012 18:13 > > An: IBM-MAIN@LISTSERV.UA.EDU > > Betreff: Re: Secure Encryption Keys vs Protected Keys > > > > How is the key generated? > > > > Rob Schramm > > Senior Systems Consultant > > Imperium Group > > > > > > > > On Mon, Jul 9, 2012 at 12:07 PM, David Stokes <sto...@interchip.de> > wrote: > > > > > Well, you can encrypt a protected key with PCKMO (Perform > > > cryptographic management operation) instruction, as appears to be > > > done in some of the white paper tests, so I'm not convinced CEX is > absolutely required. > > > However, I see little sense, as I said before, in doing such a > > > thing. It would somewhat void the point of having protected (i.e. > > > secure) keys in > > the > > > first place. > > > > > > I didn't feel the point important enough to comment on before. > > > > > > -----Ursprüngliche Nachricht----- > > > Von: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] > > > Im Auftrag von Tom Ambros > > > Gesendet: Montag, 9. Juli 2012 16:22 > > > An: IBM-MAIN@LISTSERV.UA.EDU > > > Betreff: Re: Secure Encryption Keys vs Protected Keys > > > > > > Phil Smith wrote: > > > > > > "Yes, Protected Key requires ICSF and a CEX." > > > > > > Should that not read "Yes, Secure Key requires ICSF and a CEX."? > > > > > > Blatant plagiarism follows from my copy of the z196 Tech Guide, > > > Section > > > 6.2.2 'CPACF Protected key': > > > > > > "The zEnterprise CPCs support the protected key implementation. > > > Since PCIXCC deployment, secure keys are processed on the PCI-X and > > > PCIe cards, requiring an asynchronous operation to move the data and > > > keys from the general purpose CP to the crypto cards. Clear keys > > > process faster than secure keys because the process is done > > > synchronously on the CPACF. Protected keys blend the security of > > > Crypto > > > Express3 > > > coprocessors (CEX3C) and the performance characteristics of the > > > CPACF, running closer to the speed of clear keys. > > > > > > An enhancement to CPACF facilitates the continued privacy of > > cryptographic > > > key material > > > when used for data encryption. In Crypto Express3 coprocessors, a > > > secure key is encrypted under a master key, whereas a protected key > > > is encrypted under a wrapping key that is unique to each LPAR. After > > > the wrapping key is unique to each LPAR, a protected key cannot be > > > shared with another LPAR. CPACF, using key wrapping, ensures that > > > key material is not visible to applications or operating systems > > > during encryption > > operations. > > > > > > CPACF code generates the wrapping key and stores it in the protected > > > area of hardware system area (HSA). The wrapping key is accessible > > > only by firmware. It cannot be accessed by operating systems or > > > applications. DES/T-DES and AES algorithms were implemented in CPACF > > > code with support of hardware assist functions. Two variations of > > > wrapping key are generated, one for DES/T-DES keys and another for > > > AES keys." > > > > > > Note that CPACF generates the wrapping key and the use of the term > > > 'protected key' in this context. Thus my confusion, I am not > > > entirely sure that the CEX hardware is required in this case. I see > > > the distinction that is drawn between 'secure key' and 'protected > > > key' and I believe it is significant. > > > > > > > > > Thomas Ambros > > > Operating Systems and Connectivity Engineering > > > 518-436-6433 > > > > > > This communication may contain privileged and/or confidential > > information. > > > It is intended solely for the use of the addressee. If you are not > > > the intended recipient, you are strictly prohibited from disclosing, > > > copying, distributing or using any of this information. If you > > > received this communication in error, please contact the sender > > > immediately and destroy the material in its entirety, whether > > > electronic or hard copy. This communication may contain nonpublic > > > personal information about consumers subject to the restrictions of > > > the Gramm-Leach-Bliley Act. You may not directly or indirectly reuse > > > or redisclose such information for any > > purpose > > > other than to provide the services for which you are receiving the > > > information. > > > > > > 127 Public Square, Cleveland, OH 44114 If you prefer not to receive > > > future e-mail offers for products or > > services > > > from Key > > > send an e-mail to mailto:dnereque...@key.com with 'No Promotional > > > E-mails' in the SUBJECT line. > > > > > > -------------------------------------------------------------------- > > > -- 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 > > > > > > > ---------------------------------------------------------------------- > > 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 > > > > ---------------------------------------------------------------------- > 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 > ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
