Chip and PIN is Broken
in [Cryptography]
|
Prev: Another informative pronouncement from Smug Doug Gwyn
Next: Protecting 3x16 bits with 16 bits ? (Which error correcting code for mode 3?)
From: unruh on 12 Feb 2010 23:14 On 2010-02-13, Richard Outerbridge <outer(a)interlog.com> wrote: > In article <slrnhnb71r.3rj.unruh(a)wormhole.physics.ubc.ca>, > unruh <unruh(a)wormhole.physics.ubc.ca> wrote: > >> On 2010-02-12, Jan Panteltje <pNaonStpealmtje(a)yahoo.com> wrote: >> > >> > Chip and PIN is Broken: >> > http://www.cl.cam.ac.uk/research/security/banking/nopin/oakland10chipbroken >> >> Nice paper-- the usual Ross Anderson protection of the consumer piece. >> To summarize, they show that a stolen card for which the thief does not >> know the pin, can nevertheless be used to make purchases which claim to >> be verified by PIN. Ie, the pin is useless for protecting stolen cards. > > Under certain circumstances. > > The attack is more than a little remote. Their point is that it is > entirely permitted by the somewhat malleable EMV specifications. No, they claim that it has already occured, and is not remote (They did it-- charge something against a card which returns "Pin Verified" when no pin verification ever occured. > > outer
From: Richard Outerbridge on 13 Feb 2010 00:34 In article <slrnhnc9o8.8k1.unruh(a)wormhole.physics.ubc.ca>, unruh <unruh(a)wormhole.physics.ubc.ca> wrote: > On 2010-02-13, Richard Outerbridge <outer(a)interlog.com> wrote: > > In article <slrnhnb71r.3rj.unruh(a)wormhole.physics.ubc.ca>, > > unruh <unruh(a)wormhole.physics.ubc.ca> wrote: > > > >> On 2010-02-12, Jan Panteltje <pNaonStpealmtje(a)yahoo.com> wrote: > >> > > >> > Chip and PIN is Broken: > >> > http://www.cl.cam.ac.uk/research/security/banking/nopin/oakland10chipbro > >> > ken > >> > >> Nice paper-- the usual Ross Anderson protection of the consumer piece. > >> To summarize, they show that a stolen card for which the thief does not > >> know the pin, can nevertheless be used to make purchases which claim to > >> be verified by PIN. Ie, the pin is useless for protecting stolen cards. > > > > Under certain circumstances. > > > > The attack is more than a little remote. Their point is that it is > > entirely permitted by the somewhat malleable EMV specifications. > > No, they claim that it has already occured, and is not remote (They did > it-- charge something against a card which returns "Pin Verified" when > no pin verification ever occured. I understand this entirely. I have no doubt they were able to perform the attack. But I do not believe the attack can be amplified, and as such it is more a proof-of-concept attack against EMV than a practical widespread compromise of Chip&PIN.
From: Kristian Gj�steen on 13 Feb 2010 02:58 Richard Outerbridge <outer(a)interlog.com> wrote: >I understand this entirely. I have no doubt they were able to perform >the attack. But I do not believe the attack can be amplified, and as >such it is more a proof-of-concept attack against EMV than a practical >widespread compromise of Chip&PIN. Why couldn't their tools be replicated and mass-produced, leading to significant compromise? -- Kristian Gj�steen
From: Richard Outerbridge on 13 Feb 2010 08:10 In article <hl5m2l$fl2$1(a)orkan.itea.ntnu.no>, Kristian Gj�steen <kristiag+news(a)math.ntnu.no> wrote: > Richard Outerbridge <outer(a)interlog.com> wrote: > >I understand this entirely. I have no doubt they were able to perform > >the attack. But I do not believe the attack can be amplified, and as > >such it is more a proof-of-concept attack against EMV than a practical > >widespread compromise of Chip&PIN. > > Why couldn't their tools be replicated and mass-produced, leading to > significant compromise? Two key sentences: "The card itself may permit the terminal to attempt signature verification if PIN verification fails, but in practice merchants will normally reject the transaction." "The issuer, which can decode the IAD, does not know which cardholder verification method was used, and so cannot use it to prevent the attack." But the Issuer knows which verification methods are allowed by their cards, and can decode the IAD. If the Issuer has allowed signature fallback, or no verification, or has not included the IAD in the ARQC, the ambiguity arises and the attack goes through. But if, as suggested by the first sentence, offline PIN verification by the card itself is the only option for online transactions, then there is no ambiguity - except as permitted by the specification and perhaps implemented by incautious Issuers.
From: Kristian Gj�steen on 13 Feb 2010 09:00
Richard Outerbridge <outer(a)interlog.com> wrote: >In article <hl5m2l$fl2$1(a)orkan.itea.ntnu.no>, > Kristian Gj�steen <kristiag+news(a)math.ntnu.no> wrote: > >> Richard Outerbridge <outer(a)interlog.com> wrote: >> >I understand this entirely. I have no doubt they were able to perform >> >the attack. But I do not believe the attack can be amplified, and as >> >such it is more a proof-of-concept attack against EMV than a practical >> >widespread compromise of Chip&PIN. >> >> Why couldn't their tools be replicated and mass-produced, leading to >> significant compromise? > >Two key sentences: > >"The card itself may permit the terminal to attempt signature >verification if PIN verification fails, but in practice merchants >will normally reject the transaction." > >"The issuer, which can decode the IAD, does not know which cardholder >verification method was used, and so cannot use it to prevent the >attack." > >But the Issuer knows which verification methods are allowed by their >cards, and can decode the IAD. If the Issuer has allowed signature >fallback, or no verification, or has not included the IAD in the ARQC, >the ambiguity arises and the attack goes through. > >But if, as suggested by the first sentence, offline PIN verification >by the card itself is the only option for online transactions, then >there is no ambiguity - except as permitted by the specification and >perhaps implemented by incautious Issuers. I don't understand. Why should this be an obstacle for me with a copy of their tools, but not an obstacle for them with the exact same tools? -- Kristian Gj�steen |