Платежное приложение на базе NTAG213 vs. Ultralight C (с использованием Android NFC)

Question

У меня есть (университетский) проект, в котором я в основном пишу и читаю текст из тега NFC на устройствах Android, чтобы сохранить баланс на карте (которую можно использовать, например, в кафетерии).

Сейчас я использую NTAG213 и делаю код ниже:

ndef.connect();
NdefRecord mimeRecord = NdefRecord.createMime("text/plain", messageEncrypted.getBytes(Charset.forName("US-ASCII")));
ndef.writeNdefMessage(new NdefMessage(mimeRecord));
ndef.close();

Как вы можете заметить, я использую шифрование на уровне приложения для шифрования сообщения (messageEncrypted) перед записью его в тег (шифрование AES-256 с помощью библиотеки 'com.scottyab: aescrypt: 0.0.1' - с помощью очень большой ключ пароля, в котором также используется тег UID).

Пока все хорошо - только я могу понять данные тега.

В своих исследованиях я обнаружил, что, когда речь заходит о безопасности, Ultralight C> NTAG213.

---

Вопрос 1) Почему при использовании шифрования на уровне приложений MIFARE Ultralight C безопаснее, чем NTAG213?

Вопрос 2) Я почти уверен, что могу гарантировать безопасность, используя шифрование AES, но я не хочу, чтобы люди (кроме меня) возились с сохраненными данными (форматируя тег или записывая информацию там). Я вижу, что единственный способ предотвратить это (пожалуйста, поправьте меня, если я ошибаюсь) - это установить пароль для тега. Однако и NTAG213, и Ultralight C имеют только 32-битный пароль. Это достаточно хорошо? Есть ли другой способ запретить кому-либо (кроме меня) записывать данные?

Вопрос 3) Какие другие меры безопасности я могу использовать для таких тегов для обеспечения безопасности (уровень тегов и приложений)?

Вопрос 4) Когда вы сравниваете безопасность тегов (MIFARE DESFire> Сверхлегкий> NTAG213> MIFARE Classic), что на самом деле сравнивается? Легкость взлома (нативного тега) шифрования или легкость одного магазина (чего угодно) для тега без разрешения?

Вопрос 5) Я вижу кучу других техников (MIFARE DESFire, ICODE SLIX, Infineon Cipurse), которые более безопасны, что заставляет меня задаться вопросом, использую ли я технику (NTAG213 или Ultralight C) ) достаточно хорош для хранения чьего-то баланса. Не могли бы вы (и это личное мнение) сказать, что NTAG213 с шифрованием на уровне приложений и 32-битным паролем достаточно хорош для приложений такого типа? И сколько времени понадобится кому-то, чтобы на самом деле сломать его безопасность?

Answer 1

Почему при использовании шифрования на уровне приложений Ultralight C безопаснее, чем NTAG213?Это даже правда?

Прежде всего, «безопаснее» зависит от ваших реальных целей защиты.Поскольку вы хотите хранить баланс (наличные деньги!) На карте, вы, вероятно, захотите (по крайней мере) защитить для достижения следующих целей:

• Пользователи не должны иметь возможность печатать свои собственные деньгиустановив произвольный баланс на своей карте.
• Пользователи не должны иметь возможность дублировать свою карту и, следовательно, свой денежный баланс.
• Пользователи не должны иметь возможность печатать свои собственные деньги, восстанавливая(откат) своей карты до предыдущего баланса после оплаты.
• Пользователи не должны иметь возможность распечатывать свои собственные деньги путем повторения процедуры пополнения счета.
• Пользователи не должны иметь возможностьуклоняйтесь от оплаты, оторвав свою карту во время платежной транзакции.
• Пользователи не должны иметь возможности создать произвольный (и потенциально более высокий) остаток на своей карте, разорвав свою карту во время процедуры пополнения баланса.

Кроме того, вы можете не захотеть доверять операторам (лицам, принимающим платежи и осуществляющим пополнение).В системе, где одна группа операторов выполняет только пополнение, а другая выполняет только платежные операции, последняя группа, вероятно, не должна иметь права «создавать» деньги.В частности, вы должны четко заявить о том, полностью ли вы доверяете устройствам (Android), которые вы используете в полевых условиях для выполнения этих операций, и доверяете ли вы операторам (например, они не выполняют никаких атак на эти устройства).

Более того, могут быть аспекты конфиденциальности, которые вам необходимо учитывать (например, если баланс легко читается, если пользователи могут быть идентифицированы и т. Д.)

Итак, давайте посмотрим, что вам "шифрование на уровне приложения«добавляет с точки зрения безопасности:

• Поскольку пользователи не знают ключ шифрования, они, вероятно, не могут создать произвольный баланс на своей карте.Однако это сильно зависит от формата вашего баланса (в незашифрованном виде).Пользователи могут вносить произвольные изменения в зашифрованный текст, что приводит к «случайным» модификациям простого текста.Следовательно, пользователи могут иметь возможность изменять значение баланса, несмотря на шифрование.Цифровые подписи / коды аутентификации сообщений - это путь, по которому вы, вероятно, захотите пойти, чтобы преодолеть это.
• Поскольку ключ шифрования (при условии достаточного шифрования, которого, вероятно, нет) зависит от UID тегаВы можете быть защищены от клонирования карт (+ баланс).Однако следует помнить, что UID - это просто свободно читаемый идентификатор.Он никоим образом не аутентифицирован и может быть также клонирован.Смотрите Сериалы на тегах NFC - действительно уникально?cloneable? .
• Зашифрованное значение не защищает вас от пользователей, восстанавливающих свой баланс до ранее записанного значения после оплаты.Этот тип уязвимости был обнаружен ранее (особенно в системах на основе MIFARE Ultralight), см., Например, Benninger, C., Sobell, M. (2012): NFC для бесплатных поездок и комнат (на вашемТелефон).В: Презентация на EUSecWest 2012 .
• Поскольку вы записываете полное значение во время процедуры пополнения (т. Е. Нет специальной команды «приращения баланса»), вы, вероятно, защищены от пользователейВоспроизведение пополнения (за исключением этого аспекта отката).
• Эффект отрыва, вероятно, весьма ограничен, если ваша система допускает только оплату / пополнение при посещении.

