Anne & Lynn Wheeler <lynn@garlic.com> writes:
> so what x9.59 financial standard did was require strong authentication
> and integrity for every transaction ... and a business rule that
> account numbers used in x9.59 could not be used in non-authenticated
> transactions. basically just knowing an account number was no longer
> sufficient to perform a fraudulent transaction ... and so it was no
> longer necessary to constantly keep the account number hidden; i.e.
> authentication and integrity replaced privacy to achieve security.
> x9.59 did nothing to prevent skimming/harvesting transactions ... but
> eliminated the risk/fraud associated with attacker (or insider)
> skimming/harvesting.
re:
http://www.garlic.com/~lynn/2006v.html#49 Patent buster for a method that increases password security
even more drift related to static authentication data being vulnerable to
various kinds of skimming/harvesting attacks
Fast Payments creates strong case for two-factor authentication, says
Thales
http://www.finextra.com/fullstory.asp?id=16240
Banks lobby govt on smartcard
http://www.hackinthebox.org/modules....icle&sid=21919
British Banks keep a secret..
http://www.zone-h.org/content/view/14404/31/
Banks reluctant to reveal full extent of online fraud
http://www.e-consultancy.com/news-bl...ine-fraud.html
Newspaper Says UK Banks Fail to Report Online Fraud
http://www.epaynews.com/index.cgi?su...2145191&block=
Smart Card Alliance slams RFID use in US passport card program
http://www.cbronline.com/article_new...2-45B457496214
Industry group urges caution on U.S. plan for RFID-enabled ID cards
http://www.computerworld.com/action/...intsrc=hm_list
RFID Sabotages Privacy, Says Government Watchdog
http://www.rfidnews.org/weblog/2006/...ment-watchdog/
US government warned off RFID passports
http://www.techworld.com/security/ne...13&pagtype=all
Smart Card Alliance Cautions Feds on RFID Cards
http://www2.csoonline.com/blog_view.html?CID=27237
Flaw exploited in RFID-enabled passports
http://www.garlic.com/~lynn/aadsm25.htm#46
Flaw in RFID-enabled passports (part 2?)
http://www.garlic.com/~lynn/aadsm26.htm#0
Note one of the issues related to "yes card" bank chipcard exploits
http://www.garlic.com/~lynn/subintegrity.html#yescard
was that it used static data for authentication. this made it
vulnerable to harvest/skimming and replay attacks (not too different
from magstripe harvest/skimming with replay attacks using counterfeit
cards).
however, the big additional vulnerability introduced with the bank
chipcard exploits, was that the terminal, after initially verifying
the chips (static) authentication data ... would then "obey" the
cards' instructions ... which gave rise to the "yes card" label.
When the terminal asked if the entered PIN was correct, a counterfeit
"yes card" would always answer "YES", minor digression
http://www.garlic.com/~lynn/2006w.html#0 Patent buster for a method that increases password security
And when the terminal asked if the transaction should be offline, the
counterfeit "yes card" would always answer "YES", and when the
terminal then asked if the transaction was within the account credit
limit, the counterfeit "yes card" would again answer "YES".
In some of the bank chipcard deployments ... after the appearance of
some of the counterfeit "yes cards" (in earlier deployments in the
90s), some made the decision to only issue valid cards that only did
online transactions (and never opted for offline operation, perceiving
it to be a countermeasure to "yes card" attack).
However, these were highly card-centric operations ... and didn't
understand that the counterfeit "yes card" attacks weren't attacks on
the card ... but attacks on the terminal. It was still possible to
skim that static authentication data from such cards, load it into a
counterfeit "yes card", and program the counterfeit "yes card" to tell
the terminal that the correct pin was enter and to do offline
transaction.
The problem is that the standard countermeasure for skimmed
counterfeit cards is to disable the account. However, when a terminal
does an offline transaction, there is no communication to find out
that the acocunt has been disabled until way after the fraud has
occured. The appropriate countermeasure to the "yes card" exploits
wasn't to program valid cards to only do online transactions, the
appropriate countermeasure to the "yes card" exploits was to program
terminals to never do offline transactions (i.e. it was an attack on
terminals not attacks on cards).
Sen. Schumer Decries Dangers of 'No-Swipe' Credit Cards
http://www.foxnews.com/story/0,2933,234586,00.html
Sen. Schumer Calls For Better Contactless Payment Security
http://www.cardtechnology.com/articl...061206O8ZLO98Q
Would You Trust RFID-Enabled ATM Cards?
http://ask.slashdot.org/askslashdot/.../0532242.shtml
Would You Trust RFID-Enabled ATM Cards?
http://ask.slashdot.org/article.pl?sid=06/12/06/0532242
Possible Serious Security Flaw In ATMs
http://it.slashdot.org/it/06/11/30/2....shtml?tid=187
So if bank cards continue to use static authentication data, they
continue to be vulnerable to harvest/skimming exploits ... and
contactless/wireless communication may increase the opportunities for
attackers to record static authentication data.
Note however, there may still be other vulnerabilities even in any
upgrade from static to dynamic authentication data. This is the
scenario whether the card is being authenticated or is the transaction
being authenticated.
http://www.garlic.com/~lynn/2006v.html#26 Fighting Fraudulent Transactions
the scenario with card authentication ... is that even with dynamic
authentication data, it may still be vulnerability to a "yes card"
MITM-attack where a "yes card" is paired with a lost/stolen card (or
any valid card obtained by any means).
The counterfeit "yes card" transparently passes the card
authentication messages ... but then takes over the rest of the
communication to perform the "YES" answers to the three terminal
questions 1) correct PIN, 2) offline transaction, 3) within credit
limit.