I just discovered this discussion group, and I thought I'd add a little bit of information to the discussion. I am a lead architect in development of the IBM crypto coprocessors (Crypto Express, etc), and in design of the CCA architecture and its verbs. I also happen to have been deeply involved in design of the "protected key" support.
So here are a few random things that might make it clearer. Many of you have made "educated guesses", many of which are right, but I wanted to simply state the facts from the viewpoint of someone who should hopefully know them. :-) As described elsewhere, use of protected keys DOES require the Crypto Express coprocessor. The key starts as a secure key (wrapped by the CEX master key). The CPACF firmware sends this to the CEX, where it is decrypted using a special instruction that is not available to normal application programs. The resulting cleartext key is sent directly from the CEX to CPACF and can never appear anywhere in the system that application programs or the O/S can ever see it. Thus, it stays in "hardware" in the mainframe. This is what makes it much more secure than anything the application program, O/S, RACF, etc. could do - nothing can get to the cleartext key, even though it is "in the machine". CPACF generates a fresh wrapping key when it starts, and uses that to wrap the cleartext keys that come back from the CEX. Since that wrapping key will change when CPACF starts up next time, the CPACF-wrapped keys are no good for long term use - they have to be re-decrypted and re-wrapped by CPACF the next time the system starts. Once the key has been unwrapped by the CEX and sent back to CPACF, the CEX is no longer involved in the protected key operations. The CPACF-wrapped "protected key" gets sent to the CPACF when you need to use it, and the CPACF unwraps it and performs the desired operation. Thus, the protected key operations are extremely fast, but they are slightly slower than clear key CPACF operations since there is an extra step of unwrapping the key. Obviously, if you encrypt a huge block of data, this extra unwrap operation will not have nearly as much impact as if you encrypt a tiny block, since it's only done once for the block in either case. In regard to "synchronous" vs. "asynchronous"... This is really from the perspective of the host CPU. A synchronous operation is one like any regular CPU instruction (add, move, etc.). The CPU executes a machine instruction, and at the end of that instruction the result is available. For an asynchronous operation, on the other hand, the CPU executes an instruction that sends a request off for execution somewhere else (hence the name "coprocessor"), and that CPU instruction is done when the request has been sent. Some time later, the coprocessor notifies the CPU that the request has been completed and the CPU goes and gets it. This asynchronous method is the way the CEX's work. Requests are posted to queues and the CEX's read from those queues, process the work, and return results to the queue. The choice of using protected key CPACF or the CEX is really one dependent on what your application has to do. The protected key CPACF is VERY fast and really is very secure - the only way an attacker could find the value of your key is to attack your mainframe at the hardware level. Nothing they can do in software or with any utilities or management tools will let them attack it. On the other hand, there are several things that would make you use the CEX instead, and they are important. The first one is that the CEX provides a huge and varied set of functions, while the protected key CPACF can only do simple encryption and MAC operations with the keys. The second one is that the protected key CPACF cannot do any kind of enforced key typing or key usage control. For example, you can't specify a key that can only be used for MAC, or one that can only be used to protect financial PINs, or... CCA on the CEX has a rich set of key management and key typing features that do that. Finally, if you are doing any kind of bank card or payments processing, or some other operations, there are standards that make it mandatory that you use an HSM like the CEX cards. Even though protected key CPACF is very secure, it does not meet the rules stated in those standards. Todd Arnold Senior Technical Staff Member (STSM) IBM Cryptographic Coprocessor Development ([email protected]) ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
