Discussion:
ICSF and millions of RSA keys
(too old to reply)
R.S.
2018-06-27 14:47:38 UTC
Permalink
Usually ICSF use the key kept in its repositories - CKDS for symmetric
keys and PKDS for assymetric cryptography.
There is a plan to use several millions of public keys (private key
reside out of the mainframe).
Some questions and doubts:
1. Is it good idea to have millions of keys in PKDS? Would it be a
problem for ICSF? VSAM limits seem to be not a problem, but maybe ICSF
have some bottlenecks or limitations.
2. Can I keep the keys out of PKDS, for example in DB2 table? Note, we
talk about public key, so there is no big reason to keep it secret.
For example: tell ICSF to check msg using given key value, instead of
given key label. I remeber such solution is feasible for symmetric keys
(the key was encrypted using Master Key).
3. What about performance? While DB2 table can be buffered, what about
PKDS? Does it require I/O for every key use?
--
Radoslaw Skorupka
Lodz, Poland




======================================================================


--
Treść tej wiadomości może zawierać informacje prawnie chronione Banku przeznaczone wyłącznie do użytku służbowego adresata. Odbiorcą może być jedynie jej adresat z wyłączeniem dostępu osób trzecich. Jeżeli nie jesteś adresatem niniejszej wiadomości lub pracownikiem upoważnionym do jej przekazania adresatowi, informujemy, że jej rozpowszechnianie, kopiowanie, rozprowadzanie lub inne działanie o podobnym charakterze jest prawnie zabronione i może być karalne. Jeżeli otrzymałeś tę wiadomość omyłkowo, prosimy niezwłocznie zawiadomić nadawcę wysyłając odpowiedź oraz trwale usunąć tę wiadomość włączając w to wszelkie jej kopie wydrukowane lub zapisane na dysku.

This e-mail may contain legally privileged information of the Bank and is intended solely for business use of the addressee. This e-mail may only be received by the addressee and may not be disclosed to any third parties. If you are not the intended addressee of this e-mail or the employee authorized to forward it to the addressee, be advised that any dissemination, copying, distribution or any other similar activity is legally prohibited and may be punishable. If you received this e-mail by mistake please advise the sender immediately by using the reply facility in your e-mail software and delete permanently this e-mail including any copies of it either printed or saved to hard drive.

mBank S.A. z siedzibą w Warszawie, ul. Senatorska 18, 00-950 Warszawa, www.mBank.pl, e-mail: ***@mBank.plSąd Rejonowy dla m. st. Warszawy XII Wydział Gospodarczy Krajowego Rejestru Sądowego, nr rejestru przedsiębiorców KRS 0000025237, NIP: 526-021-50-88. Według stanu na dzień 01.01.2018 r. kapitał zakładowy mBanku S.A. (w całości wpłacony) wynosi 169.248.488 złotych.


----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Jousma, David
2018-06-27 14:53:22 UTC
Permalink
If you have the ability, I'd open a Q&A PMR with IBM crypto support. I suspect it can handle it, but doesn't hurt to ask. For crypto, years ago we were running into catalog contention with ICSF accessing the KDS datasets. We created new dedicated usercat/alias and have been fine ever since.

_________________________________________________________________
Dave Jousma
Manager Mainframe Engineering, Assistant Vice President
***@53.com
1830 East Paris, Grand Rapids, MI  49546 MD RSCB2H
p 616.653.8429
f 616.653.2717

-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-***@LISTSERV.UA.EDU] On Behalf Of R.S.
Sent: Wednesday, June 27, 2018 10:47 AM
To: IBM-***@LISTSERV.UA.EDU
Subject: ICSF and millions of RSA keys

**CAUTION EXTERNAL EMAIL**

**DO NOT open attachments or click on links from unknown senders or unexpected emails**

