[email protected] (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 [email protected] with the message: INFO IBM-MAIN