Итак, давайте посмотрим, какие дополнительные функции NTAG213 могли бы использовать для защиты вашей системы:

• UID уникален для подлинных тегов.Это не очень помогает, см. Сериалы на тегах NFC - действительно уникально?cloneable? .
• Подпись оригинальности: как и выше, подпись оригинальности также является просто статическим, свободно читаемым значением.Следовательно, он также подвержен клонированию.
• Односторонний счетчик может быть инструментом, который поможет вам защитить от отката (путем включения значения счетчика в подпись).Это все равно не помешает клонированию на платформу тегов, которая позволяет генерировать произвольные значения счетчиков.Кроме того, счетчик не легко контролируется и изменит свое значение, если пользователь попытается прочитать тег.Следовательно, сомнительно, что реализация, основанная на этом значении, будет надежной.
• В отличие от MIFARE Ultralight, NTAG213 не имеет пригодной для использования одноразовой программируемой области (так как она уже используется контейнером возможностей).Следовательно, вы не можете реализовать единовременный вычитаемый баланс на основании этого.
• Функция защиты паролем может помочь вам в аутентификации тегов (путем проверки пароля) и в защите значения, хранящегося в теге (путемделая значение доступным только для чтения / записи после проверки пароля).Однако пароль передается в виде открытого текста (может быть подвергнут анализу, особенно в сценариях без участия пользователя), и криптографическая привязка между паролем и фактическим чтением / записью отсутствует.

MIFARE Сверхлегкий C добавил бы следующее:

• Можно использовать байты OTP.Если есть возможность сделать теги одноразовыми для использования (т. Е. Они начинаются с определенного баланса, который может быть только вычтен, а не пополнен), то использование байтов OTP для представления баланса будет возможным.Обратите внимание, что есть еще много вещей, которые вы можете сделать с этим неправильно, например, Беккаро, М., Коллура, М. (2013): обход OTP в MIFARE ULTRALIGHT: Кто говорит бесплатные поездки ?.В: Презентация на DEFCON 21
• Аутентификация значительно улучшена.Схема аутентификации 3DES, кажется, достаточно безопасна, чтобы предотвратить перехват ключа.Однако команды чтения / записи также не криптографически связаны с этапом аутентификации.Следовательно, злоумышленник может позволить подлинному платежному терминалу + подлинному тегу выполнить аутентификацию, но перенаправить чтение / запись куда-либо еще.Это может (особенно) быть проблемой в автоматическом сценарии.

Я почти уверен, что могу гарантировать безопасность с использованием шифрования AES.

См. Выше.Вероятно, это не так.

Я не хочу, чтобы люди возились с сохраненными данными.Я вижу, что единственный способ предотвратить это - установить пароль для тега.

Пароль / ключ аутентификации может помочь, но помните об ограничениях из-за того, что аутентификация отделена от чтения / записи в этом тегеплатформы.

И NTAG213, и Ultralight C имеют только 32-битный пароль.

Это не так.NTAG213 имеет 32-битный пароль.MIFARE Ultralight C использует более сложный механизм взаимной аутентификации 2K-3DES со 112-битным ключом.

Когда вы сравниваете безопасность тегов, что в действительности сравнивается?

• Механизмы аутентификации (алгоритмы, размеры ключей)
• Безопасность связи (например, само шифрование / аутентификация связи с использованием сеансового ключа, полученного на этапе аутентификации?)
• Контроль доступа (например, существуют ли отдельные ключи дляи оплата?)
• Существуют ли специальные механизмы для управления балансом (например, поля значений, выделенные операции увеличения / уменьшения)?И, следовательно, есть ли механизмы для защиты от разрывающих атак?
• И, возможно, еще ...

Я вижу множество других технологий, которые более безопасны, что заставляет меня задуматьсяесли технология, которую я использую, достаточно хороша для сохранения чьего-либо баланса.

Ваша конкретная система имеет недостатки во многих отношениях.На мой взгляд, MIFARE Ultralight / NTAG203 / NTAG21x - определенно не лучший выбор для автономной системы хранения наличных денег на картах.

MIFARE Сверхлегкий C может подойти с некоторыми мерами предосторожности.Я бы определенно воздержался от использования этого в автоматических сценариях и, вероятно, использовал бы онлайн-систему, отслеживающую баланс и отслеживающую несоответствия.

Все, что использует симметричную криптографию и хранит криптографические ключи в терминале, безусловно, потребует мер предосторожностипротив злонамеренных операторов.Возможно, оператору (с некоторыми знаниями) довольно легко извлечь ключи из приложения и получить собственные деньги.

Answer 2

Полагаю, ваш вопрос слишком широкий, и не для всех подвопросов этот раздел SO является наиболее подходящим.

Сосредоточив внимание на криптографической стойкости, вы что-то упускаете: если можно легко атаковать низкоуровневую защиту токена, никто не должен взламывать ваш ключ.

• Простой дамп и последующее восстановление (после некоторых платежей) соответствует печати денег
• Если токен содержит деньги напрямую (а не только идентификацию кошелька, который хранится в фоновой системе), вам нужна гораздо более безопасная система, чтобы избежать финансового ущерба. Это связано с динамически зашифрованным обменом информацией, но продолжается с другими важными темами.