Comments: Fraudwatch - Chip&PIN one-sided story, banks and deception and liability shifts

mention of IBM SDA chip&pin deployment for UK Safeway in 1997
http://www.garlic.com/~lynn/2006l.html#33

not too long later the cloned "yes cards" appeared; a reference to counterfeit sda chip&pin "yes card" from 2002 (which also mentions that detailed information for building a counterfeit "yes card" was readily available from the internet)
http://web.archive.org/web/20030417083810/http://www.smartcard.co.uk/resources/articles/cartes2002.html

then SDA chip&pin in 2006, vulnerable to the same "yes card" exploits from the 90s. a recent summary of some of the issues
http://www.garlic.com/~lynn/2006o.html#40

subsequent news mentioned that replacement DDA chip&pin cards would be countermeasure to the 90s counterfeit cloned SDA chip&pin "yes cards". however, if it is still purely "something you have" authentication, ... see discussion
http://www.garlic.com/~lynn/2006o.html#40

the infrastructure may still be vulnerabile to mitm-attacks (pairing a counterfeit "yes card" with a valid card).
http://www.garlic.com/~lynn/subpubkey.html#mitm

in the SDA chip&pin dating back to the mid-90s, supposedly there is multi-factor authentication, the "something you have" card (based on the card being able to present static authentication data) and the "something you know" PIN entry.

for a "counterfeit" yes card, involves copying the static authentication data from a valid card ... which then becomes a type of replay-attack. the "yes card" presents the (cloned) static authentication data to the terminal and then after the PIN is entered ("something you know" authentication), the terminal asks the "yes card" if it is the correct PIN. Of course, "yes cards" (in part where they got their label), always answer "YES".

The assumption about multi-factor authentication being more secure is based on assumption that the different factors are subject to independent vulnerabilities and threats ... i.e. PIN as a form of "something you know" authentication is a countermeasure to lost/stolen ("something you have" authentication) card.

However, in the "yes card" scenario, the infrastructure is vulnerable because the succesful attacker doesn't actually need to know a correct PIN ... since terminal just relies on the card as to whether the PIN is correct or not. All the succesful attacker needs to do is load cloned static authentication data into a "yes card" ... or possibly (in the case of a DDA chip&pin card), pair an appropriately programmed "yes card" with a valid card for a MITM-attack.

back in the mid-90s, when the x9a10 financial standard working group was given the requirement to preserve the integrity of the financial infrastructure for all retail payments ... most forms of both replay-attacks as well as MITM-attacks were among the things considered for the x9.59 financial standard (in part because the same exact standard needed to work, at least, in both point-of-sale as well as over the internet).
http://www.garlic.com/~lynn/x959.html#x959
http://www.garlic.com/~lynn/subpubkey.html#x959

for various reason, many replay-attacks and mitm-attacks that are well documented for the internet evironment are also possible in the point-of-sale environment ... but possibly not so clearly evident.

Posted by Lynn Wheeler at August 16, 2006 02:23 PM

re:
http://www.garlic.com/~lynn/aadsm25.htm#16 Fraudwatch - Chip&Pin one-side story

recent item somewhat related to earlier comments

Banks seek new fraud solutions
http://www.vnunet.com/computing/news/2162444/banks-seek-fraud-solutions

Posted by Lynn Wheeler at August 16, 2006 08:22 PM

The alternative is the European approach: there is a court decision now that Vodafone must not expire the amount on the prepaid accounts of mobile phones! (This happened to me in Skype recently ...)

http://www.heise.de/newsticker/meldung/77148 (in German unfortunately)

Posted by Best regards, Philipp Gühring at August 23, 2006 11:04 AM
Post a comment









Remember personal info?






Hit Preview to see your comment.
MT::App::Comments=HASH(0x563be1b83920) Subroutine MT::Blog::SUPER::site_url redefined at /home/iang/www/fc/cgi-bin/mt/lib/MT/Object.pm line 125.