[Cryptography] EMV as a fraud enabler

Anne & Lynn Wheeler lynn at garlic.com
Wed Oct 29 17:46:12 EDT 2014

On 10/29/14 07:45, John Levine wrote:
>> If I read that article correctly, the main issue is that certain banks
>> didn't bother to verify signatures and as a secondary issue don't
>> bother checking nonce uniqueness either. http://xkcd.com/1181/
> Assuming you mean crypto signatures and not ink signatures, right.  In
> this case it was just bizarre, since the network was approving chip
> transactions for an issuer that wasn't yet certifed to issue chip
> cards.
> A long-standing problem with chip cards is that the banks don't use
> the data they have to validate transactions.  If they actually use the
> data, and track the sequence numbers, they're pretty secure.  But
> through a combination of laziness and the duct-tape-and-baling-wire
> architecture of banking networks, they don't.  When I was attending
> the weekly security seminars at Cambridge a few years ago, this was a
> frequent topic of discussions, ever more ways that banks got chip+pin
> wrong.

There are various quotes about those that don't learn from history are doomed to
repeat the same mistakes.

the current payment infrastructure somewhat grew up during the days of
trusted value added networks (VANs) during the 70s&80s ... which were mostly
obsoleted by the internet over the last 20yrs.

about the time the card associations were first drafting the POS/EMV in Europe,
they also had a totally different group drafting a payment specification for
the Internet. They shared the characteristic that the integrity checking was
being done at the perimeter/boundary ... which is then dependent on internal trusted VAN
(lots of business interest in preserving that status quo) ... however it creates
an enormous attack surface ... both at the boundary/perimeter as well as inside
the infrastructure.

Not long after the early deployment of their internet payment specification, some of
the business people discovered that they were getting transactions that had
flag set that the perimeter had performed the crypto integrity check ... and
they could prove no such crypto was ever involved (not all the different from
the current attacks nearly 20yrs later).

In the internet case, the attempts to preserve the status quo of the existing
payment networks (trusted VAN) were masked by selecting crypto technology the
bloated the payload size of a payment transaction by two orders of magnitude
(100 times) ... resulting in the justification  that the crypto integrity checks
had to be performed at the boundary and only a single bit sent through (indicating
successful integrity check) because the payment networks couldn't stand a factor
of 100 times increase in transaction payload size. Note that there is little or
no evidence of that early standard still in existence.

There were other teething problems with the POS version. There was a large early
deployment in the US during the "YES CARD" period ... it turns out that it was
possible to use the same skimming technology to create a counterfeit magstripe
to create a counterfeit chip. The fraud was actually worse because a countermeasure
to counterfeit magstripe is to deactivate the account number. However for the
"YES CARD", business rules had been moved into the chip ... and a (counterfeit)
chip could tell the POS terminal that correct PIN was entered (regardless of
what was typed), that the transaction was offline (no online checking for deactivated
account) and the transaction was approved. In the wake of the "YES CARD", all
evidence of the US deployment disappears and speculation that it would be quite
some time before it is tried again (the people involved loosing credibility).
Reference to the "YES CARD" at the bottom of this Cartes2002 trip report (gone
404 but lives on at the wayback machine)

disclaimer: we had been brought in as consultants to small client/server startup
that wanted to do payment transactions on their server, they had also invented this
technology called "SSL" they wanted to use; the result is now frequently called "electronic

In part for having done "electronic commerce", we were asked to participate in the
x9a10 financial standard working group (about the same time the card associations
were drafting their POS and internet specifications) which had been given the requirement
to preserve the integrity of the financial infrastructure for *ALL* retail payments.

For this financial transaction standard we slightly tweaked the paradigm and defined
end-to-end integrity ... with fast crypto and minimal payload size so that it could
easily travel through the existing payment networks ... but because of end-to-end
integrity no longer required trusted VANs or hiding the transaction information. As
a result it enormously reduces the attack surface.

Now since the major use of SSL in the world today is this early ecommerce work for hiding
transaction details ... the standard also eliminates the requirement for SSL for that purpose.
It also eliminates the motivation for most of the current financial breaches since
crooks can't use the information from previous transactions for fraudulent transactions.

virtualization experience starting Jan1968, online at home since Mar1970

More information about the cryptography mailing list