Digital signatures are an integral component of today’s cryptography and are often found in network security, secure boot processes, and software distribution. Taking advantage of public-key cryptography, digital signatures provide three main benefits:
- Data Integrity — The data recipient can ensure that the data is in its original state and has not been tampered with.
- Data authenticity — The data recipient can verify the original source of the data.
- Non-repudiation — The data sender cannot dispute that they sent the data.
In the era of quantum computing, quantum algorithms such as Shor’s algorithm threaten to break the public-key cryptography that underpins digital signatures. Taking advantage of unique properties of quantum computers such as entanglement and superposition, problems that were difficult to solve with classical computers are now solvable with quantum computers. This risk necessitated the need to come up with new quantum-safe algorithms that are resistant to attacks from a quantum computer. In 2016 the National Institute of Standards and Technology (NIST) put out a call for proposals for quantum-safe algorithms and in 2022 selected four algorithms for standardization. Two of the four algorithms’ CRYSTALS-Kyber, a key-encapsulation mechanism (KEM), and CRYSTALS-Dilithium, a digital signature algorithm, are available on supported IBM hardware. Both algorithms are part of the Cryptographic Suite for Algebraic Lattices (CRYSTALS) and are based on hard problems over module lattices designed to resist attacks from powerful quantum computers1.
Beginning on z/OS 2.4 on the z15, IBM System Management Facilities (SMF) added support to sign an SMF record with a secondary (or alternate) signature using the CRYSTALS-Dilithium digital signature algorithm. The secondary signature is performed in conjunction with a primary signature using traditional crypto algorithms such as RSA or ECDSA. Both signatures are contained within the SMF Type 2 signature record in which you can either validate the primary signature or both signatures. This hybrid approach combines the strength of traditional and quantum-safe cryptography ensuring SMF record integrity in the quantum era.
The following steps outline how to get SMF configured to sign records with the CRYSTALS-Dilithium algorithm and how to perform the signature validation. SMF digital signatures are supported only when recording to a log stream.
1. Generate the ECC/RSA and CRYSTALS-Dilithium key pairs with ICSF
Before you can generate the key pair objects, you need to create two PKCS #11 tokens to hold them. There are two ways to create a PKCS #11 token in ICSF. The first is with the PKCS #11 Token Record Create (CSFPTRC) callable service. The second is with the PKCS #11 Token Management Utility panel.
To create PKCS #11 tokens with the ICSF Token Management Utility panel, navigate to the ICSF panels and select option 5 - ‘Utility’.
Next, select option 7 – ‘PKCS11 Token’.
Finally, select option 1 – ‘Create a new token’, and fill in the token name and press ENTER. When creating both tokens, ensure that the token name is exactly 32 characters long.
Once you’ve created two PKCS #11 tokens, it’s time to generate the key pairs. Either the RSA or ECC algorithm can be used for the primary signature. The secondary signature will take advantage of the CRYSTALS-Dilithium algorithm. Currently only the CRYSTALS-Dilithium (6,5) Round two strength is supported by SMF. Both key pairs can be generated with PKCS #11 Generate Key Pair (CSFPGKP) callable service. In the GKP service, ensure that only one key pair is written to the token and each token contains exactly two key objects. Appendix B.4 of the “Transitioning to Quantum-safe Cryptography on IBM Z” Redbook in the resource links below contain a REXX sample for generating a PKCS #11 CRYSTALS-Dilithium key pair.
2. Configure the SMFPRMxx parmlib member with the signature parameters
There are two parameters needed to enable primary and secondary digital signatures.
The RECSIGN parameter specifies to sign SMF records using the primary signature algorithm. The SIGNATURE sub-parameter indicates to use either the RSA or ECDSA signature algorithm. The HASH sub-parameter indicates which hashing method is used. This can be either SHA1, SHA256, SHA384, or SHA512. Finally, the TOKENNAME sub-parameter specifies the PKCS #11 token name that contains the RSA or ECC key pair. This is the first token that you created in step one.
For example:
RECSIGN(HASH(SHA512),SIGNATURE(ECDSA),
TOKENNAME(SHARE.CRYPT01.QSAFE.SMFLAB.ECC01))
The ARECSIGN parameter specifies to sign SMF records using the secondary signature algorithm. The SIGNATURE sub-parameter should specify LI2 which indicates the CRYSTALS-Dilithium signature algorithm. For the HASH sub-parameter, only SHA-512 is supported. Finally, the TOKENNAME sub-parameter specifies the PKCS #11 token name that contains the CRYSTALS-Dilithium key pair. This is the second token that you created in step one.
For example:
ARECSIGN(HASH(SHA512),SIGNATURE(LI2),
TOKENNAME(SHARE.CRYPT01.QSAFE.SMFLAB.LI201))
Both RECSIGN and ARECSIGN can be specified globally or on a per log stream basis. Ensure that the SMF identity has proper SAF authority to both PKCS #11 tokens and the PKCS #11 One-Way Hash, Sign, or Verify (CSNPOWH) ICSF service. Once you have your signature parameters configured, you can activate your SMF parmlib member, and SMF digital signatures will begin for the SMF types recorded to the log stream.
Here is a sample SMFPRMxx with signatures defined globally for all types:
ACTIVE /* Active SMF recording */
NOPROMPT
RECORDING(LOGSTREAM) /* Recording to log streams */
RECSIGN(HASH(SHA512),SIGNATURE(ECDSA),
TOKENNAME(SHARE.CRYPT01.QSAFE.SMFLAB.ECC01))
ARECSIGN(HASH(SHA512),SIGNATURE(LI2),
TOKENNAME(SHARE.CRYPT01.QSAFE.SMFLAB.LI201))
DEFAULTLSNAME(IFASMF.SMFALL) /* Default log stream for SMF records not
directed to another log stream */
SYS(TYPE(0:2047)) /* Record types to record */
MAXDORM(3000) /* Flush SMF buffers after 30 min */
INTVAL(30) /* SMF intervals every 30 min */
SYNCVAL(00) /* Sync intervals to top of hour */
SID(&SYSNAME(1:4)) /* System ID (SMF ID) is first 4
characters of system name */
3. Move signature data from the log stream to a data set using the IFASMFDL program
When you’re ready to start validating SMF signatures, the first step is to dump the SMF log stream to a sequential data set using the IFASMFDL program. The LSNAME parameter indicates the log stream to be dumped. This should match the log stream specified in the SMFPRMxx member. The NOSIGSTRIP parameter indicates to dump SMF Type 2 Subtypes 1 & 2 signature records. This must be specified to perform signature validation. Subtype 1 is written for each signature group. Subtype 2 is written for each signature interval. The DATE parameter specifies the range for which records are to be dumped. Ensure the range aligns with the records that you want to validate.
Sample IFASMFDL program JCL:
//IFASMFDL EXEC PGM=IFASMFDL,REGION=0M
//OUTDD1 DD DSN=CRYPT01.SMF.LOG,DISP=(NEW,CATLG,DELETE),
// SPACE=(CYL,(100,100),RLSE),
// DCB=(LRECL=32760,RECFM=VBS,BLKSIZE=0)
//SYSPRINT DD SYSOUT=A
//SYSIN DD *
LSNAME(IFASMF.SMFALL,OPTIONS(DUMP))
OUTDD(OUTDD1,TYPE(0:255))
NOSIGSTRIP
DATE(2023064,2023064)
4. Validate the SMF Signature records with the IFASMFDP program
Now that the SMF signature data is in a data set, you can begin validating it using the IFASMFDP program. Like IFASMFDL, the NOSIGSTRIP parameter must be specified. For the START and END parameters, specify that only the SMF records within that range are to be validated. For best results, sync up this range to the SMF interval (INTVAL) specified in the SMFPRMxx member. The SIGVALIDATE and ASIGVALIDATE parameters indicate to validate both the primary and secondary signatures. The HASH and TOKENNAME sub-parameters must match what was specified in the SMFPRMxx member. The user ID submitting the IFASMFDP program must have proper SAF authority to both PKCS #11 tokens and the CSNPOWH ICSF service. If you’ve received a successful return & reason code after submitting the JCL, the record validation report in the job output will indicate that signature validation has succeeded.
Sample IFASMFDP program JCL:
//IFASMFDP EXEC PGM=IFASMFDP
//DUMPIN DD DISP=SHR,DSN=CRYPT01.SMF.LOG
//DDSMF1 DD DSN=CRYPT01.SMF.DS,
// DISP=(NEW,CATLG,DELETE),
// SPACE=(CYL,(100,100),RLSE),
// DCB=(RECFM=VBS,BLKSIZE=32748,LRECL=32756)
//SYSPRINT DD SYSOUT=A
//SYSIN DD *
SID(S2)
INDD(DUMPIN,OPTIONS(DUMP))
OUTDD(DDSMF1,TYPE(0:255))
NOSIGSTRIP
DATE(2023064,2023064)
START(2110)
END(2140)
SIGVALIDATE(HASH(SHA512),
TOKENNAME(SHARE.CRYPT01.QSAFE.SMFLAB.ECC01))
ASIGVALIDATE(HASH(SHA512),
TOKENNAME(SHARE.CRYPT01.QSAFE.SMFLAB.LI201))
Example successful validation report:
RECORD VALIDATION REPORT FOR S2
RECORD RECORD VALIDATION VALIDATION START VALIDATION END
TYPE SUBTYPE FAILURE DATE-TIME DATE-TIME
82 31 N 04/19/2023-16:30:00 04/19/2023-16:40:00
82 20 N 04/19/2023-16:30:00 04/19/2023-16:40:00
82 23 N 04/19/2023-16:30:00 04/19/2023-16:40:00
VALIDATION SUCCEEDED
Example failing validation report:
RECORD VALIDATION REPORT FOR S2
RECORD RECORD VALIDATION VALIDATION START VALIDATION END
TYPE SUBTYPE FAILURE DATE-TIME DATE-TIME
82 31 Y 04/19/2023-16:30:00 04/19/2023-16:40:00
82 20 N 04/19/2023-16:30:00 04/19/2023-16:40:00
82 23 N 04/19/2023-16:30:00 04/19/2023-16:40:00
VALIDATION FAILED: INCOMPLETE VALIDATION - ENDED WITH PARTIAL INTERVAL
The IBM z16 along with the Crypto Express 8S HSM will enable you to take full advantage of the quantum-safe capabilities and future proof your business. With the successful implementation of SMF quantum-safe signatures, you will be able to ensure integrity protection over your sensitive SMF records now and in the future as quantum computers continue to advance and inch closer towards quantum advantage.
References:
1: https://pq-crystals.org/index.shtml
Resources:
ICSF Publications
https://ibm.biz/BdPmSL
IBM Crypto Education Community
https://ibm.biz/BdPmSu
SMF Signatures documentation
https://ibm.biz/BdPmg2
Transitioning to Quantum-safe cryptography on IBM Z Redbook
https://ibm.biz/BdPmuU
Gregg Arquero is a Senior Software Engineer at IBM. He joined IBM in 2015 working with the z/OS ICSF team. During his time on the ICSF team, he has designed and developed several key crypto solutions on IBM Z such as early ICSF availability at IPL, ICSF compliance reporting, and Quantum-safe algorithm support. He is also an avid innovator with over a dozen granted patents by the USPTO. He received his bachelor’s degree in Computer Science from Binghamton University.