"Anders Rundgren" <[EMAIL PROTECTED]> writes: > I don't believe in that model anymore. 3D offers so > much more possibilities for integration in purchasing > systems which the classic model cannot do. Neither > can AADS. It is like "federation" for payments.
as an aside ... the threat and vulnerability analysis done by the financial standards x9a10 working group (charged with preserving the integrity of the financial infrastructure for all retail payments) in the mid-90s, didn't find issues with trust, business, and/or message flows of the existing iso 8583 standard transactions. the issue in the x9.59 standards word http://www.garlic.com/~lynn/index.html#x959 http://www.garlic.com/~lynn/subpubkey.html#privacy was the treats and vulnerabilities in the authentication technology and athat the integrity level has possibly eroded over the past 30 years or so (in the face of technology advances). the primary issue was the authentication of the consumer for the transaction. this cropped up in two different aspects 1) is the consumer originating the transaction, really the entity that is authorized to perform transactions against the specific account 2) somewhat because of authentication integrity issues, starting at least in the 90s, there was an increase in skimming and harvesting ... either direct skimming of the magnetic stripe information or harvesting of account transaction databases ... both supporting later counterfeiting activities enabling generation of fraudulent transactions http://www.garlic.com/~lynn/subpubkey.html#harvest the countermeasure corner stones of x9.59 then became: 1) use technology for drastically increasing the authentication strength directly associated with transactions ... as a countermeasure to not being sure that the entity originating the transaction is really the entity authorized to perform transactions for that account. 2) business rule that PANs (account numbers) used in strongly authenticated transactions aren't allowed to be used in poorly or non-authentication transactions (or don't authorize poorly authenticated transaction having a PAN that is identified for use only in strongly authenticated transactions). this is a countermeasure to the skimming/harvesting vulnerabilities and exploits. there was a joke with regard to the second countermeasure corner stone that you could blanket the world in miles deep cryptography and you still couldn't contain the skimming/harvesting activities. the second corner stone just removes skimming/harvesting as having any practical benefit in support of crooks and fraudulent transactions. slightly related post on security proportional to risk: http://www.garlic.com/~lynn/2001h.html#61 recent similar posting in another thread: http://www.garlic.com/~lynn/2005k.html#23 http://www.garlic.com/~lynn/aadsm16.htm#20 having helped with the deployment of the e-commerce ssl based infrastructure http://www.garlic.com/~lynn/aadsm5.htm#asrn2 http://www.garlic.com/~lynn/aadsm5.htm#asrn3 we recognized a large number of situations where PKIs that had originally been designed to address trust issues between relying parties and other entities that had no prrevious contact ... were being applied to environments that had long term and well established trust and relationship management infrastructure (aka if i have a relationship management infrastructure that provides long-term and detailed trust history about a specific relationship ... then a PKI becomes redundant and superfluous as a trust establishment mechanism). In the AADS model http://www.garilc.com/~lynn/index.html#aads involving certificate-less public key operation http://www.garlic.com/~lynn/subpubkey.html#certless we attempted to map publickey-based authentication technology into existing and long-term business processes and relationship management infrastructures. the existing authentication landscape is largely shared-secret based http://www.garlic.com/~lynn/subpubkey.html#secret where the same information that is used for originating a transaction is also used for verifying a transaction. this opens up harvesting vulnerabilities and treats against the verification repositories. basically asymmetric cryptography is a technology involving pairs of keys, data encoding by one key is decoded by the other key. a business process has been defined for asymmetric cryptography where one of the key pair is designated "public" and can be widely distributed. The other of the key pair is designated "private" and kept confidential and never divulged. a futher business process has been defined call "digital signatures" where a hash of some message or document is encoded with a private key. later a relying party can recalculate the hash of the same message or document, decode the digitial signatures with the corresponding public key and compare the two hashes. if the two hashes are the same ... then the relying party can assume: 1) the message/document hasn't been modified since being digitally signed 2) "something you have" authentication, aka the originating entity has access to, and use of the corresponding private key. an additional business process was created called PKIs and certification authorities that was targeted at the environment where a relying party is dealing with first time communication with a stranger and has no other recourse for trust establishment about the total stranger. note however, that PKIs and certification authorities can be shown to be redundant and superfluous in envrionments where the relying party has long established business processes and trust management infrastructures for dealing with pre-existing relationships. However, just because PKIs and certification authority business processs can be shown to be redundant and superfluous in most existing modern day business operations ... that doesn't preclude digital signature technology being used (in a certificateless environment) as a stronger form of authentication (relying on existing and long estasblished relationship management processes for registering a public key in lieu of shared secret based authentication material). leveraging long established relationship management infrastructures for registering public key authentication material in lieu of shared-secret authentication material (and use of public key oriented authentication) is a countermeasure to many kinds of harvesting and skimming vulnerabilities and threats. Many of the identity theft reports result from havesting/skimming of common, static, shared-secret authentication material for later use in fraudulent transactions. The advantage of public key based authentication material, is that while it can be used for authentication purposes, it doesn't have the short-coming of also being useable for originating fraudulent transactions and/or impersonation. -- Anne & Lynn Wheeler | http://www.garlic.com/~lynn/ _______________________________________________ mozilla-crypto mailing list [email protected] http://mail.mozilla.org/listinfo/mozilla-crypto
