How fast will the chip and pin card respond to requests? Does built-in rate-limiting (or just limitations of the chip on the card) mitigate this attack? How big

How fast will the chip and pin card respond to requests? Does built-in rate-limiting (or just limitations of the chip on the card) mitigate this attack? How big is the authentication keyspace? It sounds (from the brief; Reading the paper now) like this is a fairly standard replay attack. The terminal generates a transaction id, asks the card to sign it, then transmits that to the bank to prove identity. In this case, it's a 'pre-play', because the bank verifies that it's never seen the signature before by blacklisting the transactionid. This is not very effective if you can keep retrying. It looks like they do give some numbers: "Thirty seconds is the standard authorisation time limit; this might allow for more than 100 transactions to be skimmed". That's not a whole lot, in a truly random 32 bit space, but in a world where many ATMs have predictable or deterministic sequence numbers, that's plenty for a chosen plaintext attack. The attack works like this: You run a shady merchandise store. You hack your card reader; Instead of generating one ARQC for one transaction, when the customer enters their card and pin it generates five. One for your real transaction, one for four other specially chosen numbers. You then take your special chip+pin card, armed with the public credentials of that card, and responses to those four transactions, to the local market with a freestanding ATM. You kick out the power to the ATM, "accidentally", causing the state of the ATM to be known. Then, you withdraw cash; A few hundred, or whatever's in the account. The ATM asks your card for a signature of it's 'random' number, but the 'random' number is one of the four you copied from the card in step one. As the authors pointed out: "The deeper protocol design flaw is that while the terminal generates the random number, it is the issuing bank that relies on it"