Discussion:
Crypto Utilization Question
Add Reply
Richards, Robert B.
2018-10-04 14:12:06 UTC
Reply
Permalink
I sent an email to Greg Boyd (Greg Boyd ***@MAINFRAMECRYPTO.COM<mailto:***@MAINFRAMECRYPTO.COM>) asking for a response to a coworker's question below. In case Greg is otherwise engaged, I am casting a wider net to get an answer in a timely fashion (i.e. ASAP :)).

Any takers?

Thanks in advance,

Bob

The question:

We currently have a total of 3 Crypto Express4 Accelerators and 3 Crypto Express4 CCA coprocessors configured and shared with all of our 8 z/OS LPARS and 1 Crypto Express4 CCA coprocessor defined to z/VM for Linux. We need to understand what utilization should be allowed for each of these to help us determine if we have too many or when we should be getting additional.


CRYPTO SERIAL
FEATURE NUMBER STATUS AES DES ECC RSA P11
------- -------- -------------------- --- --- --- --- ---
4C00 00000000 Active A A I A
4A01 N/A Active
4C02 00000000 Active A A I A
4A03 N/A Active
4C04 00000000 Active A A I A
4A05 N/A Active



----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Todd Arnold
2018-10-05 14:59:38 UTC
Reply
Permalink
Unfortunately, crypto card utilization is a complex thing because the HSM cards themselves can execute multiple operations simultaneously, depending on the mix your applications are sending it. A simple example is the fact that the cards have completely independent hardware for symmetric key crypto (e.g. TDES, AES) and for public-key crypto (e.g. RSA, ECC). Thus, your card might be 100% utilized doing TDES operations, but still have lots of capacity to do more RSA operations.

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Greg Boyd
2018-10-07 18:45:58 UTC
Reply
Permalink
Richard,
I tried responding to your note from three different email addresses. I keep getting a response back, apparently from your server, that delivery is delayed. Not sure what's going on.

I absolutely agree with Todd's comments: It's hard to evaluate performance metrics or do capacity planing on the cards because it is highly dependent on your workload AND the crypto infrastructure doesn't provide a lot of details about the work it is doing. With HCR77C1 there are some new stats that are available though that might help.

My general recommendation is to leave your cards as coprocessors (the default) until either:
a) you need PKCS11 secure key support or
b) the RMF Crypto Hardware Activity Report shows that the cards are getting busy AND you know that your crypto workload is supported on an ccelerator

In the first case, if you need PKCS11 secure key, then your only option is to change the cards to EP11 mode. (Don't forget for EP11 mode, you must have a TKE to load the master keys into that card.)

In the second case, if your cards are getting busy AND you know that your workload includes SSL (aka TLS) operations, then switching a card to an accelerator may help. When configured as an accelerator the card can only perform public key operations. A coprocessor can perform those same public key operations, just not as many of them.

In terms of 'busy', you need to know what your normal is. To take Todd's comments a bit further, if your cards are running at 75%, doubling the TDES workload may not max the card out. But doubling the RSA workload might. It depends on how much of that 75% is RSA vs TDES vs ECC vs PIN operations vs Key Generation. So you need to monitor the RMF Crypto Hardware Activity Report and know what your growth rate is and at least have an idea of what kind of work you are sending to the cards. If it's the right type of work (public key ops), then it might make sense to reconfigure a card as an accelerator.

Don't forget to consider redundancy. A coprocessor will still do public key operations if the accelerator fails. But the accelerator can't back up the additional functionality on a coprocessor.

Finally, be aware that the potential benefit of converting a CEX6S card to an accelerator is much smaller than converting a CEX5S (or earlier card) to an accelerator. On the older cards, an accelerator could drive approximately twice as many SSL operations as a coprocessor. A CEX6S accelerator can only drive about 15% more SSL operations than a CEX6S coprocessor.
Greg
Greg Boyd
www.mainframecrypto.com
Post by Richards, Robert B.
Any takers?
Thanks in advance,
Bob
We currently have a total of 3 Crypto Express4 Accelerators and 3 Crypto Express4 CCA coprocessors configured and shared with all of our 8 z/OS LPARS and 1 Crypto Express4 CCA coprocessor defined to z/VM for Linux. We need to understand what utilization should be allowed for each of these to help us determine if we have too many or when we should be getting additional.
CRYPTO SERIAL
FEATURE NUMBER STATUS AES DES ECC RSA P11
------- -------- -------------------- --- --- --- --- ---
4C00 00000000 Active A A I A
4A01 N/A Active
4C02 00000000 Active A A I A
4A03 N/A Active
4C04 00000000 Active A A I A
4A05 N/A Active
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Loading...