Perry E. Metzger wrote: > That system has a number of flaws in it, including the fact that it is > not an end to end cryptographically protected communication, and is > thus subject to credential theft and the customer PIN is exposed to a > reader provided by the merchant. I think with the right design, most > such issues might go away.
a lot the big news articles about data breaches are related to being able to do account fraud against the payment system .... just from electronic records. this is basically static data that can leveraged to directly performing electronic account fraud and/or being able to create counterfeit cards and performing fraudulent transactions. similar to the database harvesting exploits are the skimming exploits where electronic recording of transactions are performed .... there have even been crime tv shows about ATM overlays and pin-hole cameras as part of skimming activities. again the electronic recording is sufficient for creating counterfeit cards and performing fraudulent transactions. lots of past posts related to harvesting and skimming http://www.garlic.com/~lynn/subpubkey.html#harvest the above includes some number of past posts about the target databases provide much bigger fraud return-on-investment than evesdropping for e-commerce transactions. slightly related is old security proportional to risk posting http://www.garlic.com/~lynn/2001h.html#61 the other way of viewing this is that the knowledge of the account number and/or the static data magstripe card are taken as authentication which enables the performing of an unauthenticated transactions. This can be interpreted as both a form of replay-attack (replaying the authentication to enable to the execution of an unauthenticated transactions) and a MITM-attack (i.e. the crooks slipping into the cracks between the simple authentication and the unauthenticated transactions). as mentioned in past posts on x9.59, http://www.garlic.com/~lynn/index.html#x959 http://www.garlic.com/~lynn/subpubkey.html#privacy the x9a10 working group was tasked with preserving the integrity of the financial infrastructure for all retail payments. this resulted in two business rules 1) strongly authenticated transactions .... example mapping to iso 8583 payment transactions used ecdsa with public keys registered at the issuing bank ... there were pki-based payment specifications in the same period as the original x9.59 standards work. even when they retrenched to relying-party-only certificates to mitigate severe privacy and liability issues with x.509 identity certificates http://www.garlic.com/~lynn/subpubkey.html#rpo the certificate overhead was still on the order of 4k-12k bytes. for typical iso 8583 message sizes of 60-80 bytes, this represented a factor of one hundred times payment bloat for redundant and superfluous PKI operation 2) account numbers used in x9.59 transactions, if used in non-x9.59 transactions would not be authorized. the first business rule made it difficult to counterfeit x9.59 transactions (and made them business process friendly, especially compared to some of the PKI-oriented specifications). the second business rule eliminated harvesting/skimming of x9.59 account numbers as a threat/vulnerability. the issue here is that account numbers are used in dozens of business processes .... and even if the earth was buried miles deep in cryptography attempting to maintain privacy/confidentiality of the account numbers ... there would still be account number leakage. x9.59 recognizing that such leakage would be essentially impossible to stop ... attempted to eliminated such account number leakage as a threat and vulnerability. so, as in earlier statements ... this would still leave merchant misrepresentation as a threat and vulnerability. the problem is that that is fairly quickly identified and shutdown. a big threat/vulnerability in the harvest/skimming scenario is that the crooks attempt to perform the fraud as far away as possible from the source of compromise (maximizing the benefit of the compromised source). Fraud being performed at the point of compromise tends to have a much shorter lifetime. recent post http://www.garlic.com/~lynn/aadsm19.htm#38 massive data theft at MasterCard processor that leaves the old-fashion waving guns and social engineering. waving guns tends to have much lower fraud return on investment (especially when transactions tend to be limited to hundreds of dollars and lost/stolen reports can shut off the account). if simple harvesting/skimming has been eliminated .... like data breaches ... then similar harvesting thru social engineering isn't going to work much better. you are back to something similar to the merchant misrepresented transactions .... except this is a social engineering misrepresented transaction (rather than social engineering skimming/harvesting). chips by themselves are not necessarily a panecea. there have been past chip-based systems that have simple static data authentication ... making their threat/vulnerabilities little different than magstripe threat/vulnerabilities. there have also been MITM attacks on chips where the chip does dynamic data authentication ... and then proceed to do unauthenticated transactions. this can also be represented as separating authentication and authorization ... and the crooks slip into the cracks between the authentication and the authorization. lots of past fraud, threats, and vulnerability posts http://www.garlic.com/~lynn/subpubkey.html#fraud --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
