payment system fraud, etc.

[Anne & Lynn Wheeler]

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 majordomo at metzdowd.com