IBM eServer zSeries; IBM System z; ICSF; z9-109; z9 BC; z9 EC; z10; z10 BC; z10 EC; zSeries 800; zSeries 890; zSeries 900; zSeries 990; zSeries; z/OS
|Abstract: As announced with z/OS 1.11, and the October 20, 2009 hardware announcements, Cryptographic Support for z/OS V1.9 through z/OS V1.11 became available on November 20, 2009. This web deliverable will support z/OS V1.9 through z/OS V1.11 and provide support for the October 20, 2009 hardware announcement. To obtain this web deliverable, visit http://www.ibm.com/systems/z/os/zos/downloads/.|
|This newest version of ICSF, FMID HCR7770, adds new and enhanced crypto functionality to z/OS:
- Crypto Express3 and Crypto Express3-1P hardware support
- Protected key support
- Elliptical Curve Cryptography (ECC) support
- Extended PKCS #11 support
- Improve product performance and stability
- New Query Algorithm function
Crypto Express3 (CEX3) and Crypto Express3-1P (CEX3-1P) hardware support: This new version of ICSF provides support for the Crypto Express3 and Crypto Express3-1P that were announced on October 20, 2009. These new features provide similar functionality to the CEX2 and CEX2-1P with improved performance, reliability and serviceability.
Protected key support: Protected key is a new capability on the z10 GA3 that relies on a wrapping key to provide additional security over clear keys, but without the performance penalty of secure keys. This new version of ICSF provides support for using a secure key as the source for a protected key.
Elliptical Curve Cryptography (ECC) Support: This version of ICSF adds support to comply with RFC4869 ‘Suite B Cryptographic Suites for IPSEC’ as well as new clear key algorithms: Galois/Counter Mode encryption for AES (GCM), Elliptic Curve Diffie-Hellman key derivation (ECDH), Ellipc Curve Digital Signature Algorithm (ECDSA) and HMAC.
In February 2005, the U.S. National Security Agency defined a set of cryptographic algorithms that are intended to provide an interoperable cryptographic base for unclassified and classified information. These are known as Suite B (not to be confused with Suite A which is an unpublished list of algorithms intended for highly sensitive communication and critical authentication systems). This suite of algorithms is then used by IETF RFCs to support various protocols (such as IPSEC, TLS, SSH, etc.).
The new support in ICSF is designed to comply with NIST requirements to support a FIPS 140-2 mode of operation for IPSEC.
Extended PKCS #11 support: A new software cryptographic engine embedded in ICSF will allow PKCS11 processing even if no cryptographic coprocessors are available. Since the cryptographic coprocessors are optional hardware, ICSF will determine their availability before routing work and if the hardware is not available, use its own internal routines to accomplish the function.
Additional algorithms that are supported with PKCS11 include Digital Signature Algorithm (DSA), Diffie-Hellman (DH), Elliptic Curve, Galois/Counter Mode encryption for AES (AES GCM), Blowfish and RC4.
Improve product performance and stability: A number of changes have been implemented within ICSF to provide better performance and stability:
- Non-cancellable, non-swappable region
- More consistent, simpler routing of ICSF console messages
- Improved software paths and routine
ICSF is being made non-swappable and non-cancelable using standard z/OS conventions. Prior versions of ICSF are non-swappable however this new support is implemented using standard conventions. Current versions of ICSF are cancelable via an operator command. If the operator issues the cancel command multiple times, the address space may be terminated before cleanup can be completed and this can sometimes cause problems to other ICSF started tasks that are sharing the key data sets (CKDS, PKDS, TKDS). By making ICSF non-cancelable, operations will have to issue an explicit command to stop the address space, driving it through normal termination routines.
Making the ICSF started task non-cancelable and non-swappable requires that the ICSF initialization module be added to the Program Properties Table (PPT). To avoid impacting prior versions of ICSF this main module name is being changed from CSFMMAIN (PGM=CSFMMAIN for HCR7751 and earlier) to CSFINIT. Simply adding CSFMMAIN to the PPT, would cause current versions of ICSF to work differently than they do today (i.e. cancel operations would fail).
The CSFINIT entry in the PPT will be automatically generated as part of the install of HCR7770, however existing users of ICSF will need to modify the ICSF started task to use the new initialization module. CSFMMAIN will still exist with HCR7770, however it will simply generate error message CSFM022E explaining that CSFINIT is required and then ICSF will terminate.
Since this version of ICSF can be installed on older versions of z/OS, the migration from CSFMMAIN to CSFINIT will need to be carefully coordinated in shops running multiple versions of z/OS and ICSF. Systems that require earlier versions of ICSF will have to continue to use //CSF EXEC PGM=CSFMMAIN,REGION=0M,TIME=1440 in the started task. However, to use HCR7770, the started task will need to be modified to specify
//CSF EXEC PGM=CSFINIT,REGION=0M,TIME=1440
Installations that are running multiple LPARs with various versions of ICSF across those LPARs, might want to consider using a system variable for the startup program name. For example, the ICSF started task could be modified to specify
//CSF EXEC PGM=&ICSFPROG,REGION=0M,TIME=1440
and the system symbolic ICSFPROG could be set to
SYMDEF(&ICSFPROG=’CSFINIT’) on the HCR7770 systems and
SYMDEF(&ICSFPROG=’CSFMMAIN’) on the earlier systems. No matter whether you change the started task directly to point to the new startup module, or use system symbols, the change will have to be made before HCR7770 can be started. If using system symbols, the system symbol will have to be refreshed before ICSF can be restarted.
Alternatively, the ICSF started task could be moved to a release specific PROCLIB. On the HCR7770 systems the version of ICSF that uses
//CSF EXEC PGM=CSFMINIT,REGION=0M,TIME=1440
would come before the library that contains the JCL with
//CSF EXEC PGM=CSFMMAIN,REGION=0M,TIME=1440. On the pre-HCR7770 systems, the concatenation order would be reversed.
To improve operational efficiency, ICSF is also being simplified to be more consistent in where it sends operational messages. In prior versions of ICSF, messages would be written to the console as well as data sets. Some messages could be read immediately on the console, while other records were written to the CSFLIST DD. Starting with HCR7751, most ICSF messages will be written to the job log. Messages that require operator action (ROUTCDE=1) will display on the operator console, and messages related to system security (ROUTCDE=9) will display on the security console. Some of those messages will be written to the job log as well. Because of this change, the CSFLIST DD is no longer required in the ICSF started task, however if it is not removed, ICSF will simply ignore it.
Instruction pathlengths for invoking the hashing algorithms on the CPACF, via the ICSF APIs have been tightened to provide better performance. Some operations routed to the CEX2 card have also been improved, providing better CPU utilization for those algorithms.
New Query Algorithm Function: ICSF provides a new Query Algorithm API that returns a summary of supported cryptographic algorithms. This API can be used by applications and middleware to programmatically determine how best to satisfy crypto requirements. For example, the middleware program could determine whether its first choice of AES is available via hardware. If hardware support for AES is available, the middleware would invoke the appropriate APIs or instructions to take advantage of that hardware. And if the support is not available via hardware, it could use the TDES hardware support instead.
IBM System z Family
IBM System z Software
Crypto, ICSF, z9-109, z9, z10, z890, z990, z800, z900, z/OS
|Is this your first visit to Techdocs (the Technical Sales Library)?