I'm going to be reading this response several times just so i understand
it fully, but thanks I'd love your rexx exec.
Mark Jacobs
On 01/18/13 21:06, Frank Swarbrick wrote:
Is this a key that already exists in your system, and one where you don't actually know
what the key is (because its encrypted under your ICSF Symmetric Master Key? Or are you
wanting to "generate" a new key and share that key with another system?
In either case, if you don't want to use Public Key cryptography, (and assuming you don't want to
send a plaintext key!) you need to create multiple key parts which will be combined in order to
create the key. This key will either be the actual "working key" you wish to share, or
it will make up a "transport key" under which you will later encrypt your already
existing (operational) working key.
To create this first key (whether it be the actual working key or a transport key used to encrypt (wrap) a working key)
you need to generate two or more (usually three) random numbers of the proper size (probably 16 bits; a double-length
key). You can use the RANDOM function in the ICSF Utilities ISPF panel, or really you can use any sort of random
number generator. For however many of these random numbers (they "key parts") you want (lets say 3) you
properly should have them generated in private by 3 separate people. Each of these three people will then write down
their "key part" (their 16-bit random number), in hex form (32 hex digits) on a piece of paper. The papers
with the key parts should be inserted into 3 tamper evident envelopes by the three "key part custodians" and
should be delivered to 3 "key part custodians" at the partner's site.
These three key parts will then be combined to form the actual key. In an ICSF/CCA system you use the Key
Part Import API service (CSNBKPI) to do this. You will then want to perform a Key Test function (CSNBKYT) on
the new key (which is now encrypted under your ICSF SYM Master Key). The result of this test will be a 4
byte (8 hex digit) "key check value" which you will want to communicate to your partner. This way
they can perform the "key part import" (sometimes known as "key part combine") on their
system and generate the key check value. As long as they get the same key check value that you got, the keys
are now properly paired and (hopefully!) encrypted under each partner's appropriate Master Key.
I have a nice REXX EXEC that I can give you that allows you to easily perform
the following functions:
1) Create a key token for the selected key type (EXPORTER, DATA, or whatever)
2) Import a key part
3) After all key parts have been imported, do a final key part import to complete the
import and "finalize" the creation of the key.
4) Return the appropriate KCV for each key part, as well as for the final
combined key.
Step 2 is performed once per key part.
Each step can (should) be performed by separate individuals. The first and third steps would probably be the
same (fourth!) person, while the 3 "part 2" steps should be performed by the 3 custodians of the
key parts. Each of these 4 persons (in a pinch "person number 4" can be the same person as one of
the custodians) needs to have SAF authority to perform the KPI and KYT functions (and probably others I am
forgetting). "Person number 4" additionally needs to be able to have authority to create a key
token (CSNBKTC).
Assuming this key is the actual working key, once both partners have imported
and combined their key parts you are ready to communicate.
If the key you shared in this manner is only a transport key then you have
additional steps. If you are writing a program to invoke ICSF/CCA API calls to
generate a new key and encrypt it for transport do the following. If you want
to use KGUP instead I'll have to research it further, as I have not done it
that way.
You will want to use the Key Generate service (CSNBKGN) to generate (within the
secure crypto processor) a random key (of the appropriate length). The key
will be both
1) Encrypted under the ICSF SYM Master Key and returned to your application as
an INTERNAL key token,
2) and encrypted under the transport key (which you have supplied to the KGN
service) and returned to your application as an EXTERNAL key token.
You will then "extract" the encrypted form the EXTERNAL key token. The
encrypted key (assuming a double length key) is bytes 16 - 31 (16 bytes) of the 64 byte
external key token. You will communicate this value to your partner who will then import
it into their system using whatever processes they have available to do so.
Warning: If your working key is not a DATA or MAC key, but is rather (most of) one of the
other key types there is an issue with CCA "control vectors" that needs to be
considered. I just yesterday learned how do work with this issue if the peer is using a
non-CCA system, but I won't go into more details at this point, other than to say it
involves the Control Vector Translate service (CSNBCVT).
Hope I answered, in at least a somewhat understandable way, your (or at least someone's!)
questions. Feel free to contact me for further help, and/or if you wish my "key
management" REXX EXEC.
Frank
________________________________
From: Mark Jacobs <[email protected]>
To: [email protected]
Sent: Friday, January 18, 2013 10:24 AM
Subject: Re: ICSF Symmetric Key being sent to a non-zOS system
Yes, but I need to export a secure key to another platform. I don't
believe I can export a secure key using the ICSF api's without wrapping
it in an export key. The one piece of the puzzle that i don't have is,
how does the non-zOS target platform unwrap the symmetric key from the
exporter key so they can import it into their system.
Mark Jacobs
On 01/18/13 09:50, Steve Finch wrote:
Look at the Digital Certificate exchange process. It is the basis of SSL
(HTTPS, SSH, Secure FTP).
It should be supported on most platforms. It uses assymetric cryptography to
encrypt the crypt the symmetric key. And the RSA encryption does use a bunch of
CPU for a brief moment to encrypt the symmetric key.
Steve
RPS
-----Original Message-----
From: IBM Mainframe Discussion List [mailto:[email protected]] On Behalf
Of Mark Jacobs
Sent: Thursday, January 17, 2013 3:23 PM
To: [email protected]
Subject: ICSF Symmetric Key being sent to a non-zOS system
I've been reading the ICSF Applications Programmers guide and I understand the
process on how to transport ICSF keys to another zOS system using
importer/exporter keys, but I have no idea on how it would work on a non-zOS
platform.
Can anyone point me to some doc, or share their process if they've already done
it?
--
Mark Jacobs
Time Customer Service
Tampa, FL
----
The quiet ones are the ones that change the universe...
The loud ones only take the credit.
Londo Mollari - Babylon 5
----------------------------------------------------------------------
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
--
Mark Jacobs
Time Customer Service
Tampa, FL
----
The quiet ones are the ones that change the universe...
The loud ones only take the credit.
Londo Mollari - Babylon 5
----------------------------------------------------------------------
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
--
Mark Jacobs
Time Customer Service
Tampa, FL
----
The quiet ones are the ones that change the universe...
The loud ones only take the credit.
Londo Mollari - Babylon 5
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
