2015-09-18 1 views
3

Недавно я переписал цикл защиты от столкновения 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

    => нет colision.

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

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

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

+0

Не могли бы вы перефразировать это предложение: * Нигде в стандарте iso 14443-3 не написано, что uid3 не может быть 88, только uid0 не может быть 88. * Я не совсем понимаю это. –

ответ

5

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

Значение «88» из каскадного тега CT не должна быть использована для UID3 в двойном размере UID.

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

+0

Хотя я считаю, что читаю текущую версию, я ее не проверял. - Я проверю в понедельник. Если это так, я извиняюсь за беспокойство –

2

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

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

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

+1

Мне не нравится, что вы можете легко изготовить это - и в этом случае не определено, что делать. Или даже обнаружите, что это произошло. Так что кто-то придет и начнет суетиться в читателей, чтобы понять, не сломает ли он что-то. –

+1

Также генерация UID обычно не выполняется с помощью Crypographic-friendly (например, случайным образом). Обычно есть несколько шаблонов, например, у одного поставщика есть префикс, а затем префикс типа карты. Поэтому мне кажется, что у кого-то был плохой день, чем у расчетного решения. –

+1

@ MartinSkalský: Я согласен, это плохо (tm), чтобы быть в стандарте. –