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: Peter Fairbrother on 14 Feb 2010 11:00 Kristian Gj�steen wrote: > Peter Fairbrother <zenadsl6186(a)zen.co.uk> wrote: >> Kristian Gj�steen wrote: >>> Richard Outerbridge <outer(a)interlog.com> wrote: >>>> They got to choose the perhaps incautious Issuers' cards they attacked? >>> Do you know what fraction of issuers are "incautious"? >>> >> Afaik 100% of UK-issued cards allow signature fallback. > > In Norway, the banks say that the domestic payment system does not allow > signature fallback. Since almost every card are also part of either > the Mastercard or Visa system, I wonder if those systems might allow > signature fallback, and if so, if it is possible to make the cards use > the Mastercard/Visa system instead of the domestic system. > > It would be rather daft it that was possible... In the EMV system the decision as to whether signature or unauthenticated fallback (there are other options too, pages of them) is allowed is up to the card, and Norwegian-issued cards may - I repeat may - not allow this fallback for EMV. BTW I got my suggested fix wrong. The acquiring bank gets the data from the terminal and sends it on to the issuing bank for authentication, there is no separate transmission to both banks by the terminal. -- Peter Fairbrother
From: Peter Fairbrother on 14 Feb 2010 14:37
Jan Panteltje wrote: > Chip and PIN is Broken: > http://www.cl.cam.ac.uk/research/security/banking/nopin/oakland10chipbroken.pdf A Quick n' Dirty Fix. In section III of the paper they wrote: "The IAD (Figure 5) does often indicate whether PIN verification was attempted, however it is in an issuer-specific proprietary format, and not specified in EMV. Therefore the terminal (which knows the cardholder verfication method chosen), cannot decode it. 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. Because of the ambiguity in the TVR encoding, neither party can identify the inconsistency between the cardholder verification methods they each believe were used. The issuer will thus believe that the terminal was incapable of soliciting a PIN, which is an entirely plausible, yet inaccurate, conclusion." But the last isn't a plausible, or even possible, conclusion for the issuer. I'll assume that the card's CV Rule list (which the issuing bank will know) contains the following rules for different CVMs (cardholder verification methods). 1) online verification (for ATMs) 2) offline verification (the situation we are talking about, where cardholder verification is done offline by the terminal but the terminal is online) 3) signature verification - there will probably be some more rules, but that's enough for now. For an ordinary sales transaction the terminal will go through the list of rules in order, bypass the first option, and consider the second. There are "exceptional" situations where the rule 2 will also be bypassed and rule 3, signature verification, will be chosen. I'll go into those later. If the bank sees that bit 3 of byte 5 of the IAD is not set (the authenticated-by-the-card card's view telling the issuing bank that, in the card's view, offline PIN verification has not been successfully completed) and none of the bits of byte 3 of the TVR are set, then there are three potential causes of this: a) one of the "exceptional" situations has occurred and rule 2 has been bypassed, b) the CVM in rule 2 is not supported by the terminal, or c) an attack of this type has taken place. In regard to b): "If the CVM is not supported, processing continues at step 2. In case the CVM was PIN-related, then in addition the terminal shall set the ‗PIN entry required and PIN pad not present or not working' bit (b5 of byte 3) of the TVR to 1." [EMV Integrated Circuit Card Specifications for Payment Systems Book 3, version 4.2, section 10.5, page 104. Available at http://www.emvco.com/specifications.aspx?id=155] The conclusion that "the terminal was incapable of soliciting a PIN" is however *not* possible, as if that had happened because the terminal didn't support it or because the pad was broken then bit 5 of the TVR would be set. Which leaves only the possibilities that the rule was bypassed or an attack has taken place. The circumstances in which a CV Rule is bypassed are: "If any of the following is true: the conditions expressed in the second byte of a CV Rule are not satisfied, or data required by the condition (for example, the Application Currency Code or Amount, Authorised) is not present, or the CVM Condition Code is outside the range of codes understood by the terminal (which might occur if the terminal application program is at a different version level than the ICC application)," [EMV Integrated Circuit Card Specifications, as above] The first of these circumstances happens a lot, eg that's how rule 1 got bypassed above, so it's not really "exceptional" at all. However the issuing bank knows rule 2 in the card, and knows when it should and shouldn't be bypassed. The issuing bank will also in most cases know when the second condition should be invoked by the terminal (almost never for a normal domestic transaction). The third is a little trickier, but if they stick to the simple codes then in most cases they will be able to avoid this. Again, it's not something which happens in a normal transaction. Thus the issuing bank will, in most cases, be able detect and prevent an attack of the type in the paper. They would get some false positives if they only look at bit 3 of byte 5 of the IAD and bits 3-8 of byte 3 of the TVR, but they shouldn't get any false negatives, and the false positive rate can be lowered by looking at other factors such as why the rule might have been bypassed. I would seem that the Banks don't actually do this sort of checking, and that's why the attack works in practice - but I don't see why they couldn't start. It's not a "proper" fix, but ... -- Peter Fairbrother |