Tony, thanks for the comments about Secure+. I did not realize that, but it
does make some sense.
Radoslaw: The only product that I can think of that absolutely requires ICSF
is the old Encryption Facility for z/OS.
And Yes, you can certainly run ICSF without CEX cards or CPACF. I have a pie
chart in one of my presentations that shows the APIs that require hardware.
For HCR77C1:
# of APIs
No Hardware 29
CPACF 10
CCA Coprocessor 123
EP11 5
PKCS 11 14
There are 29 APIs that don't require any hardware. Those include utility APIs
like CSFIQF that tell you about the crypto environment and CSNBKRR which will
read a key from the keystore. Those aren't really doing crypto work.
Ten APIs are routed to the CPACF.
The EP11 APIs require a CEX configured as an EP11 coprocessor, while the PKCS
11 APIs are clear key operations and don't necessarily require hardware, but
that may depend on what you are trying to accomplish.
And that is true for other APIs as well ... it depends on what you're trying to
do. I include CSNBSYE/CSNBSYD in the 10 APIs that are routed to the CPACF
hardware, but if you are executing those APIs to do AES then you don't have to
have the CPACF. When AES support was added to these APIs, there were still
machines (z890/z990) being marketed that did not support AES in hardware, so
IBM provides software routines in ICSF to do AES encryption. (You might not
like the performance.) If you want to use those APIs to do DES/TDES, then you
must have the CPACF enabled. ICSF does not provide DES software routines.
The main point of the pie chart is that for the vast majority of the crypto
functions available in ICSF, you need a CCA Coprocessor.
Greg Boyd
Mainframe Crypto
www.mainframecrypto.com
On Tue, 22 Jan 2019 16:57:09 +0000, Cieri, Anthony <[email protected]> wrote:
>
> I believe that it is the Secure+ feature for Connect:Direct that
> exploits the Crypto hardware. If you are NOT using seure+, then I believe
> that there is no "requirement" for ICSF.
>
> However, I also believed that even if secure+ WERE enabled and you
> attempted a process to a Secure+ enabled partner node that if ICSF was NOT
> available, that the secure+ process WOULD execute, but that the encryption
> workload would be processed in general CPs.
>
> w was curious, so I tried an experiment and I offer my observations
> below.
>
> I sent a few processes to an established secure+ test node from a LPAR
> with ICSF up and available. The processes executed successfully. Next, I
> brought down ICSF on that same LPAR and resubmitted the same test processes.
> To my surprise, they failed with the following message:
>
> CSPA014E Unable to read remote node definition
>
> I recall that somewhere between Connect:Direct V4.8 and version5.2,
> there was a "requirement" to encrypt the Secure+ PARMFILE with Triple-DES. I
> suspect that it is this change that now requires ICSF to be active.
>
> So it appears that Connect:Direct (V5.x with the Secure+ feature
> enable) is like newer releases of IBM's OpenSSH Server in that they now do
> require ICSF to be active.
> There were certainly "older" releases of both, that did NOT have a
> "requirement" for ICSF to be active.
>
> Hth
> Tony
>
>
>
>-----Original Message-----
>From: IBMaMainframe Discussion List [mailto:[email protected]] On
>Behalf Of Greg Boyd
>Sent: Tuesday, January 22, 2019 8:27 AM
>To: [email protected]
>Subject: Re: ICSF and z/OS 2.3
>
>[[ SEI WARNING *** This email was sent from an external source. Do not open
>attachments or click on links from unknown or suspicious senders. *** ]]
>
>
>There may have been changes to Connect Direct since the last time I worked
>with it, but I suspect ICSF is required if you want to leverage the hardware
>technology, and specifically the CEX cards. As Kirk points out, if you want
>to use the random number generation on hardware then you need ICSF active.
>(And you probably do want the performance of RNG in hardware.) Similarly, for
>System SSL, if you want to use the Crypto Express cards for authentication
>(public/private key operations), then ICSF needs to be active. Enabling the
>cards and having ICSF active can make a big difference in throughput and
>capacity (CPU savings), but strictly speaking it's probably not required
>unless you configure the environment to use the crypto hardware.
>
>Greg Boyd
>Mainframe Crypto
>www.mainframecrypto.com
>
>
>On Fri, 18 Jan 2019 17:55:51 -0600, Steve beaver <[email protected]> wrote:
>
>>Also it’s required for Connect Direct
>>
>>Sent from my iPhone
>>
>>Sorry for the finger checks
>>
>>> On Jan 18, 2019, at 17:29, Kirk Wolf <[email protected]> wrote:
>>>
>>> ICSF is currently required if you want to use the Unix /dev/random and
>>> /dev/urandom devices.
>>> These might be required by Unix apps (or jobs/stcs that use z/OS Unix
>>> System services).
>>>
>>> For exampe: IBM OpenSSH server will not work without ICSF and /dev/random
>>> available.
>>>
>>> On Fri, Jan 18, 2019 at 5:24 PM Greg Boyd <[email protected]>
>>> wrote:
>>>
>>>> ICSF is only required if you want to use the ICSF APIs, so it depends on
>>>> what, if anything in your shop might be using the APIs. System SSL (TLS)
>>>> will certainly leverage the APIs if you have Crypto Express cards available
>>>> and that might provide some CPU relief. The Guardium Database Encryption
>>>> Tool requires it if you want to encrypt IMS segments or DB2 tables at the
>>>> row level.
>>>>
>>>> Pervasive is getting a lot of attention and if you're going that route, I
>>>> would highly recommend that ICSF be active everywhere. You don't want one
>>>> system writing ciphertext to a file and another system thinking that the
>>>> file is cleartext. IBM is also recommending that ICSF be 'always up'.
>>>> They have made a number of changes to the component so that it will come up
>>>> earlier in the IPL and it should be one of the last tasks running.
>>>>
>>>> Given the growth in crypto workload, I take 'always up' to also mean
>>>> 'running everywhere'. There are simply more things that can leverage ICSF,
>>>> some optionally and some require it.
>>>>
>>>> I'm not sure why DFSMShsm would need ICSF active, unless they were using
>>>> the Encryption Facility for z/OS with the DFSMSdss feature.
>>>>
>>>> Greg Boyd
>>>> Mainframe Crypto
>>>> www.mainframecrypto.com
>>>>
>>>>
>>>>
>>>> On Fri, 18 Jan 2019 18:16:37 +0000, Mary Kay Tubello <[email protected]>
>>>> wrote:
>>>>
>>>>> Hello all,
>>>>>
>>>>> Does anyone know if z/os 2.3 requires ICSF to be installed on each LPAR?
>>>>>
>>>>> Thanks,
>>>>> Mary Kay
>>>>>
>>>>> Large Systems Engineering
>>>>> IT Infrastructure
>>>>> Humana
>>>>> 123 E. Main St. 40202 (CT6)
>>>>> 502-476-2772
>>>>> [email protected]<mailto:[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
>>>>
>>>
>>> ----------------------------------------------------------------------
>>> 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
>
>----------------------------------------------------------------------
>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
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
