This latest version of ICSF provides support for the newest IBM System z hardware, the zEnterprise 196. It takes advantage of new capabilities in both the CPACF and the Crypto Express3 and provides additional enhancements, not specific to the hardware platform.
z196 Support (MSA-4 instructions)
The Message Security Assist instructions were introduced with the CPACF hardware on the z890/z990 and have been enhanced with each new machine. These assembler instructions are available directly to your application programs. In addition, ICSF provides access to each via its own APIs. While there is some additional overhead in invoking these instructions via the APIs, using the APIs provides portability.
On the z196, there are new Message Security Assist instructions (MSA-4) as well as new capabilities for existing MSA instructions. These instructions are related to new options and techniques in cipher block chaining. With the simplest mode of encryption (electronic code book), each block of data is encrypted independently, however this is not considered secure. Consider that if 8 bytes of blanks are encrypted, as long as the same key is used, those 8 bytes will encrypt to the same ciphertext no matter where in the message they occur. With cipher block chaining, the output from one crypto operation will impact the next crypto operation in a message. So 8 bytes of blanks will encrypt differently each time it is processed, depending on what has been encrypted before it.
The new instructions include Cipher Message with CFB or KMF, Cipher Message with Counter or KMCTR and Cipher Message with OFB or KMO. (CFB stands for Cipher Feedback Mode and OFB is Output Feedback Mode.)
Cipher block chaining was implemented within ICSF in prior versions of z/OS, but with HCR7780 on the z196, ICSF will invoke the new instructions, providing better performance for those operations.
Existing instructions, like the Cipher Message (KM) and Cipher Message with Chaining (KMC) instructions, have been enhanced to add support for XTS (XEX TCB with Ciphertext Stealing), which was approved by NIST in 2009. XEX stands for XOR-Encrypt-XOR and TCB means Tweakable Codebook mode encryption. Simply put, these are new techniques for cipher block chaining.
The hash instructions, Compute Intermediate Message Digest (KIMD) and Compute Last Message Digest (KLMD) have been enhanced to support GHASH which is part of the NSA Suite B crypto functions.
New functionality in the Crypto Express3
The Crypto Express3, which was introduced on the z10 in the fall of 2009, is the only cryptographic PCI card supported on the zEnterprise 196 machine.
When installed on a z196, the CEX3 coprocessor (CEX3C) adds Elliptic Curve support for the Digital Signature Algorithm (ECDSA) for APIs that previously supported RSA operations (Key Generate, Key Token Build, Key Token Change, as well as the APIs which read and write those tokens in the PKDS). While the previous version of ICSF (HCR7770) provided Elliptic Curve support in software as part of the PKCS #11 Callable Services, with HCR7780, ICSF provides Elliptic Curve crytptography on the CEX3C hardware on a z196 via the CSNDDSG (Digital Signature Generate) and CSNDDSV (Digital Signature Verify) APIs.
To support the new Elliptic Curve keys (specifically the private key in the public/private key pair), there is a new 32-byte ECC master key stored in the CEX3C hardware. The ICSF panels have been updated to support the generation of checksums for this new master key and for the key entry process. The ECC master key is only required if you expect to generate and store ECDSA private keys in the PKDS. The ASYM-MK is now called the RSA-MK, since it is now used to specifically protect RSA keys.
Similar to the Cipher Block chaining support that was added for clear keys on the CPACF, the secure symmetric key APIs, CSNBSYD (Symmetric Key Decipher) and CSNBSYE (Symmetric Key Encipher) on the CEX3C have been updated to support the same chaining options. This support is also available on the CEX3C when installed in a z10 machine.
The Crypto Express3 also now supports Concurrent Driver Upgrade (CDU) and Concurrent Patch Apply (CPA), which means that new cryptographic functions can be added to upgrade CCA, segment 3 on the card without taking the CEX3 offline.
ANSI X9.8 Enhancements
ANSI X9.8 is a standard for PIN (ATM) processing. It has been updated for new requirements to prevent attacks that can be made against PIN blocks. (PIN blocks are blocks of data that include information about the PIN as well as the PIN itself, but in an encrypted format.) ANSI X9.8 provides for a number of supported formats for these PIN blocks, and the new standard prohibits the translation of PIN blocks between some formats as well as translation to non-standard formats. It also prohibits the translation of PIN blocks that contain the PAN or Personal Account Number.
HCR7780 provides a new enhanced PIN security mode on the CEX3C to implement the restrictions required by ANSI X9.8. This support is available on both the z10 and z196 machines.
ANSI X9.24 Enhancements
ANSI X9.24 covers the management of key material in financial services, such as point of sales (POS) transactions and automatic teller machine (ATM) transactions. This standard has been updated to prevent some specific attacks against key bundling or wrapping of keys under other keys. These key values are bundled with other token data and encrypted using triple DES or AES encryption with cipher block chaining mode. The updated standard is required for TR-31 audits and to meet key bundling requirements in the recently published PCI Hardware Security Module (PCI HSM) standard.
The IBM Common Cryptographic Architecture (CCA) has been updated to support this new requirement for wrapping of keys and the CCA now supports both Original format wrapped keys and this new Enhanced format. All of the APIs which were used to wrap keys or manage wrapped keys have been updated to support the new Enhanced format; however the new format requires a CEX3C. Enhanced format is supported only on the z196 machines.
If the CKDS, where these Enhanced format keys are stored, is shared with an older version of ICSF, then it is imperative that the toleration APAR (OA33320) be installed on those older systems. First of all, the toleration APAR will allow the older system to read and ignore those Enhanced format records when processing the file sequentially. In addition, without the APAR applied, an API could inadvertently reference an enhanced format key and the older version of ICSF would use that key but without the proper wrapping or unwrapping, leading to unpredictable results including erroneous data but with clean return codes. Although the older version of ICSF won't be able to use the new Enhanced format, installation of the toleration APAR will allow ICSF to recognize those keys and not use the Enhanced format, while continuing to read and use the Original format keys. Note that the toleration APAR also provides support for the new ECDSA keys in the PKDS.
There is a new ICSF initialization option, DEFAULTWRAP, to specify which method (Original or Enhanced) will be the default.
HMAC (via APAR)
HCR7780 will support, via APAR (OA33260) in 1Q 2011, the new Keyed-Hash Message Authentication Code (or HMAC) as specified in FIPS-198. This support is specific to the CEX3C on a z196. The key management APIs will be enhanced to support the new CCA keys required by HMAC.
The symmetric keys used with the HMAC APIs are variable in length. This means that the format of the CKDS must change. HCR7780 will support both the current fixed record length CKDS or the new variable length CKDS, however, the variable length CKDS will not be supported on older versions of ICSF. This means that if the CKDS is shared with systems running older (pre-HCR7780) versions of ICSF, you must continue to use the fixed length CKDS until all systems that will share the CKDS have been updated to HCR7780. At that point, the CKDS can be converted to the new format using the conversion utility, CSFCNV2, provided with HCR7780.
Enhanced logging for PCI Audit requirements
The PCI Data Security Standard has driven a number of enhancements in recent versions of ICSF in terms of logging of security events. HCR7780 continues that process. SMF record Type 82 (x’52’), the ‘ICSF Record’, has been modified to include additional information in the header and self-defining section of the record. These fields include:
- RACF Userid
- RACF Connect Group
- Certificate Distinguished Name for the Issuer and Subject
- Job name, date and time
- Terminal name
- Security label
- User defined identification field
CKDS Constraint Relief
HCR7780 provides a significant enhancement in CKDS constraint relief which will enable continued growth in the number of symmetric keys that can be managed by z/OS and ICSF.
Historically, the size of the CKDS has been documented as having two limitations. First, the maximum size of a VSAM data set is 4 GB. Since the CKDS is a standard VSAM KSDS, it is subject to this limitation. The CKDS is read by ICSF at initialization (and whenever a refresh is done) into a z/OS data space so secondly, the size of the CKDS is limited to the maximum data space that you can allocate in your environment.
In reality, however, the maximum size of the CKDS is much smaller because ICSF must read that data set into its own private storage before it can build the data space. And in fact, as part of the process of building the data space it actually creates multiple copies, so the size is limited by the region available to ICSF.
With HCR7780, the way the CKDS is processed has been changed significantly. Instead of creating a data space to hold the CKDS, the records are moved above the bar, providing significantly more room for keys in memory. The ICSF Systems Programmer’s Guide, SA22-7520-15, contains additional information on planning for and sizing the CKDS (as well as sizing the PKDS and TKDS).
IBM recommends that customers migrate to HCR7780 to support very large CKDS’ and to support HMAC keys which require a variable length CKDS.
64-bit APIs
Each new version of ICSF has supported additional APIs in AMODE(64). With HCR7780 all ICSF Callable Services support AMODE(64).
TKE 7.0
HCR7780 provides support for the new TKE 7.0 LIC (FC #0860) which is required with the zEnterprise z196. Earlier versions of the TKE cannot be used to manage keys on the z196, but TKE 7.0 can be used to manage keys on the z890, z990, z9 EC and BC and z10 EC and BC.
The new TKE 7.0 LIC requires a new TKE Workstation (FC #0841) which comes with the new 4765 PCIe Cryptographic Coprocessor. The new hardware platform does not include serial ports, so if you plan to use smart cards, the smart card readers must be FC #0885 which attach via a USB port. Along with new smart card readers, there are new smart cards available (FC #0888) which were previously announced with TKE 6.0 (in announcement letter 109-678). The new cards support longer keys for better security and improved performance. Previous generation smart cards can still be read in the new readers for purposes of backing up CA smart cards or copying TKE smart cards, however they cannot be used for any other TKE operations.
If you are using User Profiles instead of smart cards to secure access to your TKE, the profiles now provide support for stronger passwords.
The new hardware platform also includes USB ports which replace the floppy drive and DVD for storing key material.
With the Elliptic Curve support on the CEX3C and the new Elliptic Curve master key that protects those ECC private keys, the TKE 7.0 will also support loading the ECC-MK. TKE 7.0 does not support creating and loading of operational ECC keys from the TKE, but it does add support for the ANSI X9.24 key wrapping that is available in HCR7780. It can support either the Original or Enhanced format key wrapping required for TR-31 and PCI audits.
TKE 7.0 enhances the migration wizard that was first available with TKE 6.0. That version of the migration wizard provided the ability to capture configuration data from existing secure cards and saving that information into a file, which could then be used to populate a new or replacement secure card being added to a system, or a secure card on another system. With TKE 7.0 not only can configuration data be captured, but also master keys from the current crypto cards and those master keys can then be installed on new cards or other systems.
Obviously, the master keys that are extracted from the secure card and stored in a file for transport must be protected. To provide this protection, there are additional smart card types (Migration CA or MCA, Injection Authority or IA and Key Part Holder or KPH) which are used to limit who can extract and load to the secure cards.
Although the TKE captures a significant amount of logging for operations, prior to TKE 7.0, reviewing that data required access to the physical TKE. With TKE 7.0 we now provide an Audit Offload Utility that can be used to unload the security log to an ASCII file on a DVD or USB file.
In addition, there is a new TKE Audit Record Upload Configuration Utility that will let you configure your TKE to automatically (or on demand) transfer audit logs from the TKE to ICSF, where they will be written to the SMF as Type 82, Subtype 29 records. This addresses a common requirement from PCI auditors for a single log for audit purposes.
