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
