Anne & Lynn Wheeler <lynn@garlic.com> writes:
> then there is the old "yes cards" discussions and the generic issue
> with "replay attacks" when static authentication data is being used
> http://www.garlic.com/~lynn/subintegrity.html#yescard
re:
http://www.garlic.com/~lynn/2006v.html#39 On sci.crypt: New attacks on the financial PIN processing
general class of harvesting/skimming authentication static data for various
forms of replay attacks.
http://www.garlic.com/~lynn/subintegrity.html#secrets http://www.garlic.com/~lynn/subintegrity.html#harvest
in the "yes card" scenario, some considered the chip worse than the
magstripe cards that it replaced. a countermeasure in the standard
financial account transaction is to flag the account and negate future
(online) transactions. in the "yes card" scenario ... once the
(counterfeit) "yes card" replayed the authentication static data, it
was allowed to instruct the terminal to do an "offline"
transaction. by the time the terminal finds out the account has been
flagged, it is way too late. also when the "terminal" asked the
(counterfeit) "yes card" if the entered PIN was correct, the "yes
card" would always reply "YES" (part of the where the counterfeit card
got its label "yes card"). As a result, the attacker doesn't even need
to know the PIN.
in three-factor authentication model
http://www.garlic.com/~lynn/subintegrity.html#3factor
* something you have
* something you know
* something you are
normally in multi-factor authentication, the different factors are
assumed to have independent vulnerabilities. A ("something you know")
PIN is countermeasure to lost/stolen ("something you have") card. In
the "yes card" scenario, an attacker just needs to harvest/skim the
card "authentication" information (and/or trick a lost/stolen card
into divulging the information). That information then can be loaded
into a (counterfeit) "yes card". Futhermore, while the account for a
lost/stolen card can be reported and have the corresponding account
flagged, since a (counterfeit) "yes card" can instruct the terminal to
do an offline transactions, it defeats the effect of flagging the
account.
some other recent items related to static data authentication and
replay attacks
http://www.garlic.com/~lynn/2006v.html#29 User Authentication
http://www.garlic.com/~lynn/2006v.html#44 User Authentication
and
User agency warns of online security risks
http://news.ninemsn.com.au/article.aspx?id=168199
Warning over use of repeat passwords
http://www.hackinthebox.org/modules....icle&sid=21901
Warning over use of repeat passwords
http://www.theage.com.au/news/securi...080812161.html
Schumer warns on no-swipe credit cards
http://news.yahoo.com/s/ap/schumer_id_theft
now one of the countermeasures to the static data authentication and
"yes card" vulnerability is to convert to some form of dynamic data
authentication (like digital signatures). note however, that even
"dynamic data authentication" may be vulnerable to a "yes card"
man-in-the-middle attack if it is used for card authentication as
opposed to transaction authentication, i.e. pair a counterfeit "yes
card" with a valid lost/stolen card ... where the counterfeit "yes
card" transparently passes the card authentication messages and then
controls the rest of the session (when the terminal asks if the
correct PIN was entered the "yes card" responds "YES" and when the
terminal asks if it should do an offline transactions, the "yes card"
also responds "YES").
recent related item
http://www.garlic.com/~lynn/2006v.html#26 Fighting Fraudulent Transactions
other posts related to man-in-the-middle attacks
http://www.garlic.com/~lynn/subintegrity.html#mitm 
On sci.crypt: New attacks on the financial PIN processing 
Linear Mode