Usually ICSF use the key kept in its repositories - CKDS for symmetric keys and PKDS for assymetric cryptography.
There is a plan to use several millions of public keys (private key reside out of the mainframe).
Some questions and doubts:
1. Is it good idea to have millions of keys in PKDS? Would it be a problem for ICSF? VSAM limits seem to be not a problem, but maybe ICSF have some bottlenecks or limitations.
2. Can I keep the keys out of PKDS, for example in DB2 table? Note, we talk about public key, so there is no big reason to keep it secret.
For example: tell ICSF to check msg using given key value, instead of given key label. I remeber such solution is feasible for symmetric keys (the key was encrypted using Master Key).
3. What about performance? While DB2 table can be buffered, what about PKDS? Does it require I/O for every key use?

--
Radoslaw Skorupka
Lodz, Poland




======================================================================


--
Treść tej wiadomości może zawierać informacje prawnie chronione Banku przeznaczone wyłącznie do użytku służbowego adresata. Odbiorcą może być jedynie jej adresat z wyłączeniem dostępu osób trzecich. Jeżeli nie jesteś adresatem niniejszej wiadomości lub pracownikiem upoważnionym do jej przekazania adresatowi, informujemy, że jej rozpowszechnianie, kopiowanie, rozprowadzanie lub inne działanie o podobnym charakterze jest prawnie zabronione i może być karalne. Jeżeli otrzymałeś tę wiadomość omyłkowo, prosimy niezwłocznie zawiadomić nadawcę wysyłając odpowiedź oraz trwale usunąć tę wiadomość włączając w to wszelkie jej kopie wydrukowane lub zapisane na dysku.

This e-mail may contain legally privileged information of the Bank and is intended solely for business use of the addressee. This e-mail may only be received by the addressee and may not be disclosed to any third parties. If you are not the intended addressee of this e-mail or the employee authorized to forward it to the addressee, be advised that any dissemination, copying, distribution or any other similar activity is legally prohibited and may be punishable. If you received this e-mail by mistake please advise the sender immediately by using the reply facility in your e-mail software and delete permanently this e-mail including any copies of it either printed or saved to hard drive.

mBank S.A. z siedzibą w Warszawie, ul. Senatorska 18, 00-950 Warszawa, www.mBank.pl, e-mail: ***@mBank.plSąd Rejonowy dla m. st. Warszawy XII Wydział Gospodarczy Krajowego Rejestru Sądowego, nr rejestru przedsiębiorców KRS 0000025237, NIP: 526-021-50-88. Według stanu na dzień 01.01.2018 r. kapitał zakładowy mBanku S.A. (w całości wpłacony) wynosi 169.248.488 złotych.


----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
**CAUTION EXTERNAL EMAIL**

**DO NOT open attachments or click on links from unknown senders or unexpected emails**


This e-mail transmission contains information that is confidential and may be privileged. It is intended only for the addressee(s) named above. If you receive this e-mail in error, please do not read, copy or disseminate it in any manner. If you are not the intended recipient, any disclosure, copying, distribution or use of the contents of this information is prohibited. Please reply to the message immediately by informing the sender that the message was misdirected. After replying, please erase it from your computer system. Your assistance in correcting this error is appreciated.

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Todd Arnold
2018-06-28 13:10:38 UTC
Permalink
I sent this question on to someone on the ICSF development team.

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Todd Arnold
2018-06-28 17:12:30 UTC
Permalink
Here are the answers from my friends on the ICSF development team.
Post by R.S.
1. Is it good idea to have millions of keys in PKDS? Would it be a
problem for ICSF? VSAM limits seem to be not a problem, but maybe ICSF
have some bottlenecks or limitations.
There will be no problem for ICSF to store 2 to 3 million public keys in the PKDS.
Post by R.S.
2. Can I keep the keys out of PKDS, for example in DB2 table? Note, we
talk about public key, so there is no big reason to keep it secret.
For example: tell ICSF to check msg using given key value, instead of
given key label. I remeber such solution is feasible for symmetric keys
(the key was encrypted using Master Key).
Yes, you can store the key tokens outside the PKDS. Callable services accept a label or key token. PKA public keys are in the clear, so there is no security issues.
To be clear, I would only recommend keeping public keys outside the PKDS. Private keys should be maintained in the PKDS so they are properly reenciphered during a master key change.
Post by R.S.
3. What about performance? While DB2 table can be buffered, what about
PKDS? Does it require I/O for every key use?
During initialization, ICSF copies the PKDS into 64 bit storage. When a label is passed to a callable service, ICSF retrieves the key token from the in-store PKDS. No I/O is performed during the retrieval

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
R.S.
2018-07-02 08:29:01 UTC
Permalink
Arnold,
Thank you very much for your help, I appreciate it.

