ISO 14443-3 防冲突协议不正确

ISO 14443-3 anti-collision protocol is not correct

我最近一直在重写 ISO 14443-3 防碰撞循环,发现它实际上在标准中没有正确定义。

例子:场中两张牌会进入防碰撞循环:

  1. 卡 uid = AB CD EF GH IJ KL xx xx xx(10 bytes/tripple 尺寸 UID)

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

它们都将进入防碰撞级联 2 级,其中:

  1. 将传输:UID CL2 = 88 GH IJ KL - 因为88是级联标签,表明它的UID更长

  2. 将传输:UID CL2 = 88 GH IJ KL - 作为其实际 UID

    => 没有碰撞。

PCB 将发送 SELECT 并且两张卡将使用 SAK 响应,其中 bit2 将发生冲突。

ISO/IEC 14443-3 标准没有说禁止 uid[3] 为 0x88,只有 uid[0] 被禁止为 0x88.

我是对的还是我错过了什么?我知道两张这样的牌同时出现在场上的概率很低 (1 : 2^56)。但是还是不对(而且我所在公司的总经理一定会过来看看我们用他钱包里的两张这样的卡干什么的)。

p = 2^-56 发生的事情为什么不适合在无线通信标准中使用?发生干扰任何通信的噪音的可能性可能要高得多!

因此:实用标准具有实际意义。例如,查看哈希函数。显然,没有哈希是没有冲突的,只要哈希比哈希数据短——但某些东西将哈希数据随机更改为具有相同哈希的假数据的概率非常小,在实践中可以忽略不计。密码学取决于攻击者,而不是靠运气在第一次尝试时找到正确的密钥;机械工程全 "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真的很小​​.

您显然没有参考最新版本的 ISO/IEC 14443-3 标准。此问题存在于标准的 2001 版中,并在修正案 1(2005 年)中通过添加子句得到纠正:

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

我预计(虽然我没有检查)2011 版标准也是如此。