BBC Moneybox - contactless hiccups

[Peter Tomlinson]

(1) I agree that charging the customer twice **for the same 
transaction** is an application flaw in the POS device - and it smacks 
of a major error in POS device certification (may also be a breach of 
the Merchant Agreement if it really happened - but that it did happen 
might be an urban myth). But maybe it was actually something different 
(see point (3) below).

(2) One (and its an obvious one) difficulty with collision avoidance by 
interrogating the cards is the time that it takes - a major point about 
contactless EMV payment is transaction speed. A less obvious difficulty 
is that the terminals don't (as far as I know) have any way for the 
customer to be asked which card should be used, so assistance would have 
to be sent for when a collision is detected - and no store trying to 
speed things up (customer proposition) and keep costs down (merchant 
proposition) will want that to happen..

(3) If another report is true (that a customer with no intention of 
paying for anything gets charged just because he/she is nearby), then 
there will have to be (a) reduction of the strength of the terminal's RF 
field, (b) adjustment of the shape of the terminal's RF field (which is 
generated by a coil), and (c) adjustment to the layout of the point of 
sale area so that those who don't want to pay are kept away until its 
their turn. One of the worse cases will be if customer A is at the 
terminal and customer B waiting in line to pay gets charged for customer 
A's purchase while customer A walks away without paying (because the 
terminal says the transaction is complete). Reminds me of passport 
control where you wait to be called forward...

I'm expecting a forthcoming debit card renewal to result in my getting a 
card with contactless technology as well as contact. Must line my wallet 
with kitchen foil (no tin foil to hand)...

Peter

On 20/05/2013 14:07, Ian Mason wrote:
> There are several collision avoidance mechanisms for RFID cards. The 
> commonest uses a tree walk strategy where the reader gradually 
> enumerates the possible serial number space by repeatedly transmitting 
> a request for cards with a defined serial number prefix to reply and 
> lengthening the prefix at every attempt. It would look something like 
> this:
>
> Reader Tx:    Any cards there?
> Reader Rx:    <collision>
> Reader Tx:    Any cards with a serial number starting '0' there?
> Reader Rx:    <silence>
> Reader Tx:    Any cards with a serial number starting '1' there?
> Reader Rx:    <collision>
> Reader Tx:    Any cards with a serial number starting '10' there?
> Reader Rx:    <silence>
> Reader Tx:    Any cards with a serial number starting '11' there?
> Reader Rx:    <collision>
> Reader Tx:    Any cards with a serial number starting '110' there?
> Reader Rx:    This is card 11011001...
>
>  This method has the undesirable property that it leaks all but the 
> last bit of the serial number of the card it is reading. This being 
> leaked by the reader (which will have a much higher transmit power 
> than the card) it can be read at much greater distances than replies 
> from cards. Using it implies that for a system to be even trivially 
> secure, the systems security must not rely on the cards serial number 
> being secret. This might seem obvious, but I've seen smart card 
> systems that do rely on serial number secrecy.
>
> An alternative collision mechanism is good old ALOHA and slotted 
> ALOHA, as used in ethernet's great granddaddy at the University of 
> Hawaii. This is a classic backoff and retransmit protocol and has all 
> the problems of those style protocols in high traffic/crowded airspace 
> situations.
>
> I don't know which mechanism contactless payment cards use. Using 
> either one there is still a race for cards to reply and a possibility 
> that for implementations that stop trying once they have received a 
> single complete reply that a particular card may always be singled 
> out, either by serial number priority or differing choices (or 
> accuracy) of retransmission timers.
>
> Note that both protocols make it possible to enumerate all cards in 
> range and then it would be an application flaw, as opposed to a reader 
> flaw, that allowed two cards to be charged for the same transaction. 
> It seems obvious to me that a POS system that detected two or more 
> cards ought to ask for human intervention to resolve which card to 
> choose but perhaps it wasn't obvious to the designers of these 
> particular systems.
>
> Ian
>
>