There have been a lot of good answers on this topic so far but I would like to add my two cents (especially since I was there when the old magic was written 😊 )
Phil said > Crypto cards are MOSTLY for improved security, so keys don't reside in the > clear on the system. Then, Lennie said: > Crypto cards also give you the ability to use "Protected keys". These are the > keys used by DFSMS in encrypting data files. Protected key processing use the > Crypto card to access a securely encrypted key from the ICSF CKDS and then > provide high-sped access to the key using CPACF operations. Finally, Radek said: > You need CPACF, which is free of charge (although it has to be enabled due to > export controls). 100%. This is my jam! I love crypto express for the extremely high security (FIPS 140 Level 3 or 4, I forget which) and CPACF for really good security (not quite as good as crypto express, but still great) AND awesome performance, especially for bulk encryption (like data set encryption or TLS sessions). > The exception is TLS handshake, where they can help with performance. The one thing I would add to this is that crypto cards are useful for certain kinds of handshakes. TLS 1.2 was very enamored with RSA, so crypto cards doing RSA is a great help for both certificate validation and RSA key exchange. However, TLS 1.3 is in love with ECC (and others), so CPACF is the go-to for these operations where you get significant performance from it. The path to the card is just long enough that the CPU savings might not outweigh the wall clock cost. Phil said: > Are there worries about security of the keys? Regulatory requirements might > mean using an HSM (which is what the CEX is) isn't optional. This is an important point that cannot be ignored. Phil said: > If it's asymmetric, there are more questions to answer--AES isn't asymmetric, > for starters. Both RSA and ECC have some weaknesses with quantum attacks. IBM released CCA support for two of the three NIST PQC standards: FIPS 203 (ML-KEM) and FIPS 204 (ML-DSA) and we are committed to PQC support across the stack. I have no ability to commit to a timeframe but we have stated publicly that we intend to do this. Phil said: > use TLSv1.3, no reason not to. 100% agree, as long as you can get your partners to update as well. Radek said: > Nice to have: CryptoExpress cards (2 at least, for redundancy purposes). > And some guy who explain what is possible and what's ridiculous. I would go a little further and say that two Crypto Express coprocessors would be my minimum recommendation, This is more than just a nice to have if you are dealing with a financial institution. I speak to large financial customers about weekly and I have yet to speak to one where their auditors weren't requiring secure keys for at least the basis of functionality. I don't know where to suggest finding that guy, but I'm sure some of us have thoughts. Steve said: > ... traffic across network pipe ... with TLS ... proof of concept involving > new Z replication software that will propagate / replicate change logs for > CICS and DB2. This by itself only requires CPACF. However, I would submit that having secure keys for the private key material on both ends of that pipe along with enabled both client and server authentication would go a LONG way towards making my security-heart feel safe. > What I am looking for is a clear decision tree / matrix to determine if > crypto cards are required or not CPACF is a non-negotiable. You cannot have crypto cards without it. As for crypto express cards, I would suggest that you would want at least two features. This is either 2 cards for the 1-card-per-feature option or 4 cards for the 2-cards-per-feature option. The reason I suggest two features is for the redundancy. Frankly, most crypto MCLs are concurrent (non-disruptive) so you can apply them and the cards stay going through the whole operation. However, in the rare case of non-concurrent (disruptive) updates, you will be able to take half your cards offline for updates and wait for them to finish before doing the other half. > when they are absolutely required for network encryption related purposes. Really, their strength is so that you can have the asymmetric (RSA or ECC or PQC) private keys in a form that is secured by the HSM. Those private keys are everything to establishing TLS security. Eric Rossman --------------------------------- ICSF Security Architect z/OS Security --------------------------------- -----Original Message----- From: IBM Mainframe Discussion List <[email protected]> On Behalf Of Steve Estle Sent: Friday, October 3, 2025 8:25 AM To: [email protected] Subject: [EXTERNAL] ZSeries Crypto Cards - Decision Table? All, Am working with financial institution that needs to encrypt traffic across network pipe using at least AES256 or higher encryption protocol with TLS 1.2 or higher that will lead to an eventual proof of concept involving new Z replication software that will propagate / replicate change logs for CICS and DB2. They do not currently have crypto accelerator cards installed in Z processor(s). They are running ZOS 3.1. What I am looking for is a clear decision tree / matrix to determine if crypto cards are required or not - I understand they can reduce CPU overhead but beyond optimized encryption / decryption what are the gating factors that drive the need for crypto hardware cards (I know they are needed for pervasive encryption for data at rest), but less clear on when they are absolutely required for network encryption related purposes. All input / reference materials (Redbooks, Share, etc.) are appreciated. Thanks, ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
