PMFJI here, but wouldn't it be nearly as good a design to store the original clear key (not encrypted) in the PKDS from a secure ICSF workstation, where the clear key is entered into PKDS only by a highly authorized security administrator, and then to have the application use the ICSF clear key API functions, passing the LABEL of the clear key to be "wrapped" and then used for encryption/decryption as needed?
In this scenario the clear key is not, I believe, ever unprotected once it is entered into the PKDS, since the only application references to it are via the PKDS label. This does reduce the CPU benefit of protected keys somewhat by introducing the ICSF API overhead (which is substantial based on the testing I have done, but nowhere near CEX overhead) into the application, but I think it does provide at least some security for the clear key without the expense of CEX hardware. Peter -----Original Message----- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Greg Boyd Sent: Monday, July 09, 2012 4:07 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Secure Encryption Keys vs Protected Keys Effectively, you need both ICSF and a CEX3 to take advantage of Protected Keys. As was pointed out in another append, you can use the PCKMO instruction to wrap a key. That is, you would take a clear key and wrap it, creating a protected key. And as was also pointed out in that post, I'm not sure why you would do that. Once you bring the key, in the clear, into storage, it could be viewed by an attacker. So you would have to make sure the system is secured (i.e. no other apps or users accessing the system) while you're using the PCKMO to wrap it. And even then, you would have to be sure to use that wrapped key right away. There is no point in saving a copy of the wrapped key because there is no guarantee that the wrapping key won't have changed before you use it again. If the LPAR is deactivated and activated then the wrapping key will change and your wrapped key is no longer usable. So the value of protected key is to leverage the security of the CEX3 (for storing your application key as a secure key) with the performance of the CPACF. and responding to John Gilmore's comments, I say that the performance numbers are 'ivory tower' because few customers will ever obtain those metrics. For example, the SSL tests are intended to measure the performance of the handshake. I believe the payload in that example was 1 byte of data. That's not a very realistic exercise, but it does effectively demonstrate the value of the CEX card on the SSL handshake. So the data is valuable and useful. In the report you can see the expected throughput given AES vs TDES or the various blocksizes. And you can see the relative impact of secure key vs clear key vs protected key. But you must temper your expectations. Crypto has a cost and it can be significant, but I would also suggest that the application design can have a significant impact on your performance expectations as well. -- This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail and delete the message and any attachments from your system. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
