[17520] in cryptography@c2.net mail archive
Re: massive data theft at MasterCard processor
daemon@ATHENA.MIT.EDU (Anne & Lynn Wheeler)
Tue Jun 21 16:04:52 2005
X-Original-To: cryptography@metzdowd.com
X-Original-To: cryptography@metzdowd.com
Date: Tue, 21 Jun 2005 06:27:59 -0600
From: Anne & Lynn Wheeler <lynn@garlic.com>
To: Peter Fairbrother <zenadsl6186@zen.co.uk>
Cc: "Steven M. Bellovin" <smb@cs.columbia.edu>,
cryptography@metzdowd.com
In-Reply-To: <BEDD25DC.A8A89%zenadsl6186@zen.co.uk>
Peter Fairbrother wrote:
> Also there are several attacks on Chip n' PIN as deployed here in the UK,
> starting with the fake reader attacks - for instance, a fake reader says you
> are authorising a payment for $6.99 while in fact the card and PIN are being
> used to authorise a transaction for $10,000 across the street. They get
> quite complex, there's the double-dip, where the $6.99 transaction is also
> made, and the delayed double dip, where a reader belonging to a crook makes
> the $10,000 transaction several days later (the crook has to skip town with
> the money in this attack - so far. Except of course he never existed in the
> first place, and maybe ...).
the payment infrastructure requires a financial institution taking
responsibility for a merchant to connect into the network ... and the
settlement into the merchant account nominally flows thru the sponsoring
merchant financial institution. for a merchant not to actually exist
would require some lapse on the sponsoring financial institution ...
i.e. some of the anonomous stored-value specifications tried to simulate
direct cash-like transfer between two tokens .... but the existing
payment networks are far from that, requiring a bit more deception
on the part of any fraudulent merchant.
note that some of the transaction authentication specifications don't
necessarily match x9.59 financial standard in also specifying that a PAN
in an authenticated transaction can't be used in a non-authenticated
transaction. recent post reference
http://www.garlic.com/~lynn/aadsm19.htm#38
http://www.garlic.com/~lynn/2005k.html#55
http://www.garlic.com/~lynn/2005k.html#56
i.e. which still leaves open the various harvesting vulnerabilities. the
x9.59 financial standard specified that both
1) transactions have to be individually authenticated (account-level
authentication with the issuing institution) and
2) the same PAN used in authenticated transactions can't be used in
non-authenticated transactions (countermeasure to harvesting
vulnerability where crook could utilize information for later fraudulent
transactions)
misc. x9.59
http://www.garlic.com/~lynn/index.html#x959
http://www.garlic.com/~lynn/subpubkey.html#privacy
---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo@metzdowd.com
