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

【问题标题】：ISO 14443-3 anti-collision protocol is not correctISO 14443-3 防冲突协议不正确
【发布时间】：2015-09-18 14:08:30
【问题描述】：

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

例子：场内两张牌会进入防撞循环：

卡 uid = AB CD EF GH IJ KL xx xx xx（10 字节/三倍大小的 UID）
card uid = AB CD EF 88 GH IJ KL (7 bytes/double size UID)

它们都将进入防碰撞级联 2 级，其中：

将传输：UID CL2 = 88 GH IJ KL - 因为88是级联标签，表明其UID更长
将传输：UID CL2 = 88 GH IJ KL - 作为其实际 UID

=> 没有粘连。

PCB 将发送 SELECT 并且两个卡都将响应 SAK，其中 bit2 将发生冲突。

ISO/IEC 14443-3 标准没有说明禁止 uid[3] 为0x88，只有 uid[0] 禁止为0x88。

我是对的还是我错过了什么？我知道两张这样的牌同时出现在场上的概率非常低（1：2^56）。但这仍然是不正确的（我工作的公司的总经理肯定会来看看我们用他钱包里的两张这样的卡做什么）。

【问题讨论】：

您能否重新表述这句话：iso 14443-3 标准中没有任何地方写到 uid3 不能为 88，只有 uid0 不能为 88。 我不太明白它。

标签： nfc standards iso smartcard-reader contactless-smartcard

【解决方案1】：

您显然没有参考最新版本的 ISO/IEC 14443-3 标准。该问题在 2001 版标准中存在，并在修订版 1（2005 年）中通过添加以下条款进行了更正：

级联标签CT的值'88'不得用于双倍大小UID的uid3。

我希望（尽管我没有检查）2011 版标准也是如此。

【讨论】：

虽然我相信我阅读了当前版本，但我没有检查过。 - 我会在星期一验证。如果是这样，我很抱歉打扰

【解决方案2】：

在无线通信标准中使用 p = 2^-56 时会发生什么不正确的情况？干扰任何通信的噪音发生的概率可能要高得多！

因此：实用标准具有实际意义。例如，看看哈希函数。显然，没有哈希是没有冲突的，只要哈希比哈希数据短——但是随机将哈希数据更改为具有相同哈希的虚假数据的概率是如此之小，在实践中可以忽略不计。密码学取决于攻击者，而不是靠运气，在第一次尝试时找到正确的密钥；机械工程就是“哦，所有这些铁原子都排列在一个整齐的金属网格中，因此支撑这座摩天大楼的整个钢梁发生晶体断裂的可能性真的很小”。

2^-56 真的很小。

【讨论】：

我不喜欢你可以轻松地制造这个 - 而且没有定义在这种情况下要做什么。甚至检测到它发生了。所以有人会来并开始戳读者，看看它是否会破坏某些东西。
另外，UID 的生成通常不是以密码友好的方式（例如随机）。通常有一些模式，比如一个供应商有一些前缀，然后是卡片类型的前缀 - 所以在我看来，它更像是某人度过了糟糕的一天，而不是经过计算的低谷决定。
@MartinSkalský：我同意，在标准中这是一件坏事（tm）。