Deploying quantum-safe capabilities
Now that your cryptographic inventory is created (as discussed in Chapter 5, “Creating a cryptographic inventory” on page 71), the preparation and planning can begin for the replacement of weak symmetric keys and public key algorithms. The algorithms and protocols at risk are discussed in “Cryptographic vulnerabilities possible with quantum computers” on page 9.
Adopting and implementing agreed upon quantum-safe standards, algorithms, and protocols in cryptographic systems helps protect against quantum computer and conventional computer attacks.
This chapter includes the following topics:
6.1 Quantum-safe algorithm artifacts
As you transition your cryptographic infrastructure to quantum-safe algorithms, it is important to understand some of the differences in artifact sizes between quantum-safe algorithms and traditional public key cryptography. It also is important to understand the supported quantum-safe algorithm object identifiers.
Quantum-safe algorithm (QSA) keys and signatures are much larger and might require changes in your environment. CCA QSA, RSA, and Elliptic Curve Cryptography (ECC) keys are compared in Table 6-1. The token size does not include other sections (such as private key name). The PKCS #11 key objects and signatures are of comparable size to the CCA key tokens.
Table 6-1 CCA public key token and signature sizes
|
Algorithm
|
Public key token size (bytes)
|
Private key token size (bytes)
|
Signature size (bytes)
|
|
RSA CRT 4096
|
1104
|
2504
|
512
|
|
ECC Edwards 448
|
79
|
323
|
114
|
|
CRYSTALS-Dilithium 6,5 Round 3
|
1984
|
6128
|
3293
|
|
CRYSTALS-Dilithium 8,7 Round 3
|
2624
|
7632
|
4595
|
The supported quantum-safe algorithm object identifiers (OIDs) on IBM z15 and IBM z16 with Crypto Express7S and Crypto Express8S features are listed in Table 6-2.
Table 6-2 Supported quantum-safe algorithm object identifiers
|
Algorithm
|
Algorithm strength/version1
|
Object identifier
|
|
CRYSTALS-Dilithium
|
CRYSTALS-Dilithium 6,5 Round 2
|
1.3.6.1.4.1.2.267.1.6.5
|
|
CRYSTALS-Dilithium 6,5 Round 3
|
1.3.6.1.4.1.2.267.7.6.5
| |
|
CRYSTALS-Dilithium 8,7 Round 2
|
1.3.6.1.4.1.2.267.1.8.7
| |
|
CRYSTALS-Dilithium 8,7 Round 3
|
1.3.6.1.4.1.2.267.7.8.7
| |
|
CRYSTALS-Kyber
|
CRYSTALS-Kyber 1024 Round 2
|
1.3.6.1.4.1.2.267.5.4.4
|
1 Crypto Express7S features support CRYSTALS-Dilithium 6,5 Round 2 only
For more information about the supported quantum-safe OIDs, see ICSF Application Programmer's Guide, SC14-7508.
For more information about each quantum-safe algorithm, see the following web pages:
6.2 Converting your PKDS to KDSRL format
If you plan to store CCA QSA key tokens in your ICSF Public Key Data Set (PKDS), you must be on ICSF FMID HCR77D2 and have a large common record format (KDSRL) PKDS. KDSRL format supports all asymmetric key tokens and metadata. It also allows key usage tracking, if configured. KDSRL format increases the logical record length (LRECL) of the PKDS 3800 to 32756.
ICSF provides a utility to convert a KDSR format PKDS to KDSRL format by using the ICSF panes.
Complete the following steps to convert a PKDS to KDSRL format by using the ICSF panes:
1. On the ICSF Primary menu (see Example 6-1), select option 2, KDS MANAGEMENT and then, press Enter.
Example 6-1 ICSF Primary menu
HCR77D2 -------------- Integrated Cryptographic
System Name: SY1 Crypto Domain: 0
Enter the number of the desired option.
1 COPROCESSOR MGMT - Management of Cryptographic Coprocessors
2 KDS MANAGEMENT - Master key set or change, KDS Processing
3 OPSTAT - Installation options
4 ADMINCNTL - Administrative Control Functions
5 UTILITY - ICSF Utilities
6 PPINIT - Pass Phrase Master Key/KDS Initialization
7 TKE - TKE PKA Direct Key Load
8 KGUP - Key Generator Utility processes
9 UDX MGMT - Management of User Defined Extensions
Licensed Materials - Property of IBM
5650-ZOS Copyright IBM Corp. 1989, 2021.
US Government Users Restricted Rights - Use, duplication or
disclosure restricted by GSA ADP Schedule Contract with IBM Corp.
Press ENTER to go to the selected option.
Press END to exit to the previous menu.
OPTION ===>
2. On the Key Data Set Management pane (see Example 6-2), select option 2, PKDS MANAGEMENT and then, press Enter.
Example 6-2 ICSF key data set management
------------------------ ICSF - Key Data Set Management ------------
Enter the number of the desired option.
1 CKDS MANAGEMENT - Perform Cryptographic Key Data Set (CKDS)
functions including master key management
2 PKDS MANAGEMENT - Perform Public Key Data Set (PKDS)
functions including master key management
3 TKDS MANAGEMENT - Perform PKCS #11 Token Data Set (TKDS)
functions including master key management
4 SET MK - Set master keys
Press ENTER to go to the selected option.
Press END to exit to the previous menu.
3. On the PKDS Management pane (see Example 6-3), select option 6, COORDINATED PKDS CONVERSION and then, press Enter.
Example 6-3 PKDS Management
---------------------------- ICSF - PKDS Management --------------------------
Enter the number of the desired option.
1 PKDS OPERATIONS - Initialize a PKDS, activate a different PKDS,
(Refresh), or update the header of a PKDS and make
it active
2 REENCIPHER PKDS - Reencipher the PKDS
3 CHANGE ASYM MK - Change an asymmetric master key and activate the
reenciphered PKDS
4 COORDINATED PKDS REFRESH - Perform a coordinated PKDS refresh
5 COORDINATED PKDS CHANGE MK - Perform a coordinated PKDS change master key
6 COORDINATED PKDS CONVERSION - Convert the PKDS to KDSR/L record format
7 PKDS KEY CHECK - Check key tokens in the active PKDS for format errors
Press ENTER to go to the selected option.
Press END to exit to the previous menu.
4. On the Coordinated KDS conversion pane (see Example 6-4), enter the new KDS name and then, press Enter.
Example 6-4 Coordinated KDS conversion
---------------------- ICSF - Coordinated KDS conversion -----------------
To perform a coordinated KDS conversion, enter the KDS names below
and optionally select the rename option.
KDS Type ===> PKDS
Active KDS ===> ‘SYS1.PKDS.KDSR’
New KDS ===> ‘SYS1.PKDS.KDSRL’
Rename Active to Archived and New to Active (Y/N) ===> N
Archived KDS ===>
Create a backup of the converted KDS (Y/N) ===> N
Backup KDS ===>
Press ENTER to perform a coordinated KDS conversion.
Press END to exit to the previous menu.
After converting your PKDS to KDSRL format, you can confirm the change by using the D ICSF,KDS command. The output is shown in Example 6-5.
Example 6-5 D ICSF, KDS output
SY1 d icsf,kds
SY1 CSFM668I 14.28.13 ICSF KDS 875
CKDS SYS1.CKDS.KDSR
FORMAT=KDSR COMM LVL=3 SYSPLEX=Y MKVPs=DES AES
DES MKVP date=Unknown
AES MKVP date=Unknown
PKDS SYS1.PKDS.KDSRL
FORMAT=KDSRL COMM LVL=3 SYSPLEX=Y MKVPs=RSA ECC
RSA MKVP date=Unknown
ECC MKVP date=Unknown
TKDS SYS1.TKDS.KDSRL
FORMAT=KDSRL COMM LVL=3 SYSPLEX=Y MKVPs=P11
P11 MKVP date=Unknown
6.3 Ensuring the environment is ready
The examples in the subsequent sections assume that all the necessary hardware and software is installed. Review the information in this section before deploying the quantum-safe capabilities.
The following general prerequisites must be met:
•ICSF FMID HCR77D2 or later is installed with the latest service level
•z/OS 2.5 or later is installed
•Running on IBM z15 or later
•Crypto Express7S or later is installed and configured
•CPACF feature code 3863 is enabled
For the CCA examples, our environment featured the following components:
•z/OS 2.5 installed and running on an IBM z16.
•ICSF FMID HCR77D2 with the latest service level applied.
•The CKDS and PKDS are allocated and in the correct format:
– The CKDS is recommended to be in KDSRL format.
– The PKDS must be in KDSRL format. For more information, see “Converting your PKDS to KDSRL format” on page 99.
•Two Crypto Express8S (CEX8C) were installed and configured as CCA coprocessors (for more information, see IBM z16 Configuration Setup, SG24-8960).
•Feature Code (FC) 3863 was enabled for CPACF use.
•The AES master key was set and active in each CEX8C (CCA coprocessor) and initialized in the CKDS header. The Master Key Verification Pattern must be the same across your environment.
If you are converting ciphertext that is encrypted with secure CCA DES keys, you must have the DES master key set and active in each CEX8C coprocessor and initialized in the CKDS header. The Master Key Verification Pattern must be the same across your environment.
CCA CRYSTALS-Dilithium and CRYSTALS-Kyber key operations require that the ECC master key be set and active in each CEX8C coprocessor and initialized in the PKDS header. The Master Key Verification Pattern must be the same across your environment.
For the PKCS #11 examples, we made the following changes to our environment:
•The TKDS was allocated. A TKDS is not required if session objects are used.
•For secure key operations:
– Two Crypto Express8 (CEX8P) were installed and configured as Enterprise PKCS #11 (EP11) coprocessor.
– The EP11 master key was set and active in each CEX8P and initialized in the TKDS header. The Master Key Verification Pattern must be the same across your environment. A TKE is required to set the EP11 master key.
|
Note: PKCS #11 hybrid key-exchange can be done in hardware only.
|
For more information about allocating ICSF Key Data Sets and entering and activating ICSF master keys, see z/OS ICSF Administrator’s Guide, z/OS, SC14-7506.
For more information about the IBM Z cryptographic stack, see 4.1, “IBM Z cryptographic components overview” on page 48.
6.4 Quantum-safe key generation
This section describes generating cover keys for AES 256, CRYSTALS-Dilithium, and CRYSTALS-Kyber algorithms by using ICSF services.
AES 256, CRYSTALS-Dilithium, and CRYSTALS-Kyber are proven to be resistant to attacks from a powerful quantum computer. They also are ideal candidates when transitioning your application that is identified in your cryptographic inventory.
The PKCS #11 sample assumes that your environment is running with a specified ICSF TKDS. For more information about allocating and initializing a TKDS, see ICSF System’s Programmer’s Guide, SC14-7507.
6.4.1 Generating an AES 256-bit key by using ICSF CCA services
Generating a secure AES 256-bit CIPHER CCA key token can be done by using the Key Token Build2 (CSNBKTB2 and CSNEKTB2) and Key Generate2 (CSNBKGN2 and CSNEKGN2) ICSF services.
To generate a CCA AES 256-bit key, complete the following steps:
1. Build a skeleton token by using CSNBKTB2 with the correct key usage and key management bits specified. Ensure key type CIPHER is specified.
2. Pass the created skeleton token from CSNBKTB2 to CSNBKGN2 and specify the AES and OP rules.
The secure AES 256-bit CCA key token is generated and can be written to the CKDS with the CKDS Key Record Create2 (CSNBKRC2 and CSNEKRC2) service.
For more information about a sample REXX program that showcases steps 1 and 2, see B.1, “CCA AES 256-bit key generation REXX sample” on page 134.
For more information about these services and parameters, see ICSF Application Programmer’s Guide, SC14-7508.
6.4.2 Generating an AES 256-bit key by using ICSF PKCS #11 services
Generating a secure AES 256-bit PKCS #11 key object can be done by using the PKCS #11 Generate Secret Key (CSFPGSK and CSFPGSK6) ICSF service.
To generate a secure PKCS #11 AES 256-bit key, complete the following steps:
1. Initialize a PKCS #11 token by using the PKCS #11 Token Record Create (CSFPTRC and CSFPTRC6) service.
2. Call the CSFPGSK service that passes the token handle that was created in step 1. Specify the CKA_CLASS (with a value of CKO_SECRET_KEY) and CKA_KEY_TYPE (with a value of CKK_AES) object attributes in the attribute list.
For more information about contains a sample REXX program that showcases step 2, see B.2, “PKCS #11 AES 256-bit key generation REXX sample” on page 137.
For more information about key object attributes, see ICSF Writing PKCS #11 Applications guide, SC14-7510.
6.4.3 Generating CRYSTALS-Dilithium key by using ICSF CCA services
Generating a secure CRYSTALS-Dilithium key pair can be done by using the PKA Key Token Build (CSNDPKB and CSNFPKB) and PKA Key Generate (CSNDPKG and CSNFPKG) ICSF services.
To generate a CRYSTALS-Dilithium key pair, complete the following steps:
1. Build a skeleton token by using CSNDPKB passing the ‘QSA-PAIR’ and ‘U-DIGSIG’ rules. In the Key Value Structure (KVS), specify the algorithm ID and algorithm parameters for CRYSTALS-Dilithium.
2. Pass the created skeleton token from CSNDPKB to CSNDPKG and specify the ‘MASTER’ rule.
The secure CRYSTALS-Dilithium key pair is generated and can be written to the PKDS with the PKDS Key Record Create (CSNDKRC and CSNFKRC) service if the PKDS is in KDSRL format. For more information, see 6.2, “Converting your PKDS to KDSRL format” on page 99.
The CRYSTALS-Dilithium public key optionally can be extracted from the private key token by using the PKA Public Key Extract (CSNDPKX and CSNFPKX) service.
For more information about a sample REXX program that showcases steps 1 and 2, see B.3, “CCA CRYSTALS-Dilithium key pair generation REXX sample” on page 139.
For more information about these services and parameters, see ICSF Application Programmer’s Guide, SC14-7508.
6.4.4 Generating CRYSTALS-Dilithium key by using ICSF PKCS #11 services
Generating a secure PKCS #11 CRYSTALS-Dilithium key object can be done by using the PKCS #11 Generate Key Pair (CSFPGKP and CSFPGKP6) ICSF service.
To generate a secure PKCS #11 CRYSTALS-Dilithium key object, complete the following steps:
1. Initialize a PKCS #11 token by using the PKCS #11 Token Record Create (CSFPTRC and CSFPTRC6) service.
2. Call the CSFPGKP service that passes the token handle that was created from step 1. Specify the CKA_IBM_DILITHIUM_MODE object attribute with the DER encoded OID that corresponds to the CRYSTALS-Dilithium strength that is wanted in the public key attribute list.
For more information about a sample REXX program that showcases step 2, see B.4, “PKCS #11 CRYSTALS-Dilithium key pair generation REXX sample” on page 142.
For more information about key object attributes, see ICSF Writing PKCS #11 Applications Guide, SC14-7510.
6.4.5 Generating CRYSTALS-Kyber key by using ICSF CCA services
Generating a secure CRYSTALS-Kyber key pair can be done by using the PKA Key Token Build (CSNDPKB and CSNFPKB) and PKA Key Generate (CSNDPKG and CSNFPKG) ICSF services.
To generate a CRYSTALS-Kyber key pair, complete the following steps:
1. Build a skeleton token by using CSNDPKB passing the QSA-PAIR, U-KEYENC, and U-DATENC rules. In the Key Value Structure (KVS), specify the algorithm ID and algorithm parameter for CRYSTALS-Kyber.
2. Pass the created skeleton token from CSNDPKB to CSNDPKG and specify the MASTER rule.
The secure CRYSTALS-Kyber key pair is generated and can be written to the PKDS with the PKDS Key Record Create (CSNDKRC and CSNFKRC) service if the PKDS is in KDSRL format. For more information, see 1.2: Converting your PKDS to KDSRL format.
The CRYSTALS-Kyber public key optionally can be extracted from the private key token by using the PKA Public Key Extract (CSNDPKX and CSNFPKX) service.
For more information about a sample REXX program that showcases steps 1 and 2, see B.5, “CCA CRYSTALS-Kyber key pair generation REXX sample” on page 144.
For more information about these services and parameters, see ICSF Application Programmer’s Guide, SC14-7508.
6.4.6 Generating CRYSTALS-Kyber key by using ICSF PKCS #11 services
Generating a secure PKCS #11 CRYSTALS-Kyber key object can be done by using the PKCS #11 Generate Key Pair (CSFPGKP and CSFPGKP6) ICSF service.
To generate a secure PKCS #11 CRYSTALS-Kyber key object, complete the following steps:
1. Initialize a PKCS #11 token by using the PKCS #11 Token Record Create (CSFPTRC and CSFPTRC6) service.
2. Call the CSFPGKP service that passes the token handle that was created from step 1. Specify the CKA_IBM_KYBER_MODE object attribute with the DER encoded OID corresponding to the CRYSTALS-KYBER strength that is wanted in the public key attribute list.
For more information about a sample REXX program that showcases step 2, see B.6, “PKCS #11 CRYSTALS-Kyber key pair generation REXX sample” on page 147.
For more information about key object attributes, see ICSF Writing PKCS #11 Applications Guide, SC14-7510.
6.5 Quantum-safe encryption
Data must be encrypted with AES 256-bit keys to ensure its protection from quantum computers running Grover’s algorithm. For more information about the effect Grover’s algorithm has on symmetric key cryptography, see 1.3, “Impact of Shor’s and Grover’s algorithms” on page 7.
The following options are available to protect ciphertext:
•Translate it by decrypting it by using the original key and then, encrypting it with an AES 256-bit key. The clear text is visible only for a short time within the secure cryptographic coprocessor.
•Reencrypt the ciphertext by using an AES 256-bit key without decrypting it first.
•Decrypt it with Symmetric Key Decipher (CSNBSYD or CSNBSYD1 and CSNESYD or CSNESYD1) and reencrypt it with Symmetric Key Encipher (CSNBSYE or CSNBSYE1 and CSNESYE or CSNESYE1). The clear text is visible only for a short time on the host system.
For more information about generating AES 256-bit keys, see 6.4.1, “Generating an AES 256-bit key by using ICSF CCA services” on page 102.
For more information about the use of AES 256-bit keys to translate cipher text from a weaker key (such as DES) to AES 256-bit encryption (option 1 in the previous bulleted list), see 6.4.2, “Generating an AES 256-bit key by using ICSF PKCS #11 services” on page 103.
6.5.1 Translating ciphertext to AES 256-bit encryption by using ICSF CCA services
Translating ciphertext from a weaker algorithm to AES 256-bit can be done by using the Cipher Text Translate2 (CSNBCTT2, CSNBCTT3, CSNECTT2, CSNECTT3) ICSF service.
To translate ciphertext to AES 256-bit encryption, complete the following steps:
1. Generate an AES 256-bit CIPHER key by using the ENCRYPT and C-XLATE key usage bits enabled. For more information, see B.1, “CCA AES 256-bit key generation REXX sample” on page 134.
2. Call the Cipher Text Translate2 service that passes the key that originally encrypted the ciphertext as the key_identifier_in and the new AES 256-bit key as the key_identifier_out.
The ciphertext is decrypted within the secure cryptographic coprocessor and reencrypted with the AES 256-bit key.
For more information about a sample REXX program that showcases step 2, see C.1, “CCA ciphertext translation REXX sample” on page 152.
For more information about these services and parameters, see ICSF Application Programmer’s Guide, SC14-7508.
6.5.2 Translating ciphertext to AES 256-bit encryption by using ICSF PKCS #11 services
Translating ciphertext from a weaker algorithm to AES 256-bit can be done by using the PKCS #11 Secret Key Reencrypt (CSFPSKR and CSFPSKR6) ICSF service.
|
Note: This translate ciphertext service supports secure secret keys only.
|
To translate ciphertext over to AES 256-bit encryption, complete the following steps:
1. Generate an AES 256-bit PKCS #11 key object by using the CKA_IBM_SECURE key attribute set to TRUE. For more information, see B.2, “PKCS #11 AES 256-bit key generation REXX sample” on page 137.
2. Call the PKCS #11 Secret Key Reencrypt service that passes the key handle that originally encrypted the ciphertext as the decrypt_handle and the new AES 256-bit key handle as the encrypt_handle.
The ciphertext is decrypted within the secure cryptographic coprocessor and reencrypted with the AES 256-bit key.
For more information about a sample REXX program that showcases step 2, see C.2, “PKCS #11 ciphertext translation REXX sample” on page 154.
For for more information about these services and parameters, see ICSF Application Programmer’s Guide, SC14-7508.
6.6 Quantum-safe digital signatures
Digital signatures are used to validate the authenticity and integrity of a message. Digital signatures also add nonrepudiation, which provides indisputable proof of origin for the signed data.
Traditional public key cryptography, such as RSA and ECC, are compromised of a sufficiently powerful quantum computer that is running Shor’s algorithm. This process can lead to issues, such as data history manipulation by forging digital signatures. To protect against such issues, it is important to start adopting hybrid signature schemes that combine traditional public key cryptography and quantum-safe algorithms, such as CRYSTALS-Dilithium.
For more information about how organizations can use digital signatures to verify the authenticity of data, see 3.4, “Proof of authorship” on page 42.
This section describes how to digitally sign and verify data by using the CRYSTALS-Dilithium quantum-safe algorithm.
6.6.1 Generating and verifying CRYSTALS-Dilithium digital signature by using ICSF CCA services
To generate and verify a CRYSTALS-Dilithium digital signature, use the Digital Signature Generate (CSNDDSG and CSNFDSG) and Digital Signature Verify (CSNDDSV and CSNFDSV) ICSF services.
To generate a CRYSTALS-Dilithium signature, complete the following steps:
1. Generate a CRYSTALS-Dilithium CCA key token by using the CSNDPKB and CSNDPKG ICSF services. For more information, see 6.4.3, “Generating CRYSTALS-Dilithium key by using ICSF CCA services” on page 103.
2. Call the CSNDDSG service and specify the CRDL-DSA, MESSAGE, and CRDLHASH rules. Pass the CRYSTALS-Dilithium private key token that was generated in step 1.
With a Crypto Express8 CCA coprocessor, the message to be signed can be up to 15000 bytes.
The generated signature is created. The signature size depends on the strength of the specified CRYSTALS-Dilithium key.
To verify a CRYSTALS-Dilithium signature, complete the following steps:
1. Call the PKA Public Key Extract (CSNDPKX and CSNFPKX) service to extract the CRYSTALS-Dilithium public key from the private key token.
2. Call the CSNDDSV service and specify the CRDL-DSA, MESSAGE, and CRDLHASH rules. Pass the CRYSTALS-Dilithium public key token that was extracted in step 1.
With a Crypto Express8 CCA coprocessor, the message to be verified can be up to 15000 bytes.
You receive a 0/0 return/reason code for a successful verification.
For more information about a sample REXX program that showcases a CRYSTALS-Dilithium digital signature generation and verification, see D.1, “CCA CRYSTALS-Dilithium digital signature generation and verification REXX sample” on page 158.
For more information regarding these services and parameters, see ICSF Application Programmer’s Guide, SC14-7508.
6.6.2 Generating and verifying CRYSTALS-Dilithium digital signature by using ICSF PKCS #11 services
To generate and verify a CRYSTALS-Dilithium digital signature, use the PKCS #11 Private Key Sign (CSFPPKS and CSFPPKS6) and PKCS #11 Public Key Verify (CSFPPKV and CSFPPKV6) ICSF services.
To generate a CRYSTALS-Dilithium signature, complete the following steps:
1. Generate a CRYSTALS-Dilithium PKCS #11 key pair by using the CSFPGKP ICSF service. Ensure that the private key attribute list contains CKA_SIGN set to TRUE, and the public key attribute list contains CKA_VERIFY set to TRUE. For more information, see 6.4.4, “Generating CRYSTALS-Dilithium key by using ICSF PKCS #11 services” on page 104.
2. Call the CSFPPKS service and specify the LI2 rule. Pass the CRYSTALS-Dilithium private key handle that was generated in step 1.
3. The generated signature is created. The signature size depends on the strength of the specified CRYSTALS-Dilithium key.
To verify a CRYSTALS-Dilithium signature, perform the following steps call the CSFPPKV service and specify the LI2 rule. Pass the CRYSTALS-Dilithium public key handle. Pass the signature to verify and the original message.
A 0/0 return/reason code is returned for a successful verification.
D.2, “PKCS #11 CRYSTALS-Dilithium digital signature generation and verification REXX sample” on page 161 contains a sample REXX program that showcases a CRYSTALS-Dilithium digital signature generation and verification.
For more information about these services and parameters, see ICSF Application Programmer’s Guide, SC14-7508.
6.6.3 Using digital signatures to protect SMF records
SMF records are an important part of the auditability to the z/OS platform. For example, SMF records can contain important security-related information, such as RACF processing records (SMF record type 80).
It is important to ensure that these records are never tempered with. SMF digital signature provides a cryptographic means to verify the integrity of the records when log streams are used as the recording media.
In this section, we demonstrate how SMF records digital signature is used to sign SMF records and how to transition to quantum-safe algorithms for that purpose.
Configuring SMF digital signature
An SMF digital signature is based on a token and a key (RSA or ECC). The digital signature can be the same for all the records or specific to a log stream.
Step 1: Creating the token and the associated key pair
We created a PKCS#11 token that is called QSAFE.REDBOOK.SMF.SIGN.TOKEN.LS1. Then, we created a key pair that we bound to this certificate (see Example 6-6).
Example 6-6 Creating and binding a PKCS#11 token and a key pair (RSA)
RACDCERT ADDTOKEN(QSAFE.REDBOOK.SMF.SIGN.TOKEN.LS1)
RACDCERT GENCERT ID(STCID) SUBJECTSDN(CN('SMF sign cert')) +
WITHLABEL('SMF sign certificate') SIZE(2048) RSA +
NOTAFTER(DATE(2023/04/18))
RACDCERT BIND(ID(STCID) LABEL('SMF sign certificate') DEFAULT +
TOKEN(QSAFE.REDBOOK.SMF.SIGN.TOKEN.LS1)
Step 2: Configuring SMF for digital signature
Example 6-7 shows an SMFPRMxx parmlib member (truncated), which enables SMF digital signature for a log stream IFASMF.ALLSYS.DATA that stores selected z/OS SMF records. Other SMF records that are directed to the default log stream IFASMF.ALLSYS.DEFAULT do not have SMF digital signature processing enabled.
Example 6-7 SMFPRMxx parmlib member enabling SMF digital signature for SMF log streams
ACTIVE /*ACTIVE SMF RECORDING*/
LISTDSN /* LIST DATA SET STATUS AT IPL*/
NOPROMPT /*DON'T PROMPT THE OPERATOR */
DEFAULTLSNAME(IFASMF.ALLSYS.DEFAULT,COMPRESS(PERMFIX(32M)))
LSNAME(IFASMF.ALLSYS.DATA,TYPE(0,23,30,42,70:79,80:83,99,113),
COMPRESS(PERMFIX(64M))
RECSIGN(HASH(SHA512),SIGNATURE(RSA),
TOKENNAME(QSAFE.REDBOOK.SMF.SIGN.TOKEN.LS1))
)
RECORDING(LOGSTREAM)
…
Note that the log stream IFASMF.ALLSYS.DATA must be defined with a MAXBUFSIZE of 65532.
Step 3: Extracting the data from the log stream
When extracting the SMF records from the log streams, we want to ensure that the SMF digital signature is available for post-processing. For this purpose, the NOSIGSTRIP parameter must be specified (see Example 6-8).
Example 6-8 JCL for SMF records extraction, preserving SMF digital signature
//IFASMFDL EXEC PGM=IFASMFDL,REGION=0M
//OUTDD1 DD DSN=RBOOK.SMF.LOGS,DISP=(NEW,CATLG,DELETE),
// SPACE=(CYL,(100,100),RLSE),
// DCB=(LRECL=32760,RECFM=VBS,BLKSIZE=0)
//SYSPRINT DD SYSOUT=A
//SYSIN DD *
LSNAME(IFASMF.ALLSYS.DATA,OPTIONS(DUMP))
OUTDD(OUTDD1,TYPE(0:255),START(1400),END(2000))
NOSIGSTRIP
DATE(2022096,2022096)
Step 4: Validating the SMF signature
By using the IFASMFDP utility, we can specify the SIGVALIDATE parameter along with the hashing method and the name of the token. The utility validates the records and ensures that they are all signed with the specified token (see Example 6-9).
|
Tip: You do not have write out records to another data set when performing validation, as we show in the example. An alternative is to use a dummy data set, by replacing the DDSMF1 DD statements with DDSMF1 DD DUMMY.
|
Example 6-9 JCL to create SMF records signing validation
//SMF EXEC PGM=IFASMFDP
//DUMPIN DD DISP=SHR,DSN=RBOOK.SMF.LOGS
//DDSMF1 DD DSN=RBOOK.SMF.RACF,
// DISP=(NEW,CATLG,DELETE),
// SPACE=(CYL,(100,100),RLSE),
// DCB=(RECFM=VBS,BLKSIZE=32748,LRECL=32756)
//SYSPRINT DD SYSOUT=A
//SYSIN DD *
SID(SYSA)
INDD(DUMPIN,OPTIONS(DUMP))
OUTDD(DDSMF1,TYPE(30,82))
NOSIGSTRIP
DATE(2022096,2022096)
START(1400) END(1800)
SIGVALIDATE(HASH(SHA512),
TOKENNAME(QSAFE.REDBOOK.SMF.SIGN.TOKEN.LS1))
Sample output from the SMF records signing validation job is shown in Example 6-10.
Example 6-10 SMF records signing validation report
IFA010I SMF DUMP PARAMETERS
IFA010I REPORTOPTS(NOSUBTYPE) -- DEFAULT
IFA010I NOASIGVALIDATE -- DEFAULT
IFA010I SIGVALIDATE(HASH(SHA512),
TOKENNAME(QSAFE.REDBOOK.SMF.SIGN.TOKEN.LS1)) -- SYSIN
IFA010I END(1800) -- SYSIN
IFA010I START(1400) -- SYSIN
IFA010I DATE(2022096,2022096) -- SYSIN
IFA010I NOSIGSTRIP -- SYSIN
IFA010I OUTDD(DDSMF1,TYPE(30,82)) -- SYSIN
IFA010I INDD(DUMPIN,OPTIONS(DUMP)) -- SYSIN
IFA010I SID(SYSA) -- SYSIN
IFA020I DDSMF1 -- RBOOK.SMF.RACF
IFA020I DUMPIN -- RBOOK.SMF.LOGS
SUMMARY ACTIVITY REPORT
START DATE-TIME 04/06/2022-14:00:00 END DATE-TIME 04/06/2022-19:59:58
RECORD RECORDS PERCENT AVG. RECORD MIN. RECORD MAX. RECORD RECORDS
TYPE READ OF TOTAL LENGTH LENGTH LENGTH WRITTEN
2 5,974 4.35 % 347.85 18 356 447
3 1 .00 % 18.00 18 18 1
23 24 .02 % 8,062.00 8,062 8,062 0
30 20,995 15.29 % 1,529.65 480 6,121 3,244
42 5,674 4.13 % 2,473.64 176 32,444 0
70 1,224 .89 % 20,887.45 1,672 32,600 0
71 288 .21 % 2,596.00 2,596 2,596 0
72 13,824 10.06 % 1,791.39 1,324 13,328 0
73 288 .21 % 29,216.00 29,216 29,216 0
74 5,616 4.09 % 10,474.92 308 32,520 0
75 576 .42 % 272.00 272 272 0
77 288 .21 % 585.25 328 832 0
78 576 .42 % 6,428.00 4,056 9,008 0
82 47 .03 % 120.00 120 120 31
99 75,619 55.06 % 2,877.35 419 8,870 0
113 6,336 4.61 % 1,606.00 1,462 1,834 0
TOTAL 137,350 100 % 2,901.58 18 32,600 3,723
NUMBER OF RECORDS IN ERROR 0
RECORD VALIDATION REPORT FOR SYSA
RECORD RECORD VALIDATION VALIDATION START VALIDATION END RECORDS GROUPS INTERVALS
TYPE SUBTYPE FAILURE DATE-TIME DATE-TIME VALIDATED VALIDATED VALIDATED
30 2 N 04/06/2022-14:00:00 04/06/2022-18:00:00 2,620 73 48
30 6 N 04/06/2022-14:00:00 04/06/2022-18:00:00 624 48 48
30 3 N 04/06/2022-14:00:00 04/06/2022-18:00:00 0 0 48
30 4 N 04/06/2022-14:00:00 04/06/2022-18:00:00 0 0 48
30 5 N 04/06/2022-14:00:00 04/06/2022-18:00:00 0 0 48
82 20 N 04/06/2022-14:00:00 04/06/2022-18:00:00 31 31 48
VALIDATION SUCCEEDED
Implementing SMF alternative signatures
As described in “Impact of Shor’s and Grover’s algorithms” on page 7, traditional public key cryptography, such as RSA and ECC, can be compromised by a quantum computer that is running Shor’s algorithm. To maintain a safe way to validate SMF audit data, you can use a function that was introduced with z/OS 2.4 that allows a secondary (or alternative) signature that uses CRYSTALS-Dilithium.
Step 1: Generate the PKCS #11 CRYSTALS-Dilithium key pair
|
Note: As of this writing, SMF alternative signature support is for CRYSTALS-Dilithium 65 Round 2 only.
|
The PKCS #11 CRYSTALS-Dilithium key pair can be clear or secure. For a secure key pair, an Enterprise PKCS #11 coprocessor Crypto Express7S or later must be available with the suitable ICSF minimum service level. The minimum hardware and software levels are listed in Table 4-2 on page 55.
For more information about generating PKCS #11 CRYSTALS-Dilithium key pair services, see 6.4.4, “Generating CRYSTALS-Dilithium key by using ICSF PKCS #11 services” on page 104.
Step 2: Configuring SMF for alternative digital signature
Example 6-11 shows an SMFPRMxx parmlib member (truncated) that enables an SMF digital signature, and alternative digital signature for a log stream that stores z/OS events. The alternative signature is specified in SMFPRMxx by using the ARECSIGN parameter and the RECSIGN parameter. When ARECSIGN is used, RECSIGN also must be specified. The specified TOKENNAME must be the PKCS #11 token that contains the CRYSTALS-Dilithium key object.
Example 6-11 SMFPRMxx parmlib member that enables SMF digital signature for SMF log streams
ACTIVE /*ACTIVE SMF RECORDING*/
LISTDSN /* LIST DATA SET STATUS AT IPL*/
NOPROMPT /*DON'T PROMPT THE OPERATOR */
DEFAULTLSNAME(IFASMF.ALLSYS.DEFAULT,COMPRESS(PERMFIX(32M)))
LSNAME(IFASMF.ALLSYS.DATA,TYPE(0,23,30,42,70:79,80:83,99,113),
COMPRESS(PERMFIX(64M))
RECSIGN(HASH(SHA512),SIGNATURE(RSA),
TOKENNAME(QSAFE.REDBOOK.SMF.SIGN.TOKEN.LS1))
ARECSIGN(HASH(SHA512),SIGNATURE(LI2),
TOKENNAME(QSAFE.REDBOOK.SMF.SIGN.TOKEN.LS2))
)
RECORDING(LOGSTREAM)
Step 3: Extracting the data from the log stream
Although the extraction process did not change, we still need to use the NOSIGSTRIP parameter to preserve the record signatures (see Example 6-12).
Example 6-12 JCL for SMF records extraction, preserving SMF digital signature
//IFASMFDL EXEC PGM=IFASMFDL,REGION=0M
//OUTDD1 DD DSN=RBOOK.SMF.LOGS,DISP=(NEW,CATLG,DELETE),
// SPACE=(CYL,(100,100),RLSE),
// DCB=(LRECL=32760,RECFM=VBS,BLKSIZE=0)
//SYSPRINT DD SYSOUT=A
//SYSIN DD *
LSNAME(IFASMF.ALLSYS.DATA,OPTIONS(DUMP))
OUTDD(OUTDD1,TYPE(0:255),START(1400),END(2000))
NOSIGSTRIP
DATE(2022096,2022096)
Step 4: Validating the SMF signature
Here, we want to specify the SIGVALIDATE and ASIGVALIDATE parameters (see Example 6-13).
Example 6-13 JCL to create SMF records signing validation including alternative signature
//SMF EXEC PGM=IFASMFDP
//DUMPIN DD DISP=SHR,DSN=RBOOK.SMF.LOGS
//DDSMF1 DD DSN=RBOOK.SMF.RACF,
// DISP=(NEW,CATLG,DELETE),
// SPACE=(CYL,(100,100),RLSE),
// DCB=(RECFM=VBS,BLKSIZE=32748,LRECL=32756)
//SYSPRINT DD SYSOUT=A
//SYSIN DD *
SID(SYSA)
INDD(DUMPIN,OPTIONS(DUMP))
OUTDD(DDSMF1,TYPE(30,82))
NOSIGSTRIP
DATE(2022096,2022096)
START(1400) END(1800)
SIGVALIDATE(HASH(SHA512),
TOKENNAME(QSAFE.REDBOOK.SMF.SIGN.TOKEN.LS1))
ASIGVALIDATE(HASH(SHA512),
TOKENNAME(QSAFE.REDBOOK.SMF.SIGN.TOKEN.LS2))
6.7 Quantum-safe hybrid key exchange
Key exchange allows two parties to establish a shared secret by using public key cryptography.
With the introduction of the CRYSTALS-Kyber algorithm, is it now possible to perform a quantum-safe hybrid key exchange scheme that combines the protection of traditional Elliptic Curve Cryptography (ECC) and the quantum-safe CRYSTALS-Kyber algorithm. This hybrid key exchange scheme provides two layers of protection and ensures that all key exchanges are protected from attacks by traditional and quantum computers.
For more information about how organizations can use secure key exchange to protect their sensitive data, see 3.2, “Use case: Sharing keys securely” on page 31.
This section describes how to perform a quantum-safe hybrid key exchange by using CCA and PKCS #11 services.
6.7.1 Performing a hybrid quantum-safe key exchange scheme by using ICSF CCA services
A hybrid quantum-safe key exchange can be performed with the PKA Encrypt (CSNDPKE and CSNFPKE) and EC Diffie-Hellman (CSNDEDH and CSNFEDH) ICSF services.
The following Access Control Points (ACP) must be enabled:
•PKA Encrypt -Allow CRYSTALS-Kyber keys (0083x)
•EC Diffie-Hellman -Allow Hybrid QSA Scheme (035Dx)
Consider the following hybrid quantum-safe key exchange scheme that includes two participants: Alice and Bob are two parties who want securely exchange information. They can be a company and a Business Partner, for example.
Step 1: Alice
1. Alice creates the following keys:
– Kyber-priv-A, Kyber-pub-A: CRYSTALS-Kyber 1024 key pair
– EC-priv-A, EC-pub-A: ECC key pair for key agreement
– Kyber-cert-A, EC-cert-A: authentication forms of Kyber-pub-A and EC-pub-A
2. Alice sends Kyber-cert-A and EC-cert-A to Bob.
Step 2: Bob
1. Bob receives and validates Kyber-cert-A and EC-cert-A
2. Bob creates the following keys:
– AES-ciph-B: AES CIPHER key in a CCA key token
|
Note: AES-ciph-B must be as strong as the derived shared key (for example, AES 256-bit) and allow encrypt and decrypt operations.
|
– EC-priv-B, EC-pub-B: ECC key pair for key agreement
– EC-cert-B: authenticated form of EC-pub-B
– Kyber-pub-A CCA public key token with public key pulled from Kyber-cert-A
3. Bob creates the shared key derivation input by using the CSNDPKE service:
– RANDOM keyword, AES-ciph-B, Kyber-pub-A, AES encryption IV
– Generates a random 32B value: rand-32
– AES-CBC encrypts rand-32 by using key AES-ciph-B and the AES encryption IV returning [AES-ciph-B(rand-32)] in the keyvalue parameter.
– CRYSTALS-Kyber encrypts rand-32 with Kyber-pub-A returning [Kyber-pub-A(rand-32)] in the PKA_enciphered_keyvalue parameter.
4. Bob completes the shared key derivation by using CSNDEDH
Bob calls CSNDEDH by using a derivation keyword and wanted key length, [AES-ciph-B(rand-32)], AES-ciph-B, AES encryption IV, EC-priv-B, EC-cert-A, output skeleton token.
Consider the following points about CSNDEDH:
– Decrypts rand-32 by using the key AES-ciph-B and the AES encryption IV.
– Uses EC-priv-B and EC-cert-A with ECDH to generate the Z value.
– Passes Z and rand-32 to the key derivation function that is indicated by the derivation keyword, rand-32 is the salt or OtherData. The shared key of the requested length is derived.
– Places the shared key in the provided output skeleton token and then, encrypts the key value.
– Returns the final CCA shared key token.
5. Bob stores the shared key
6. Bob sends EC-cert-B, [Kyber-pub-A(rand-32)] to Alice.
Step 3: Alice
1. Alice receives and validates EC-cert-B, [Kyber-pub-A(rand-32)].
2. Alice completes the shared key derivation by using CSNDEDH
Alice calls CSNDEDH with a derivation keyword and the wanted key length, [Kyber-pub-A (rand-32)], Kyber-priv-A, EC-priv-A, EC-cert-B, output skeleton token.
Consider the following points about CSNDEDH:
– Decrypts rand-32 by using Kyber-priv-A.
– Uses EC-priv-A and EC-cert-B with ECDH to generate the Z value.
– Passes Z and rand-32 to the key derivation function that is indicated by the derivation keyword, rand-32 is the salt or OtherData. The shared key of the requested length is derived.
– Places the shared key in the provided output skeleton token and then, encrypts the key value.
– Returns the final CCA shared key token.
3. Alice stores the shared key.
The shared key is now established by Alice and Bob.
Role of CSFNDPKE
The role of the PKA Encrypt (CSNDPKE) service in this scheme is to create the rand-32 derivation input and return rand-32 in the following forms:
•Encrypted by Bob’s AES cipher key, AES-ciph-B
•Encrypted by Alice’s CRYSTALS-Kyber public key, Kyber-pub-A
This process is accomplished in one call to CSNDPKE:
•Inputs:
– RANDOM rule-array keyword
– AES-ciph-B: AES-cipher key for Bob
|
Note: AES-ciph-B must be as strong as the derived shared key.
|
– Kyber-pub-A as PKA_key_identifier: CRYSTALS-Kyber key for Alice
•Outputs:
– keyvalue parameter: [AES-ciph-B(rand-32)]
– PKA_enciphered_keyvalue parameter: [Kyber-pub-A(rand-32)]
Consider the following points:
•Authentication of the public keys that are used in the scheme is the responsibility of the host.
Currently, CRYSTALS-Kyber keys do not participate in PKI processes. The kyber-cert-A certificate for a CRYSTALS-Kyber public key recognizes that certificate formats are needed for the authentication part of a protocol.
For the ECC public keys, the CCA internal PKI can be used for authentication if the trust anchor was installed in the adapter.
•A full protocol must include a Key Check Value that is calculated over the shared key that was created by Bob so that Alice can verify the creation of an agreed shared key.
For more information about a REXX sample that shows this end-to-end scheme that uses ICSF CCA services, see E.1, “CCA hybrid quantum-safe key exchange scheme REXX sample” on page 166.
For more information about these services and parameters, see ICSF Application Programmer’s Guide, SC14-7508.
6.7.2 Performing a hybrid quantum-safe key exchange scheme by using ICSF PKCS #11 services
A hybrid quantum-safe key exchange can be performed by using the PKCS #11 Derive Key (CSFPDVK and CSFPDVK6) ICSF service.
Consider the following hybrid quantum-safe key exchange scheme that includes two participants: Alice and Bob, who are two parties that want to securely exchange information. They can be a company and a Business Partner, for example.
Step 1: Alice
1. Alice generates an ECC key pair (EC-pub-A, EC-priv-A) for key agreement by using the PKCS #11 Generate Key Pair service.
2. Alice creates EC-cert-A: authenticated form of EC-pub-A
3. Alice sends EC-cert-A to Bob.
Step 2: Bob
1. Bob receives and validates EC-cert-A.
2. Bob creates the following keys:
– ECC (EC-pub-B, EC-priv-B) key pair for key agreement by using the PKCS #11 Generate Key Pair service.
– CRYSTALS-Kyber (Kyb-pub-B, Kyb-priv-B) key pair by using the PKCS #11 Generate Key Pair service.
– EC-pub-A PKCS #11 public key object that was pulled from EC-cert-A by using the PKCS #11 Token Record Create service.
– Kyb-cert-B and EC-cert-B: authenticated forms of Kyb-pub-B and EC-pub-B.
3. Bob derives a generic secret key object (GenSec-B) by passing EC-priv-B and EC-pub-A to PKCS #11 Derive Key.
4. Bob sends Kyb-cert-B and EC-cert-B to Alice.
Step 3: Alice
1. Alice receives and validates Kyb-cert-B and EC-cert-B.
2. Alice creates Kyb-pub-B and EC-pub-B PKCS #11 public key objects that were pulled from their respective certificates by using the PKCS #11 Token Record Create service.
3. Alice derives a generic secret key object (GenSec-A) by passing EC-priv-A and EC-pub-B to PKCS #11 Derive Key.
4. Alice passes GenSec-A and Kyb-pub-B to PKCS #11 Derive Key to encapsulate random key material (rand-A). The Kyber-encapsulated random key material [Kyb-pub-B(rand-A)] and derived shared key are returned. The shared key is the output in the target_key_handle parameter.
5. Alice sends to Bob the Kyber-encapsulated random key material [Kyb-pub-B(rand-A)].
Step 4: Bob
Bob passes GenSec-B and Kyb-priv-A to PKCS #11 Derive Key to decapsulate [Kyb-pub-B(rand-A)]. The derived shared key is output in the target_key_handle parameter.
The shared key is now established at Alice and Bob.
Authentication of the public keys that are used in the scheme is the responsibility of the host.
Currently, CRYSTALS-Kyber keys do not participate in PKI processes. The Kyb-cert-B certificate for the CRYSTALS-Kyber public key recognizes that certificate formats are needed for the authentication part of a protocol.
The lack of PKI support for CRYSTALS-Kyber can be circumvented by using a trustworthy public RSA or EC certificate to verify a signed Kyber SPKI.
For more information about a REXX sample that shows this end-to-end scheme that uses ICSF PKCS #11 services, see E.2, “PKCS #11 hybrid quantum-safe key exchange scheme REXX sample” on page 176.
For more information about these services and parameters, see the ICSF Application Programmer’s Guide, SC14-7508.
6.8 Quantum-safe hashing
Hashing is the process of transforming data (for example a key or message) into a shorter, fixed-length message digest by using a cryptographic hash algorithm.
Hashes are used in various cryptographic operations, such as digital signatures, and key derivation functions, such as PBKDF2, Message Authentication Codes (MAC). The message digests that are produced from a hash algorithm ensures the integrity of the data and protects against unauthorized alteration of the source data.
It is important to start transitioning from weaker hash algorithms, such as SHA-1 or MD2, to much stronger hash algorithms, such as SHA-256 or SHA-512.
This section describes how to perform an SHA-512 hash over a message by using CCA and PKCS #11 ICSF services.
6.8.1 Hashing a message with the SHA-512 algorithm by using ICSF CCA services
To hash a message by using the SHA-512 algorithm, use the One-Way Hash Generate (CSNBOWH or CSNBOWH1 and CSNEOWH or CSNEOWH1) ICSF service.
To hash a message by using the SHA-512 algorithm, complete the following steps:
1. Call the CSFBOWH ICSF service that passes the SHA-512 and ONLY rules.
2. Pass the message to hashed in the text parameter. (Optionally, the message can be hashed in parts by using the chaining flag rules and the chaining_vector parameter.)
The 64-byte message digest is output in the hash parameter.
For more information about a sample REXX program that showcases this process, see F.1, “CCA SHA-512 one-way hash REXX sample” on page 188.
For more information about this service and parameters, see ICSF Application Programmer’s Guide, SC14-7508.
6.8.2 Hashing a message with the SHA-512 algorithm by using ICSF PKCS #11 services
To hash a message by using the SHA-512 algorithm, use the PKCS #11 One-Way Hash, Sign, or Verify (CSFPOWH and CSFPOWH6) ICSF service.
To hash a message by using the SHA-512 algorithm, complete the following steps:
1. Initialize a PKCS #11 token by using the PKCS #11 Token Record Create (CSFPTRC and CSFPTRC6) service.
2. Call the CSFPOWH ICSF service that passes the SHA-512 and ONLY rules.
3. Pass the message to hashed in the text parameter.
4. Pass the token handle that was created in step one in handle parameter. (Optionally, the message can be hashed in parts by using the chaining flag rules and the chaining_vector parameter.)
The 64-byte message digest is output in the hash parameter.
For more information about a sample REXX program that showcases step 2, see F.2, “PKCS #11 SHA-512 one-way hash REXX sample” on page 189.
For more information about these services and parameters, see ICSF Application Programmer’s Guide, SC14-7508.
6.9 Validating your quantum-safe transition
As discussed in 5.1, “Collection tools overview” on page 72, the usage statistics are key to a comprehensive cryptographic inventory.
In Example 6-14, we can see that non-quantum-safe algorithms are used in our DATAOWN job (which is a formatted report of SMF record type 82, subtype 31 [hex ’001F’]). We can identify the use of single DES, AES 128, weak RSA 1024, and so on.
Example 6-14 Crypto usage statistics:Checking for non-quantum-safe algorithms
Type=82 Subtype=001F Crypto Usage Statistics
Written periodically to record crypto usage counts
22 Feb 2022 15:12:27.73
TME... 005389D5 DTE... 0122053F SID... SP21 SSI... 00000000 STY... 001F
INTVAL_START.. 02/22/2022 19:11:30.001815
INTVAL_END.... 02/22/2022 19:12:27.737573
USERID_AS.....DATAOWN
USERID_TK.....
JOBID.........J0000055
JOBNAME.......DATAOWN
JOBNAME2......
PLEXNAME......SYS1
DOMAIN........0
ENG...CARD...8C11/99EA6127...17
ENG...CPACF...150
ALG...DES56......2
ALG...AES128.....2
ALG...RSA1024....1
ALG...ECCBP192...1
ALG...MD5........45
ALG...RPMD160....15
ALG...SHA1....... 70
ALG...SHA3-224... 13
ALG...SHA3-256... 15
ALG...SHA3-384... 13
ALG...SHA3-512... 13
ALG...SHAKE128... 12
ALG...SHAKE256... 14
SRV...CSFKYT..... 2
SRV...CSFDSG..... 2
SRV...CSFOWH..... 264
SRV...CSFOWH1.... 3
SRV...CSFIQF..... 485
SRV...CSFIQF2.... 2
After identifying the weak algorithms and replacing them with quantum-safe algorithms, ICSF usage statistics can be used to monitor progress with a formatted report of SMF record type 82, subtype 31 (hex ‘001F’).
In Example 6-15, most algorithms are quantum-safe. For example, we no longer use AES 128; instead, we use AES 256. We can also see that CRYSTALS-Dilithium and CRYSTALS-Kyber algorithms are being used.
Example 6-15 Crypto usage statistics: Checking for quantum-safe algorithms
Type=82 Subtype=001F Crypto Usage Statistics
Written periodically to record crypto usage counts
Mar 2022 15:35:30.00
TME... 0055A5C8 DTE... 0122070F SID... SP21 SSI... 00000000 STY... 001F
INTVAL_START.. 03/11/2022 19:33:59.202360
INTVAL_END.... 03/11/2022 19:35:30.001479
USERID_AS..... QSAFE
USERID_TK.....
JOBID......... T0000046
JOBNAME....... QSAFE
JOBNAME2......
PLEXNAME...... SYS1
DOMAIN........ 0
ENG...CARD...8C00/99EA6006... 17
ENG...CPACF... 5
ALG...DES112..... 1
ALG...AES256..... 9
ALG...ECCP384.... 6
ALG...KY1024R2... 3
ALG...LI2-87R3... 4
SRV...CSFDSG..... 2
SRV...CSFDSV..... 2
SRV...CSFPKG..... 3
SRV...CSFPKE..... 1
SRV...CSFPKX..... 3
SRV...CSFKYT2.... 2
SRV...CSFEDH..... 2
SRV...CSFPKB..... 3
SRV...CSFCTT2.... 1
|
Important: Data that is protected with a retired algorithm must not remain in the system after it is protected by using a quantum-safe algorithm. Removing the data that was encrypted by using a retired algorithm eliminate the risk of an attacker finding that data and breaking the encryption.
|
..................Content has been hidden....................
You can't read the all page of ebook, please click here login for view all page.