3

I've been recently rewriting ISO 14443-3 anti-collision loop and found out that it is actually not correctly defined in the standard.

Example: two cards in the field will enter anti-collision loop:

  1. card uid = AB CD EF GH IJ KL xx xx xx (10 bytes/tripple size UID)

  2. card uid = AB CD EF 88 GH IJ KL (7 bytes/double size UID)

They will both get into anti-collision cascade level 2 where:

  1. will transmit: UID CL2 = 88 GH IJ KL - as 88 is the cascade tag indicating that its UID is longer

  2. will transmit: UID CL2 = 88 GH IJ KL - as its actual UID

    => no colision.

PCB will send SELECT and both cards will respond with the SAK where there will be a collision in bit2.

The ISO/IEC 14443-3 standard does not says anything about forbiding uid[3] to be 0x88, only uid[0] is forbidden to be 0x88.

Am I right or did I miss something? I know it is very low probability (1 : 2^56) that two such cards appear in the field at the same time. But nevertheless it is not correct (and the general director of the company I am working for will definitely come to look at what we are doing with two such cards in his wallet).

Community
  • 1
  • 1
Martin Skalský
  • 166
  • 1
  • 8
  • Could you re-phrase this sentence: *Nowhere in the iso 14443-3 standard is written that uid3 cant be 88 only uid0 cant be 88.* I don't fully understand it. – Marcus Müller Sep 18 '15 at 14:21

2 Answers2

7

You obviously do not refer to the latest version of the ISO/IEC 14443-3 standard. This problem existed in the 2001 version of the standard and was corrected in Amendment 1 (in 2005) by adding the clause:

The value '88' of the cascade tag CT shall not be used for uid3 in double size UID.

I would expect (though I did not check) that this is also the case for the 2011 version of the standard.

Michael Roland
  • 39,663
  • 10
  • 99
  • 206
  • While I believe that I read current version, I haven't checked that. - I'll verify on Monday. If it is the case I am sorry for bothering – Martin Skalský Sep 19 '15 at 19:49
2

How is something that happens with p = 2^-56 not correct to use in a wireless communication standard? The probability that noise occurs that disrupts any communication is probably much higher!

Hence: Practical standards do practical implications. Look at hash functions, for example. Obviously, no hash is free of collisions, as long as the hash is shorter than the hashed data -- but the probability of something randomly changing the hashed data to false data with the same hash is so small, it can be neglected in practice. Cryptography depends on an attacker not, by sheer luck, finding the right key on the first try; mechanical engineering is all "oh all these iron atoms are aranged in a neat metal grid, so the probability of a crystal fracture going through the whole steel beam supporting this skyscraper is really really small".

2^-56 is really really small.

Marcus Müller
  • 34,677
  • 4
  • 53
  • 94
  • 1
    I don't like that you can easily fabricate this one - and it is not defined what to do in that case. Or even detect that it happend. So somebody will come and will start to poke into readers to see if it not breaks something. – Martin Skalský Sep 18 '15 at 14:40
  • 1
    Also generation of UIDs is usually not made in Crypographically friendly way(e.g randomly). There are usually some patterns like one vendor has some prefix and then prefix of card type - So it looks to me more like somebody had bad day than calculated trough decision. – Martin Skalský Sep 18 '15 at 15:20
  • 1
    @MartinSkalský: I do agree, this is a bad thing(tm) to be in a standard. – Marcus Müller Sep 18 '15 at 15:51