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
[email protected]
----------------------------------------------------------------------
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