When talking about performance I also thouth about key "life management"
like new key, key change, key delete. I don't expect it would be very
frequent operation, but even that in multi-milion (10-20M rather than
2-3M) key database can be an issue.

Regards
--
Radoslaw Skorupka
Lodz, Poland
Post by Todd Arnold
Here are the answers from my friends on the ICSF development team.
Post by R.S.
1. Is it good idea to have millions of keys in PKDS? Would it be a
problem for ICSF? VSAM limits seem to be not a problem, but maybe ICSF
have some bottlenecks or limitations.
There will be no problem for ICSF to store 2 to 3 million public keys in the PKDS.
Post by R.S.
2. Can I keep the keys out of PKDS, for example in DB2 table? Note, we
talk about public key, so there is no big reason to keep it secret.
For example: tell ICSF to check msg using given key value, instead of
given key label. I remeber such solution is feasible for symmetric keys
(the key was encrypted using Master Key).
Yes, you can store the key tokens outside the PKDS. Callable services accept a label or key token. PKA public keys are in the clear, so there is no security issues.
To be clear, I would only recommend keeping public keys outside the PKDS. Private keys should be maintained in the PKDS so they are properly reenciphered during a master key change.
Post by R.S.
3. What about performance? While DB2 table can be buffered, what about
PKDS? Does it require I/O for every key use?
During initialization, ICSF copies the PKDS into 64 bit storage. When a label is passed to a callable service, ICSF retrieves the key token from the in-store PKDS. No I/O is performed during the retrieval
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
.
======================================================================


--
Treść tej wiadomości może zawierać informacje prawnie chronione Banku przeznaczone wyłącznie do użytku służbowego adresata. Odbiorcą może być jedynie jej adresat z wyłączeniem dostępu osób trzecich. Jeżeli nie jesteś adresatem niniejszej wiadomości lub pracownikiem upoważnionym do jej przekazania adresatowi, informujemy, że jej rozpowszechnianie, kopiowanie, rozprowadzanie lub inne działanie o podobnym charakterze jest prawnie zabronione i może być karalne. Jeżeli otrzymałeś tę wiadomość omyłkowo, prosimy niezwłocznie zawiadomić nadawcę wysyłając odpowiedź oraz trwale usunąć tę wiadomość włączając w to wszelkie jej kopie wydrukowane lub zapisane na dysku.

This e-mail may contain legally privileged information of the Bank and is intended solely for business use of the addressee. This e-mail may only be received by the addressee and may not be disclosed to any third parties. If you are not the intended addressee of this e-mail or the employee authorized to forward it to the addressee, be advised that any dissemination, copying, distribution or any other similar activity is legally prohibited and may be punishable. If you received this e-mail by mistake please advise the sender immediately by using the reply facility in your e-mail software and delete permanently this e-mail including any copies of it either printed or saved to hard drive.

mBank S.A. z siedzibą w Warszawie, ul. Senatorska 18, 00-950 Warszawa, www.mBank.pl, e-mail: ***@mBank.plSąd Rejonowy dla m. st. Warszawy XII Wydział Gospodarczy Krajowego Rejestru Sądowego, nr rejestru przedsiębiorców KRS 0000025237, NIP: 526-021-50-88. Według stanu na dzień 01.01.2018 r. kapitał zakładowy mBanku S.A. (w całości wpłacony) wynosi 169.248.488 złotych.


----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Loading...