Anne & Lynn Wheeler wrote:
> for even more drift ... a news item from later yesterday
>
> UK Detects Chip-And-PIN Security Flaw
> http://www.cardtechnology.com/article.html?id=20060606I2K75YSX
>
> APACS says the security lapse came to light in a recent study of the
> authentication technology used in the UK's new "chip-and-PIN" card
> system.
>
> ... snip ...
>
> and some comment
> http://www.garlic.com/~lynn/aadsm23.htm#55 UK Detects Chip-And-PIN
> Security Flaw
>
> not too long after the exploit (from earlier deployments) being
> documented in 2002 ... it was explained to a group from the ATM
> industry ... leading somebody in the audience to quip "do you mean
> that they managed to spend a couple billion dollars to prove that
> chips are less secure than magstripes".
the above from discussion on the subject in a different context
http://www.garlic.com/~lynn/2006l.html#33
the above reference goes into a little more detail of where the label
"yes card" came for the counterfeit cards used in the "SDA" exploit.
as mentioned in earlier posting in this thread:
http://www.garlic.com/~lynn/aadsm23.htm#56 UK Detects Chip-And-PIN
Security Flaw
part of the aads chip strawman
http://www.garlic.com/~lynn/x959.html#aads
requirements in the 90s was to be able to do dynamic data authentication
with higher security than the "DDA" chips (using the chip&pin
terminology) with chip that cost less than the "SDA" chips (and also
could meet the contactless transit power and timing profile requirements).
the x9a10 working group had already examined replay attack threat models
(based on static data authentication) especially in light of the common
skimming attacks that being used to harvest magstripes and PINs
that were starting to become common at the time.
for little more drift, there are assumptions about multi-factor
authentication being more secure ... i.e. magstripes and PINs represent
different factors. However, skimming attacks appearing by at least the
mid-90s where capturing magstripes and PINs as part of the same
operation (invalidating a basic multi-factor security assumption).
also previously mentioned, x9a10 was specifying transaction
authentication as opposed to session-like authentication ... because
transaction authentication reduced several kinds of vulnerabilities that
were frequently related to session operation (end-point threats, mitm
threats, insider threats).
there were a number of chip&pin "SDA" deployments in the 90s ... a
partial reference here:
http://www.garlic.com/~lynn/2006l.html#33
... which had provided opportunities for the "yes card" type attacks to
evolve. by the time of the 2002 article about "yes cards" ... the
article also mentioned that information about building counterfeit "yes
cards" was widely available on the internet.
however, the information about "yes card" kind of attacks (skimming
"SDA" data for replay attacks against terminals) was relatively readily
available by 2000. In late fall of 2000, there was a small conference in
London with principles of the lloyd's of london syndicates involved in
insuring (brick & mortar) point-of-sale retail payment fraud discussing
numerous threat models and countermeasures.
however, a lot of chip&pin deployments have been by people that are
extremely chip centric ... interpreting everything from the context of
the produced chips. there were some chip&pin deployments in 2001 that
interpreted the "yes card" vulnerability from the standpoint that valid
cards could do offline transactions. their "yes card" countermeasure was
to produce valid cards that always did online transactions.
Some of the chip&pin aficionados, when various of the "yes card" details
were explained in more details ... tended to have trouble coming to
grips with it being an attack on terminals and the rest of the
infrastructure ... not attacks on valid chips ... and also thought that
the crooks were not playing fair in how they programmed the counterfeit
chips.
one of the references in the 2002 article was to "yes cards" never going
away. this also was somewhat behind the cited comment from ATM industry
in conference not too long after the 2002 article about proving chips
are less secure than magstripe.
a cornerstone countermeasure to attacks on valid chips (like lost/stolen
vulnerabilities) was infrastructure feature that when a card did an
online transaction (as opposed to offline), the online infrastructure
could instruct the card to self-destruct. the infrastructure allowed
valid cards to instruct chip&pin terminals that they were doing offline
transactions ... but valid cards were programmed to sporadically do
online transactions. if a valid chip was reported as compromised, the
account could be flagged (as happens with all magstripe transactions)
and the chip also be scheduled for self-destruct command, the next time
it went online.
since a counterfeit "yes card" could be programmed to never go online,
flagging an account (as works with magstripe transactions) has no effect
(which was part of what prompted the comment about proving that chips
are less secure than magstripes, another part was in many cases, the
same technology being used for skimming magstripes & pins would also
skim "SDA" information). however, periodically some of the "yes cards"
might be forced to go online ... but several of the chip-centric
individuals were totally dismayed and felt it very unfair that crooks
would go so far as to program the counterfeit "yes cards" to ignore the
self-destruct commands.
in the 2001 chip&pin deployments with countermeasures to counterfeit
"yes cards", involving programming valid cards to always do online
transactions, had no effect on "yes card" fraud. the "yes card" attack
was (replay attack) on terminals (not an attack on valid cards). the
countermeasure for counterfeit "yes cards" would have required the
terminals to be programmed to always ignore instructions to do offline
transaction ... forcing everything to online transactions ... so the
operation would be subject to the same online "account number flagging"
that has been used as countermeasure to magstripe fraud.
---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
