The problem to be solved is this. Spoofed sites can acquire user credentials, especially passwords, and then use those to impersonate the user on the real sites. With paypal and e-gold, this allows stealing real money.
Using client certificates to authenticate would solve this, because even if the user got fooled and authenticated to the spoofed site, the attacker wouldn't learn the client cert secret key and so would not be able to masquerade as the user.
The problem (among others) is that this allows a virus to steal the client cert. If it is protected by a password, the malware must hang around long enough for the user to unlock the cert (perhaps because the malware sent a spoofed email calling for the user to visit the site, even the real site!). It can then read the user's keystrokes and acquire the password. Now it has the cert and password and can impersonate the user at will.
slight nit .... the solution is non-shared secret in conjunction with something you have authentication implementing, digital signatures, public/private keys where the private key is never divulged .... even to the owner (the private key housing can be hardware token ... or something embedded in the computer).
it seems that certificates sometimes are considered synonymous with public/private key and digital signatures. however, certificates were originated to address a specific issue with key distribution and trust involving parties that 1) had no prior business relation, 2) were unlikely to have any future business relationship, and 3) didn't have online access to trusted 3rd party. however, it is actually much more natural in a standard business process setting that public key is registered in lieu of shared-secret authentication material when parties are involved that have established business relationship (aka for example a person with some sort of an account, especially in any sort of online paradigm). A trivial examples is certificateless operation with public/private keys for radius, kerbers pk-init or x9.59 standard for all retail payment transactions (internet, non-internet, point-of-sale, debit, credit, ach, stored-value, etc).
Also note, a certificate tends to only contain the owners public key and some other information about the owner (and nominally is assumed to be freely distributable, somewhat in the same way the PGP keyserver information is published). The certificate doesn't contain the private key ... which tends to be either in a software encrypted file or an external hardware token.
for the various possible types of social engineering & virus exploits, eliminating shared secrets is only a partial solution (although shared secrets have a number of vulnerabilities and exploits, so eliminating shared secrets is not a bad thing)., if the individual has direct access to the private key in anyway, then it is possible to compromise that access. That is where some flavor of "something you have" authentication comes in with hardware that houses the private key and there is no way to divulge the private key, even to the owner. EU finread (financial reader) has an external reader with its own display and pin-pad. This addresses the issue (even with something you have hardware token) where a viirus can 1) display one value on the screen and send another value to the token for signing and 2) spoof keystroke entry with the correct PIN (perform fraudulent transactions w/o the owners knowledge).
If the
1) private key can never be directly physically accessed,
2) the digital signature is taken to represent a form of something you have authentication.
3) the display can be trusted to always display what will be signed
4) the keypad can't be spoofed and actually requires the person to hit the keys
5) hardware token never signs anything unless there has been (human) keypad entry
then the remaining types of fraud will tend to be no different than the phone scams, mail scams and the people coming to your door scams .... effectively no different than the types of fraud that has been going on for hundreds/thousands of years.
--
Anne & Lynn Wheeler http://www.garlic.com/~lynn/
Internet trivia 20th anv http://www.garlic.com/~lynn/rfcietff.htm
--------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
