Можно ли удаленно клонировать кредитные карты с помощью считывателя RFID?

В этой новости из "13 Investigates" рассказывается о Уолте Аугустиновиче (эксперте по RFID и продавце пакетов с защитой от RFID), у которого есть портативный считыватель, который считывает данные кредитных карт, пока они все еще находятся в бумажниках и кошельках людей.

Он также демонстрирует копирование клонированной информации на магнитную кредитную карту и использование ее для покупки товаров без необходимости подписывать или вводить PIN-код.

Легко ли клонировать кредитную карту на основе RFID?

Примечание. Адам Сэвидж сообщает, что, когда Mythbuster задумали исследовать безопасность RFID, юрисконсульт нескольких крупных организаций, выпускающих кредитные карты, предупредил их об этом.

@Cullen: Хотели бы вы превратить это в ответ, чтобы мы могли убрать этот вопрос из списков без ответа?

Ответы (1)

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

Snopes опубликовал ответ на это видео в 2012 году, который содержал довольно хорошее резюме аналитиков безопасности:

Потоки данных, испускаемые бесконтактными картами , не включают в себя такую ​​информацию, как PIN-коды и коды безопасности CVV (Card Verification Value) — или, в более новых картах, имена клиентов — и без этих фрагментов информации скиммер карты не сможет использовать номера украденных карт для распечатки поддельных карт или участия в транзакциях без предъявления карты (CNP):

Ни одна из карт не передает дополнительный номер на лицевой или оборотной стороне , известный как код проверки карты, который требуется некоторым предприятиям для покупок в Интернете.

[C] представители компании утверждали, [что] процесс совершения покупок с помощью карт включает процедуры проверки, основанные на мощном шифровании, которые делают каждую транзакцию уникальной. По их словам, большинство карт на самом деле передают фиктивный номер, который не совпадает с номером, выбитым на карте , и этот номер можно использовать только в сочетании с проверочным «токеном» или небольшим битом кода, который шифруется перед отправкой . отправлено .

«По сути, это бесполезная информация», — сказал Дэвид Боналле, вице-президент и генеральный менеджер по авансовым платежам в American Express. «Вы не можете украсть эти данные, просто воспроизвести их и ожидать, что транзакция сработает».

(Выделение мое.)

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

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

Я не знаю, что думать о видео Адама Сэвиджа, но, учитывая вышеизложенную информацию, не думаю, что вам стоит об этом беспокоиться. :)

У меня есть анекдот, чтобы пойти с этим. У меня есть две кредитные карты с NFC (RFID), и по крайней мере для одной из них я могу прочитать хотя бы номер карты с телефона NFC. Карты от британских банков, и я получил их в 2014 году. Обратите внимание, что многим продавцам не нужно ничего, кроме номера карты (без CVV), один из таких примеров — Amazon.
Росс Андерсон из Кембриджского университета исследует (и находит) уязвимости в реализации бесконтактных кредитных карт, см., например: cl.cam.ac.uk/~rja14/Papers/rfid-fc07.pdf
Итак, я предполагаю, что это что-то вроде того, что читатель генерирует случайный токен, отправляет его на карту, карта шифрует токен своим закрытым ключом и отвечает зашифрованным сообщением, включая токен, читатель сверяет его со своим открытым ключом. Это типа правильно?
@томр, да; насколько я понимаю, это правильно. Перейдите по этой ссылке для более подробного технического объяснения: security.stackexchange.com/a/71370/44582