This new version of ICSF provides support for the latest hardware announcement (zEC12). In addition, there are enhancements to the IBM Common Cryptographic Architecture (CCA) which can be exploited with this version of ICSF. Finally, there are some enhancements that aren’t specifically tied to the hardware, but improve performance and usability.
These enhancements include:
- Enterprise PKCS #11 (EP11 Mode) HSM
- Derived Unique Key Per Transaction (DUKPT) for MAC and Data keys
- Ciphertext Translate API
- KDS Improvements for PKDS and TKDS
- PKDS/TKDS Constraint Relief
- KDS Administration support for PKDS and TKDS
- Random Number Generator Enhancements
- FIPS compliant RNG
- Cache (for Performance)
- FIPS On Demand
- Wrapping Keys with Stronger Keys
- KGUP Enhancements
- TKE 7.2
- Crypto Express4S support
- EP11 Mode support
- New DES operational key types
- AES CIPHER key attribute
- Creation of corresponding key types
- Support for four smart card readers
Enterprise PKCS #11 (EP11) Mode HSM
The new Crypto Express4S card is the newest hardware security module available on System z. It provides the same tamper resistant technology as was available on the Crypto Express2 and Crypto Express3, but now also provides hardware security for cryptographic tokens as described by the PKCS #11 architecture. You can still configure your crypto card as either a coprocessor or an accelerator, but now you have the option of configuring the card in an Enterprise PKCS #11 mode to support just the PKCS #11 APIs.
Previous versions of ICSF supported the PKCS #11 architecture, but only with clear keys. Working with the Crypto Express4S, ICSF can now provide hardware security for the cryptographic objects used by PKCS #11 applications. In addition to updating all the PKCS #11 APIs to support secure keys, ICSF now supports a fifth master key, the P11-MK, for protecting PKCS #11 key material. The P11-MK is different from other master keys in that there are only registers for the current and new P11 master key. There is no ‘old’ master key register for the P11-MK.
Configuring your Crypto Express4S in EP11 mode requires TKE V7.2 because this P11-MK can only be loaded via the TKE.
Derived Unique Key Per Transaction (DUKPT) for MAC and Data Keys
Previous versions of ICSF supported generating unique keys per transaction for PIN (ATM) keys. DUKPT is a key management technique that provides the ability to derive a unique key for individual transactions, from a fixed key. This provides unique security for each transaction, such that if the key for a particular transaction is compromised, that does not compromise the key for the next transaction. With HCR77A0 you can now derive unique keys for MAC and Data Keys as well as for PIN keys.
Ciphertext Translate provides the ability to securely re-encrypt data from one key to another. Input to the API would be data encrypted under one key and output will be the same data, but encrypted under a different key. Without the Ciphertext Translate2 API, if data needs to be re-encrypted, it must be decrypted and the data returned to the calling application, which would then invoke the encryption API using the second key. This new API, CSNBCTT2, allows the data to be re-encrypted entirely inside the secure crypto module, without having to return the clear text back to the caller. The Ciphertext Translate2 API also introduces several new key types (CIPHERXI, CIPHERXL, CIPHERXO) which provide granularity in terms of a key being used to decrypt the ciphertext being translated, or encrypt the new ciphertext, or both. It also extends the AES CIPHER key type with the new C-LATE key usage flag.
KDS Improvements for PKDS and TKDS
The previous version of ICSF, HCR7790, introduced a number of enhancements for managing the Cryptographic Key Data Set (CKDS) for symmetric keys. These included performance enhancements including removing constraints on the size of the keystores as well as operational enhancements for changing master keys and refreshing the key repositories. These enhancements were generic and with HCR77A0 have been extended to the Public Key Data Set (PKDS) where public/private keys and Trusted Block Key Tokens are store and to the Token Key Data Set (TKDS) where PKCS #11 objects and key material is stored.
The performance enhancements are completely transparent to applications but provide for bigger keystores (more keys in the repository) as well as performance improvements in terms of making changes to records in the keystores, especially when the keystore is shared between systems.
The operational enhancements in HCR7790 were labeled KDS Administration and provided the ability to coordinate a master key change or a refresh of the CKDS across all members of a plex sharing that CKDS. Beginning with HCR7790, you would load a new master key (either the DES-MK, the AES-MK or both) into the crypto cards on each member of the plex, but then you could drive the master key change from a single system in the plex. That driving system would enqueue on the CKDS, to prevent updates, and then perform the reencipher before switching to the new master key. The driving system would then notify all other members of the plex sharing the CKDS to switch to the new master key and new key repository and finally release the enqueue. Similarly, if you updated keys in the CKDS (either added new keys, or modified existing keys) you could tell all the systems in the plex to pick up those changes via one command from one system. The original driving system would refresh the CKDS data space and notify all other members of the plex sharing that CKDS to refresh their data spaces as well.
With HCR77A0 that generic support has been extended to the asymmetric master keys (RSA-MK and ECC-MK) and their keystore, the Public Key Data Set (PKDS), as well as to the new EP11 master key (P11-MK) and it’s keystore, the Token Key Data Set (TKDS). With this support, you would load the master keys on the crypto cards for each member of the plex, but then you could initiate the master key change from a single system and have the master key change process coordinated across all the members of the plex sharing the PKDS and/or TKDS. You can also coordinate a refresh of those key repositories across the plex, from a single system.
Random Number Generator Enhancements
There are new standards associated with the generation of random numbers (see NIST Special Publication 800-90/90A). The Crypto Express4S now supports methods that are compliant with the new standards and ICSF can use either the new compliant function or the old random number generator. The new RNG function generates a string of random numbers which are stored into a cache and each caller can request as many bytes as it needs. The old random number generator would simply generate strings of the requested length.
Using this cache function for random numbers provides a significant performance boost for RNG operations. When ICSF is started it will create and fill two caches of random numbers. One cache will contain random numbers generated using FIPS compliant facilities, and the second cache will contain random numbers generated using either non-FIPS compliant or FIPS compliant facilities depending on the resources available.
All random number generation APIs will retrieve numbers from the cache, and ICSF will decide when to create and fill another buffer. Each cache is initially 128K in size, but it is treated as two 64K buffers. While one buffer is being used to provide random numbers, the other can be repopulated. If ICSF determines that the 128K cache is too small to service the request, it can dynamically increase the size of the cache. This is completely under ICSF’s control.
FIPS on Demand
Achieving FIPS compliance requires that a subsystem (such as System SSL) or application always use FIPS compliant modules and routines. And FIPS compliant modules must perform certain self-tests during initialization to verify that they are operating correctly. These are called ‘known-answer’ tests, where the module will perform an operation on the hardware and check the results to verify that the expected results were received. If the known-answer tests fail, there is a problem with the module and it can not be used when FIPS compliance is required.
With prior versions of ICSF, these known answer tests were only performed when FIPSMODE(YES) or FIPSMODE(COMPAT) was specified in the ICSF start-up options. When FIPSMODE(NO) was specified, other FIPS compliant routines could not rely on ICSF functionality.
With HCR77A0, ICSF will always perform these known-answer tests, and set a flag indicating that ICSF does have FIPS compliant hardware and routines available. Products such as System SSL, which require FIPS compliant routines can then query the flag and use the FIPS support via ICSF. If the FIPS On Demand flag is not set, System SSL will use it’s own software routines to meet the FIPS requirement.
Wrapping Keys with strong keys
Newer standards such as ANSI X9.24 and PCI-HSM require that keys cannot be wrapped with a key weaker than itself. (Wrapping a key means encrypting it using another key. You might wrap a key that you want to share with a partner.) Historically, the ICSF APIs allowed you to perform the wrapping operation without any restrictions on key lengths. The APIs would allow you to wrap a TDES key (24 bytes) with a DES key (8 bytes), but this would not be considered strong security.
Beginning with HCR77A0 you can now enforce wrapping of keys only with stronger keys. This check is implemented inside the crypto card using an Access Control Point (ACP) which is like a SAF check in the hardware, giving you the ability to set a switch that will perform a check on whether the key being wrapped and the wrapping key are of equal or greater length. By default the ACP is disabled and no checking is performed, so key wrapping works as it always has and there are no restrictions on key wrapping. However, you can enable the ACP to prevent the wrapping of a key by a shorter key, or, for migration purposes, you can allow the wrapping, but provide a return code/reason code to the calling application indicating that the key was wrapped but without the proper key strength. It is then up to the application to handle that return code/reason code and generate the appropriate console or output messages.
Enabling the Access Control Point require a TKE running TKE 7.2 LIC.
The Key Generation Utility Program (KGUP) has been enhanced to support all symmetric key types, including the new variable length key tokens. It also supports a limited set of key usage attributes.
Another enhancement to KGUP is support for more ‘corresponding’ keys (or complimentary keys that can be used from another system). For example, you might create an exporter key encrypting key on host A. On Host B you would need a corresponding importer key encrypting key, with the same value. KGUP on Host A can create the exporter key encrypting key as well as the corresponding importer key encrypting key that can be carried to Host B.
The CSFKEYS data set, used by KGUP can now be variable length. KGUP also now enforces the NODUPLICATES Security Policy.
TKE 7.2 LIC is the latest version of the TKE application. It provides support for the new Crypto Express4S card as well as several usability enhancements. If you have a zEC12 with a CEX4S installed and you want to use a TKE, the TKE requirements depend on how you are using the CEX4S. If you are running HCR7790 or lower with compatibility APARs, then the card is treated as a CEX3C and you can manage those cards with TKE 7.0 or 7.1. If you are running HCR77A0 and thus the card is recognized as a CEX4S and fully exploitable, then you must manage that card with TKE V7.2. The TKE 7.2 LIC must run on the TKE 7 hardware (FC #0841) which was introduced along with the z196 and includes a 4765 in the workstation. TKE V7.2 can also be used to manage Crypto Express Adapters on a z196, z114, z10 EC or z10 BC. If your zEC12 only has CEX3 adapters installed, you do not require TKE 7.2, only TKE 7.0 or higher.
A TKE, running TKE V7.2, with at least two smart card readers is required when the Crypto Express4S is configured in EP11 mode.
As long as your Crypto Express4S is running in compatibility mode, that is, you are running HCR7770, HCR7780 or HCR7790 with the appropriate APARs which tell ICSF to treat the CEX4S as a CEX3, then you can manage those cards using TKE V7.0 or higher on your zEC12. Note: If you have a TKE 5.x or TKE 6.0 on your current CEC, you cannot upgrade that workstation to a TKE 7.x. The TKE 7.x workstation and local crypto adapters are different from the workstations and local crypto adapters that were supported for TKE 5.x and TKE 6.0.
EP11 Mode Support
EP11 Mode requires that a new master key, P11-MK, be loaded. This master key can only be loaded via the TKE and TKE V7.2. The ICSF panels do not support loading the P11-MK.
Support for four smart card readers
When the TKE is ordered, the smart card support is an optional feature that provides two smart card readers and 20 smart cards (FC #0885). If you elected to use smart cards with your TKE, previous versions of the TKE only supported two smart card readers. With the new EP11 mode, it is conceivable that significantly more signatures may be required. To facilitate management of these signature keys, TKE V7.2 can support up to four smart card readers. So with TKE 7.2 you can order two smart card reader features giving you up to four smart card readers and 40 smart cards.
As with previous versions of the TKE, FC #0884 is for additional smart cards and each feature includes 10 smart cards.
If you are planning on implementing EP11 Mode you should consider adding the additional smart card readers and ordering additional smart cards.
New DES operational key types
As mentioned above, the Ciphertext Translate function introduces several new key types, and TKE 7.2 provides support for all of these new keys.
CIPHERXL can be used to both encrypt and decrypt data being processed by the CipherText Translate API, but this key type cannot be used by other ICSF APIs. CIPHREXI keys can only be used to decrypt data that is being passed to the CipherText Translate API.
CIPHERXO keys can only be used to re-encrpyt the data that will be returned from the API.
DUKPT for Data and MAC keys
As described above, HCR77A0 now supports the generation of Derived Unique Keys per Transaction for Data and MAC keys as well as for PIN keys. TKE V7.2 provides support for generating and managing these DUKPT keys from the TKE workstation.
Creation of corresponding key types
TKE 7.2 provides support for the same corresponding key types that KGUP supports in HCR77A0, as described above in the ‘KGUP Enhancements’ section.
ICSF, HCR77A0 provides exploitation support for the Crypto Express4S on your zEC12. In addition, it provides performance and operational enhancements for your z196, z114, z10 EC and BC. You can download this new FMID from the z/OS Downloads website (http://www.ibm.com/systems/z/os/zos/downloads/) and install with SMP/E. As always, be sure to check the latest PSP buckets for recommended service for the HCR77A0 FMID.