Tom, It is possible to initialise ICSF without a Crypto Express card. I have done it. Changes were made to ICSF in support of that initialisation many years ago. It does require the CPACF. However, this only supports clear keys in the CKDS. The CKDS formatting is different in some way and cannot be converted to a secure key CKDS. I don't know if there is a way of using the PKDS or TKDS in this configuration. I have been told it is possible to run Data set encryption with CPACF only and a clear key CKDS, but I have not tried this.
My understanding is that System SSL libraries use code that works out what facilities are available and uses the "best" option. CPACF on the later machines has some support for asymmetric keys so that could potentially help with handshakes. Earlier machines with CPACF could only do symmetric key processing. In the back of my mind I also think that the crypto processing for TCP/IP could be performed on a zIIP processor (which could be using its CPACF, of course). Lennie Dymoke-Bradshaw https: //rsclweb.com -----Original Message----- From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> On Behalf Of Tom Brennan Sent: 24 January 2024 08:49 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Encryption and decryption - processor or TCPIP Woah... right now I'm only about 1000 miles from Timothy so I get to see his responses in real time and not California time :) So Timothy (and probably just for me), I've seen a couple of sites without crypto HSM cards not bother to run ICSF. Can I assume in that case there's pretty-much no way any encryption processing could be using CPACF? On 1/24/2024 12:29 AM, Timothy Sipples wrote: > Peter wrote: >> I have a general question here. When you don't have crypto processor, >> So when a ATTLS traffic is enabled does the encryption and decryption >> handled by Started task TCPIP or the general processor? > > I've seen some of the follow-up messages, and it seems like you're trying to troubleshoot a performance/throughput-related issue. Or at least you'd like to understand what changed, why you may be observing an elongation in your transaction times from CICS's perspective. > > "Crypto processor" could refer to the CP Assist for Cryptographic Functions (CPACF) or to the IBM Crypto Express hardware security modules (HSMs). CPACF is an integral part of every main processor that's on every modern IBM Z and all IBM LinuxONE machine models. You need to have Feature Code 3863 installed to enable CPACF's full set of cryptographic algorithms. So just make sure that feature code is installed on all your machines. CPACF is an integral part of your main processors that supports additional instructions that accelerate lots of cryptographic operations. > > IBM Crypto Express HSMs are optional (but strongly recommended!) > features that are installed as cards in your IBM Z or IBM LinuxONE > server's PCI slots. In recent models there are two variants of the IBM > Crypto Express cards: "single port" and "dual port." Dual port means > that there are two physical HSMs per card. It's simply a higher > density card that allows you to support more HSM domains and modes > within a smaller physical space, analogous to the difference between a > fully populated processor drawer and a partially populated one. > Whether you get the single port or dual port variant (or some of > both), their role is to protect secrets, especially private encryption > keys. They have their own onboard processors to execute cryptographic > operations, and you need them to move beyond "clear key" cryptography. > Clear key cryptography means your private encryption keys inhabit main > memory, the same memory that the operating system, middleware, and > applications inhabit. Conceivably that memory could be accessed - via > a dump that hasn't been redacted, for example - to obtain the private > keys. The vast majority of non-IBM Z/LinuxONE systems that support TLS > are operating with clear key, but "we can do better." And we do: > Crypto Express facilitates protected key and secure key operations. > Get them, use them, love them. :-) > > But let's leave that HSM point aside for the moment and just focus on z/OS AT-TLS and what you may be observing. If you're actually seeing longer transaction times - if you've got reasonable evidence this one change (changing an unencrypted connection to a TLS encrypted connection) made the difference - then there are likely one or two basic reasons why. One likely reason is that you're not getting a good match between z/OS AT-TLS and CPACF. That is, z/OS AT-TLS (and specifically the z/OS System SSL component that AT-TLS uses) isn't exploiting CPACF as much as it could. For example, AT-TLS and the other party to the network connection may have mutually negotiated a cipher suite that's less than ideal for CPACF exploitation. Generally you should "encourage" (or even require) one of the AES GCM cipher suites, and you can do that by configuring AT-TLS to prefer certain cipher suites and outright reject several. And of course you should use only TLS 1.2 or higher, with weak cipher suites disabled. So... check your cipher suite(s). > > Next, do you have the appropriate software levels that can exploit CPACF well on your machine? ICSF and System SSL are quite important, so check those levels especially. Do you see newer releases (or PTFs) with better CPACF exploitation? Get them on if you can. There are some tools and traces you can use to figure out how much CPACF exploitation you're getting. > > Finally, you could be observing the natural effects of non-persistent TLS connections. When you establish a new TLS connection there's an initial handshake, a negotiation that takes place to establish the secure connection before the two systems exchange real data. If you're comparing non-persistent TLS connections to unencrypted connections then you should see double the number of network roundtrips: one set of roundtrips to establish the TLS connection, then the real data-bearing roundtrips over the TLS connection. And these extra hops may be OK! It may be just the "cost of doing business" when you turn on TLS to secure your network connections. Non-persistent TLS connections are not much of a direct processor utilization concern if you've got CPACF instructions exploited well, but it may be a latency concern. Greater latency, in turn, could have some secondary processor utilization effects. > > If you're concerned about the extra network roundtrips that TLS handshaking requires then you can check whether you can establish persistent connections instead. And a persistent connection could be TLS, IPSec/IKEv2, or a SSH tunnel. Another possible option is to relocate the other party closer (in network latency terms) to z/OS AT-TLS. Let's suppose for example you're connecting from CICS to an OpenLDAP server running on another machine in another data center. You could install, configure, and run an instance of OpenLDAP on the z/OS Container Extensions (zCX) within the same LPAR running your CICS transactions. That z/OS-hosted OpenLDAP server can replicate with other OpenLDAP servers elsewhere so that it's kept in sync. And then your CICS application has a much shorter, much lower latency network path because it can connect to the local OpenLDAP instance inside the same LPAR. > > Does this background help and give you some areas to check? > > ----- > Timothy Sipples > Senior Architect > Digital Assets, Industry Solutions, and Cybersecurity IBM Z/LinuxONE, > Asia-Pacific sipp...@sg.ibm.com > > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, send > email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
