llo...@gmail.com (Lou Losee) writes:
> Yes you are correct that you have to initiate your trust somewhere.  The
> paradigm is that you trust the vendor that delivers the CA certificates to
> you (e.g., Mozilla, Microsoft, IBM, etc.)
> Hand delivering keys defeats the purpose of using certificates.  If you
> were going to hand deliver keys, you might as well just use a symmetric
> cipher rather than asymmetric. If you want perfect unbreakable encryption
> then you should hand deliver one time pads between the parties.

re:
http://www.garlic.com/~lynn/2018c.html#28 Software Delivery on Tape to Be 
Discontinued

symmetric key ... like passwords ... are shared secrets ... you need a
unique value for every security domain (or use, as countermeasure to
cross domain attacks).

the same single public/private key pair could be used for every security
domain in lieu of unique shared secret ... shifting from an
institutional centric security paradigm to a person centric security
paradigm.

this is somewhat analogous to biometric authentication ... but can work
at a distance rather than requiring person's biometric be physically
present.

the trivial approach is registering a public key in lieu of a
unique pin/password at every institution ... we actually did
example implementations for radius, kerberos and some number
of other widely used authentication infrastructure.

problem was that it would generate no new revenue stream ... and
the ceritication authority industry really wanted their $20B/year

tirivia ... in the digital signature scenario ... some hash (SHA, MD5,
etc) is calculated for the data, the hash encrypted with the private key
and appended to the data. the recipient decrypts the digital signature
with the public key and compares the decruypted value with recalculated
hash. This confirms/authenticates that the original data hasn't been
changes and also confirms/authenticates the sender.

The use in lieu of pin/password ... the institution has to protect
against replay attacks. Rather than the user generating the data that is
signed ... the institution sends the user some unique data. The user
than encrypts the hash of the unique data with their private key and
returns the encrypted hash to the institution (doesn't have to return
the data, since the institution already has it). The institution then
decrypts the returned value with the public key (saved in file that had
previously stored pin/password) and compares it with the hash of the
originally transmitted value.

There is no longer a danger of pin/passwords being skimmed or the
pin/password file being copied ... and in fact can be transmitted
completely in the clear (w/o any additional encryption).

We used this for the X9.59. Financial industry started out saying
that they could not trust some other certification authority and
would only recognize "relying party only certificates" (i.e. only
recognize certificates that they had issues).

However, a certification authority has to create a business process that
does background on the public key and then save the public key in some
administration file (before issuing a certificate).  However, for a
financial institution, that would all be collapsed in account
record. But in any sort of financial authentication, it involves
accessing the account record ... where the public key has been stored
... having it also in appended digital certificate (that is typically
100 times larger than financial transaction) is then redundant and
superfluous (since a financial institution will already have the public
key).

Then for the whole financial industry, certificates became
unnecessary. Also since X9.59 account transactions could only be done
with public key (digital signature) ... crooks were no longer able to do
fraudulent transaction against an x9.59 w/o the corresponding private
key. Since the private key was never divulged ... it was no longer
necessary to hide/encrypt/ssl/tls such financial transactions (skimming,
breaches, evesdropping, wern't prevented, but the risk of crooks
being able to use the information was eliminated).

One of the things that the transit industry then asked was if I could
design a chip that could do such transactions and be implemented in a
contractless transit card (i.e. amount of power for doing calculations
is severely limited) and time constraint of turnstyle (1/10 sec or
less). Turns out using a variation of ECC would be as strong or stronger
than RSA ... and do the calculations within the power and time
constraints of a transit contactless turnstyle.

other trivia: its certification authority ... not certificate authority
... the service provided is certification (some correspondance between
the public key and some entity) ... which is then encapsulated in a
certificate. However, since fine print frequently says that the
certification has no warrenty ... there is frequent disire to distract
the market ... and make believe that the certificate by itself has some
magic pixie dust property.

-- 
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

Reply via email to