Mark, Haven't had to do it.. but here are a couple of ideas.
http://www-01.ibm.com/support/docview.wss?uid=isg3T1010756 http://tools.ietf.org/html/draft-hoyer-keyprov-portable-symmetric-key-container-02 Once the key material is clear.. there are a plethora of ways to encrypt it that would be compatible on the other platforms. This has a plethora of OpenSSL uses.. one was how to encrypt an encryption key. http://security.ncsa.illinois.edu/research/grid-howtos/usefulopenssl.html Unfortunately, OpenSSL doesn't port to z/OS. I am sure the guys at PKWARE can do it... since they run on all the platforms. The only issue is still getting the key out in the clear.. and getting into the next "container" securely. I suppose transporting values that need to be XORed together. ICSF supports a remote key load for ATMs which might be worth a look. If you have OpenPGP running on z/OS... then I suppose you could use it as the transportation vehicle. HTH, Rob Schramm Rob Schramm Senior Systems Consultant Imperium Group On Fri, Jan 18, 2013 at 1:08 PM, Anne & Lynn Wheeler <l...@garlic.com>wrote: > sfi...@recoverypoint.com (Steve Finch) writes: > > 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. > > PKI & Digital Certificate has some smoke and mirrors associated with it. > > Relying party needs secure repository of trusted public keys that is > distributed by some trusted out-of-band process. > > Then the relying party can use public key from their secure respository > to validate some digitially signed information. > > SSL, HTTPS, PKI, etc uses a level indirection. A repository of > (certification authority) "trusted" public keys are embedded in browser > distribution. > > Individuals can present public key to certification authority which does > some validation process and generates a digitally signed (using a > certification authority private key) digital certificate that attests to > some equivalence between something that the individual claimed (like a > name, or url, etc) and the presented public key. > > Subsequently an individual can transmit some digitally signed > information (with their corresponding private key), with their > appended digital certificate. > > The recipient (relying party) validates the CA's issued digital > certificate by using the CA's public key from the previously distributed > trusted repository (part of the browser distribution). Once the digital > certificate has been validated, the recipient can extract the sender's > public key from the digital certificate and validate the sender's > digital signature on the transmitted message (to validate that the > message really originated from the entity that the sender claims to be). > > In SSL, the recipient/client can also generate a session symmetric > secret key, encrypt it with the server/sender's public key (from the > validated digital certificate) and return it to the sender. Only the > originally sender with the corresponding private key can decrypt the > client's generated session symmetric secret key. Subsequent SSL > communication then takes place with the client's session symmetric > secret key > > In any case, for limited environment ... it is possible to exchange your > own public keys out-of-band and keep them in your own trusted repository > for future session key exchange w/o requiring 3rd party digital > certificates (and having out-of-band distribution of the public keys > from digital certificate issuing Certification Authorities kept in your > trusted public key repository). > > lots of disclaimers: > > long ago and far away we were brought in to small client/server startup > that wanted to do payment transactions on their servers, the small > startup had also invented this technology called SSL they wanted to use; > the result is now frequently called "electronic commerce". Along the way > we had to map the technology to payment business operations as well as > establish some requirements for operation and use of SSL (some of which > were almost immediately violated ... resulting in many of the exploits > that continue until this day). some related posts > http://www.garlic.com/~lynn/subnetwork.html#gateway > > we had been brough in to help word-smith the cal. electronic signature > act .... which was under heavy pressure from the certification authority > industry to mandate that electronic signatures could only be done > with digital signatures and digital certificates. some past posts > http://www.garlic.com/~lynn/subpubkey.html#signature > > Some past RSA show, the IBM executive that crypto reported to, was > showing some Certification Authority (now defunct) CEO around the show > ... and insisted on introducing the CEO to me. The CEO asked me what I > did. I said that I was working on eliminating Certification Authorities > from the face of the earth. > > I've frequently pointed out that the SSL Certification Authority > industry is dependent on the domain name system integrity and that > their proposal to improve the integrity of the domain name system > can also result in no longer needing SSL > http://www.garlic.com/~lynn/subpubkey.html#catch22 > > we have dozens of (assigned) patents in the area of public key use > w/o using Certification Authorities and/or digital certificates > http://www.garlic.com/~lynn/aadssummary.htm > > -- > virtualization experience starting Jan1968, online at home since Mar1970 > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
