Lots of good discussion! Pulling some of it together: IBM CPACF hardware is not a feature, it comes standard with your z hardware. That is, if you order a 6-way z13, each of those 6 CPs has a CPACF. However, because of export restrictions, that device is not enabled until you order and install the necessary microcode, FC #3863. If your address is North Korea, don't bother trying to order this FC. IBM can't ship it to you because of export restrictions.
The 'D M=CPU' shows the CPs, it just doesn't mention the CPACF. Think of the CPACF as just some additional real estate on the general purpose engines ... it simply provides additional instructions (see Message Security Assist in the POPs manual), but you can't use those instructions without the microcode feature. Ten years ago, it was not uncommon that customers did not install that microcode. Today, with all the focus on crypto, most customers have it installed ... unless they are in one of the embargoed countries. To check, look at the System Details from the SE and in the lower right corner, look for 'CP Assist for Crypto functions: Installed'. If it says 'Not Installed' call IBM to order the feature code. You don't have to have ICSF active to use the CPACF hardware. You can write assembler code that uses these MSA instructions. However, if ICSF is active, then it provides APIs that will in turn invoke those same instructions. It becomes a question of how the product implements crypto. If it uses assembler code and the MSA instructions, then ICSF does not need to be active. If it invokes the ICSF APIs, then ICSF must be active. System SSL has code that will query the environment and branch to routines that use the native instructions, or the APIs or its own software to perform the needed function. The CPACF device is separate and distinct from the Crypto Express cards, however FC #3863 is a pre-req for the Crypto Express. (Same logic, you can't use encryption technology if you're in an embargoed country.) Note that the CEX cards provide a hardware random number generator (RNG). The CPACF provides a Pseudo Random Number Generator (PRNG). I suspect that the OpenSSH product will use whichever is available, maybe Kirk can confirm? The later versions of ICSF provide some RNG enhancements, specifically a cache of random numbers, instead of making a call to the card every time a random number is needed. And the z13 implements RNGs that conform to the latest NIST standards. As Radoslaw mentioned you can dynamically configure the LPARs to assign Crypto Express cards. (There is no config work to assign the CPACF to the LPAR, if the microcode is installed and the CP is assigned, then the CPACF is available to the LPAR.) In the LPAR Activation Profile, you must assign the CEX cards in the online list and candidate list and assign the Usage Domain (where the LPAR looks for a master key when it needs one). The Control Domain is associated with the use of a TKE. And starting with the z10s this configuration could be done dynamically. (This dynamic configuration support isn't just for crypto, but applies to other hardware resources as well.) Starting with the z10 you could update the LPAR Activation profile, or temporarily add it to the currently active LPAR or both. See the PR/SM Planning Guide for your machine.) Loading the master keys only applies if you have CEX cards installed, and as has been pointed out, can be done from the ICSF panels or from the TKE. I don't recommend using Passphrase Initialization for your production environment. That's a great way to get up and running, but not secure enough for a production environment. If you have master keys installed in your production environment, then those same production master keys will need to be available on the DR machine. Whatever method you used in production, you'll have to use the same method on the DR machine. However, it also depends on the DR environment (cold site, warm site, hot site). As David Jousma pointed out, you can use a TKE to load master keys in advance, but if it's a push-pull you can't load master keys until the CEX hardware is available, and you'll need at least one z/OS LPAR to connect to the TKE. The other alternative is to use a driver z/OS system and stop and restart ICSF, pointing to each domain, to load the appropriate master keys into each Usage Domain on the DR hardware. Cumbersome, but doable. Greg Boyd Mainframe Crypto www.mainframecrypto.com ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
