I'm a little late chiming in and I must confess I don't have as much experience with crypto on z/VSE. z/VSE may have changed, but in the past it has not provided a facility like ICSF which provides the interface to the CEX cards.
Going back to the original post, I suspect that the customer is using locally written assembler code to invoke the crypto instructions on the CPACF to encrypt the data before writing it to disk. How does the customer expect to drive work to the CEX card? Is there a product that they plan on using? z/VSE can use Total Storage devices which can provide encryption, but the encryption is done on the device, not on the CPACF hardware. In this case, the Crypto Express card can be used to protect (encrypt) the symmetric key, using public key APIs, and then that symmetric key is used in the device to encrypt or decrypt the data depending on whether it's a write or read operation. In addition, z/VSE supports the Encryption Facility for z/VSE (a z/VSE implementation of the Encryption Facility for z/OS). It can also provide similar support, using a public key to wrap the symmetric key that is then used to protect the data within the file. As with the TotalStorage hardware, the CEX can perform these public key operations, but the encryption of the data is done elsewhere (not on the card). But to use the CEX card to actually encrypt/decrypt the data a rest, would a) probably not provide acceptable performance and b) require another product to invoke the APIs that would be executed on the cards. So, why is the customer considering installing the CEX card? Is it to provide more security for their data at rest? If so, what product do they expect to use to perform the encryption. Bottom line, the CPACF and CEX are compatible, and in fact you must have the CPACF enabled to use the CEX cards, but using the cards requires software that will leverage the cards. Or is it for SSL operations? The card can provide a significant performance boost for SSL operations and the real benefit is for authenticating the network communication sessions. In this case, these public key operations are done on the CEX card instead of using software routines (MVC, SLL, Multiple instructions, etc.). Along those lines, I want to clarify Todd Arnold's comments: "If you use ICSF as the interface, it automatically selects the most appropriate crypto to use - for example, if you are doing clear-key encryption, it will automatically use CPACF because it knows that will be faster than the CEX ..." Actually, the specific API that you implement in your code, not ICSF, determines which device will perform the work. For example, CSNBSAE is the Symmetric Algorithm Encipher API and is a secure key API. When you invoke that API, ICSF will always route the work to a CEX card (and there better be a card available to service that request or the API will fail). On the other hand, if you invoke CSNBSYE, the Symmetric Key Encipher API, then ICSF will use the assembler instructions on the CPACF to perform that operation. So ICSF is not deciding where the operation is performed, your choice of APIs is. I hope that helps. Greg Boyd Mainframe Crypto www.mainframecrypto.com ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
