Протокол предотвращения столкновений ISO 14443-3 неверен

Недавно я переписывал цикл предотвращения столкновений ISO 14443-3 и обнаружил, что на самом деле он неправильно определен в стандарте.

Пример: две карты в поле войдут в цикл предотвращения столкновений:

  1. uid карты = AB CD EF GH IJ KL xx xx xx (10 байт / UID тройного размера)

  2. uid карты = AB CD EF 88 GH IJ KL (7 байт/UID двойного размера)

Они оба попадут на уровень каскада предотвращения столкновений 2, где:

  1. будет передавать: UID CL2 = 88 GH IJ KL - поскольку 88 является тегом каскада, указывающим, что его UID длиннее

  2. будет передавать: UID CL2 = 88 GH IJ KL - как его фактический UID

    =› нет коллизии.

PCB отправит SELECT, и обе карты ответят SAK, где будет коллизия во втором бите.

Стандарт ISO/IEC 14443-3 ничего не говорит о запрете uid[3] быть 0x88, только uid[0] запрещено иметь 0x88.

Я прав или я что-то пропустил? Я знаю, что очень мала вероятность (1 : 2^56) того, что две такие карты появятся на поле одновременно. Но все же это неправильно (и гендиректор компании, в которой я работаю, обязательно придет посмотреть, что мы делаем с двумя такими карточками в кошельке).


nfc standards iso contactless-smartcard smartcard-reader
person Martin Skalský    schedule 18.09.2015    source источник
comment
Не могли бы вы перефразировать это предложение: Нигде в стандарте iso 14443-3 не написано, что uid3 не может быть 88, только uid0 не может быть 88. Я не совсем понимаю.   -  person Marcus Müller    schedule 18.09.2015

Ответы (2)


arrow_upward
6
arrow_downward

Вы явно не имеете в виду последнюю версию стандарта ISO/IEC 14443-3. Эта проблема существовала в версии стандарта 2001 г. и была исправлена ​​в Поправке 1 (в 2005 г.) путем добавления пункта:

Значение '88' каскадного тега CT не должно использоваться для uid3 в UID двойного размера.

Я ожидаю (хотя и не проверял), что это относится и к версии стандарта 2011 года.

person Michael Roland    schedule 19.09.2015
comment
Хотя я считаю, что читал текущую версию, я не проверял ее. - Я проверю в понедельник. Если это так, извините за беспокойство - person Martin Skalský; 19.09.2015

arrow_upward
2
arrow_downward

Как то, что происходит с p = 2 ^ -56, не подходит для использования в стандарте беспроводной связи? Вероятность возникновения шума, нарушающего любую коммуникацию, вероятно, намного выше!

Следовательно: Практические стандарты имеют практические последствия. Посмотрите, например, на хеш-функции. Очевидно, что ни один хэш не свободен от коллизий, пока хэш короче хэшированных данных, но вероятность того, что что-то случайно изменит хешированные данные на ложные данные с тем же хешем, настолько мала, что на практике ею можно пренебречь. Криптография зависит от злоумышленника, а не от чистой удачи, находящей правильный ключ с первой попытки; машиностроение - это все «о, все эти атомы железа расположены в аккуратной металлической сетке, поэтому вероятность разрушения кристалла, проходящего через всю стальную балку, поддерживающую этот небоскреб, действительно очень мала».

2^-56 действительно очень мало.

person Marcus Müller    schedule 18.09.2015
comment
Мне не нравится, что вы можете легко сфабриковать это - и не определено, что делать в этом случае. Или даже обнаружить, что это произошло. Вот придет кто-нибудь и начнет тыкать в ридеры, чтобы посмотреть, не сломается ли что-нибудь. - person Martin Skalský; 18.09.2015
comment
Кроме того, генерация UID обычно не выполняется криптографически (например, случайным образом). Обычно есть некоторые закономерности, например, у одного поставщика есть какой-то префикс, а затем префикс типа карты. Так что мне кажется, что у кого-то был плохой день, а не расчетное решение. - person Martin Skalský; 18.09.2015
comment
@MartinSkalský: Я согласен, это плохо (tm) быть в стандарте. - person Marcus Müller; 18.09.2015