Anne & Lynn Wheeler <[EMAIL PROTECTED]> writes: > That very theory is what the MasterCard and Visa networks are > supposed to be proving with SET, the Secure Electronic Transaction > protocol, which requires digital certificates for banks, merchants, > and cardholders. A purchaser would use the digital code, rather than > a card number, to initiate a transaction; the certificate would > represent authentication by a bank or other certificate authority. > > SET has gained some acceptance overseas but almost none in the > United States, therefore contributing little to the mainstreaming of > digital certification. > > The concept has, however, attained some level of business-world > consciousness through initial public offerings this year by two > specialists in the field, Verisign Inc. and Entrust Technologies > Inc. These companies and others stand ready to give banks the > software or outsourcing support they need to authenticate people > doing business facelessly on the World Wide Web.
two issues from the historical news article posting http://www.garlic.com/~lynn/2005l.html#34 More Phishing scams, still no SSL being used is that their "light" digital certificates are also referred to has relying-party-only certificates http://www.garlic.com/~lynn/subpubkey.html#rpo ... since rather than carrying the actual information, they just carry some sort of index pointer into a business relationship management infrastructure (like account number). the relationship management infrastructure contains all the real information. however, it is trivial to show that such "light" certificates are redundant and superfluous when the business process has to access the infrastructure containing the real information. this is also somewhat a trivial logic operation when you take the original design point for digital certificates is providing relying parties with information in an offline environment when the relying parties had no other recourse to the real information; aka therefor by definition, if the relying parties have access to the real information ... the original purpose and justification for digital certificates is invalidated. the other issue is that even for "light" certificates the infrastructure overhead for appending certificates ran 4k to 12k bytes. when you are talking about the basic payment card infrastructure where typical message size is 60-80 bytes, the appended certificate paradigm represents an enormous payload bloat of one hundred times (two orders of magnitude) ... for otherwise redundant and superfluous certificates. the basic technology is asymmetric key cryptography, where what one key (of a key-pair) encodes, the other of the key-pair decodes. a business process has been defined called public key ... where one of the key-pair is made freely available and the other key is identified as private and kept confidential and never divulged. a further business process has been defined called digital signature ... which represents "something you have" authentication ... from 3-factor authentication paradigm http://www.garlic.com/~lynn/subpubkey.html#3factor * something you have * something you know * something you are digital signatures implies that some entity has access and (presumably sole) use of a specific private key. existing relationship management infrastructures can upgrade their shared-secret based authentication http://www.garlic.com/~lynn/subpubkey.html#secret to digital signature, by registering a public key in lieu of pin, password, ssn, date-of-birth, mother's maiden name, etc. while in secret-based infrastructures, the same value is used to both originate as well as authenticate. in public key scenario for digital signature, the public key is only used to authenticate (and can't be used to originate or impersonate). from the PAIN security acronym P ... privacy (or sometimes CAIN, confidential) A ... authenticate I ... integrity N ... non-repudiation it can be easily demonstrated that relationship management infrastructures tend to have very high integrity reguirements (regarding all details of the relationship as well as the authentication information). however, many business infrastructures that make heavy use of their relationship management infrastructure for numerous business process are also at risk of exposing the authentication information. when this authentication information is public key, it tends to not be a big deal. however, when the authenticaton material are secrets, then there is an enormous privacy requirement (since obtaining the secrets also enables impersonation, fraudulent transactions, account fraud, etc). Using secret-based authentication can create enormous dynamically opposing objectives for relationship management infrastructure ... on one hand the relationship management infrastructure has to be readily available in support of numerous business operations .... and on the other hand, the secret-based privacy requirements are none but extremely constrained business operations can access the information. one such description is my old security proportional to risk posting http://www.garlic.com/~lynn/2001h.html#63 and a whole host of postings on skimming and harvesting of (secret-based) authentication material (that can be leveraged to perform fraudulent transactions) http://www.garlic.com/~lynn/subpubkey.html#harvest as an aside ... there was a report within the past couple years that something like 70 percent of identity/account fraud involved insiders. there has been some additional, similar reports. there were a number of these news URLs in the past couple days: Bank workers biggest ID theft threat; Insiders with access to data may pose 70% to 80% of risk http://deseretnews.com/dn/view/0,1249,600145529,00.html Banks Face Challenge In Screening Employees To Avert Inside ID Thefts http://www.banktech.com/aml/showArticle.jhtml?articleID=164904297 -- Anne & Lynn Wheeler | http://www.garlic.com/~lynn/ _______________________________________________ mozilla-crypto mailing list [email protected] http://mail.mozilla.org/listinfo/mozilla-crypto
