Как стать автором
Обновить

Комментарии 22

В этот момент в игру вступал второй чип, который позволял хакерам завершать транзакцию с использованием любого PIN-кода.
Как это возможно?
habrahabr.ru/post/229527
Независимо от того, каким образом и кем (эмитент карты или платежная сеть) была получена вся необходимая информация, сама проверка PIN выполняется на HSM, который для выполнения проверки получает ключ PPK в защищенном виде, ключ проверки PIN в защищенном виде, зашифрованный PIN блок, проверочное значение PIN и дополнительные данные проверки, в ответ на что возвращается только результат проверки: верный PIN, неверный PIN, прочая ошибка. Т.е. в процессе проверки система, отвечающая за авторизацию, с самим открытым значением PIN кода никак не соприкасается.
Тоже кажется ничего не понятным. Чтобы наклепить сверху свой чип, надо украсть карту. Ок. Далее, подбрасываем обратно человеку его карту. Тот начинает(продолжает) ею пользоваться как ни в чем не бывало. Допустим, чип настолько крутой, что разгадывает код и запоминает информацию. Но теперь, получается, надо снова украсть эту карту, чтобы считать данные с чипа? Ведь чип не может взломать POS-терминал и полезть в интернет, сливать через POS инфу о карте…
Думаю, все проще. POS может не всегда быть на связи с банком. В этом случае он может провести оффлайн-транзакцию, о которой отчитается банку потом, когда выйдет на связь. Однако, чтобы такое сделать, ему должен это разрешить чип (подмена чипа как раз может служить этой цели) и настройки самого POS-а, которые прогружаются из процессинга. PIN в этом случае также проверяет чип.

Так что градус истерии явно завышен.
Подробные ответы на данные вопросы опубликовал участник группы Хабрахабр ВК — Владислав Турман. Чтобы не повторяться, публикую ниже цитаты:

1) Карту своровали, наклеили на нее чип, который на любой пин-код отвечает, что он верный
2) Засунули эту карту в банкомат
3) ввели рандомный пин-код и фейковый чип ответил, что код верный
5) сняли бабосов, при этом


атака-по-середине подразумевает перехват информации между настоящим чипом и банкоматом и подмена нужной информации. В данном случае меняется лишь ответ настоящего чипа на запрос о проверке пин-кода. Банкомат спрашивает настоящий чип: «верный ли пинкод ввел пользоватеь», а фейковы чип отвечает вместо настоящего «да». При этом все остальные операции делает настоящий чип. на них поддельный не влияет. Это если весь процесс упростить) На самом деле я думаю там все в разы сложнее, но это уже на пальцах не объяснить
НЛО прилетело и опубликовало эту надпись здесь
Получается, ответ, что пин верный, не подписывается ЭЦП? Или подписывается, но терминал не проверяет?
НЛО прилетело и опубликовало эту надпись здесь
Насколько я понял (я могу быть неправ) — они крадут карту, и приклеивают на неё свой чип, который вместе с картой суют в банкомат, а когда происходит проверка pin, то хацкерский чип подменяет
только результат проверки: верный PIN, неверный PIN, прочая ошибка
, который криптографически не защищён. Если бы юзать обычную ЭЦП (т.е. банк генерирует рандомную строку, которая подписывается карточкой и проверяется в банке), то (имхо) было бы безопаснее.
Так и есть, только наоборот — чип генерирует криптограмму на основе данных транзакции (тип, сумма, случайность) шифруя ее своим ключем и передает в банк. Банк проверяет криптограмму и дает зашифрованный ответ, который проверяет чип. В нагрузку еще может и какие-то данные на чип прогрузить, с лимитами, например.

Банк, как понимаете, не может сам начинать что-то передавать, ведь он не знает, когда вы захотите совершить транзакцию и где.
Распознавание лиц при покупке онлайн, говорите?
Ну значит после кражи карты преступникам теперь будет достаточно просто сделать фото «счастливчика».
Вообще, странная идея заменять авторизацию по секретной информации авторизацией по общедоступной. Они там часом не перепутали авторизацию с подписью?
Какая-то очень поверхностная статья для компании, которая занимается безопасностью. Выше уже написали несколько вопросов.

Вопрос — оригинальный чип с динамическим кодом был?
Схема с использование реальной карты и подменой APDU команд на лету стара настолько, на сколько стара технология чиповых карт. И появление попыток мошенничества с использование «прокси схемы» всегда нужно учитывать.
Единственное, что раньше (еще 3-4 года назад) это можно было «на коленке» сделать только через шлейф (банкоматы обычно от этого защищены), а теперь можно просто заказать ARM контроллер в Китае без корпуса встроить прямо в пластик карты. Или обычный контроллер в LQFP корпусе и сточить «лишнее»

Суть уязвимости.

EMV карты в Европе (которые я ковырял) выпускаются с CVM где приоритет проверки выглядит как: offline encypted PIN -> offline plain PIN -> on-line PIN -> cardholder signature. В России, кстати, большинство банков ставит on-line PIN более приоритетным, чем off-line PIN.
On-line PIN и off-line PIN имеют свои плюсы и минусы… И оба решения имеют права на жизнь.
Хотя, лично я бы вообще off-line plain PIN не использовал в конфигурациях карты. Из общих соображений… уж лучше on-line PIN если карта без RSA.

Как это могло сработать:
  1. Дополнительный чип (с этим даже ATMega на 16 Мгц справится, хотя и на грани) перехватывает команду Verify, не передавая ее чипу карты. Вместо него отвечая терминалу «OК» (SW:9000) на команду Verify.
  2. Терминал выставляет бит в TVR что PIN «проверен»!
  3. Терминал принимает решение (PIN то «проверен») что может обслужить карту в off-line (например) или отправляет в on-line, но при этом в TVR указано что PIN «проверен».


Таким образом, можно обмануть risk management терминала, но не карты (эмитента)!
Карта все равно «знает» что ей PIN не предъявлялся вообще.

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

В данном случае возможны два варианта:
  1. «Уязвимость» это результат грубой ошибки в настройках либо профиля персонализации карты. Например CIAC маски для MChip, разрешающие off-line транзакцию без PIN. Да еще большие off-line лимиты или вообще без проверки лимитов (хотя звучит бредово).
  2. Хост авторизации эмитента не проверял CVR биты или просто не учитывал факт не предъявления off-line PIN карте (то же звучит как грубая программная ошибка). Транзакция выполнялась в on-line"


В любом случае — это ошибка сотрудников банка и/или проц. центра. Ошибка программная или настройки.

Хотя… Есть еще один вариант… Глядя на тесты EMV CCD и некоторые конфигурации (A45, A29 или A21, например), которые они покрывают, мне вспоминается классический анекдот про Чапаева, общество джентльменов, игру в покер и веру на слово. А раз эти варианты появились в EMV CCD тестах, значит они и где то массово (!) используются! Так что это первая ласточка с прокси схемой!

Так что, это может быть не ошибки настройки, а так было задумано «для удобства» владельца карты.
Вот только «игроки» попались не джентльмены.

Любопытно было бы глянуть на профили этих карт… Жаль все статьи без подробностей и упоминаний конкретных банков. Хотя как раз это легко понять.

Хорошо, хоть у Российских банков я встречал только варианты «без удобств для пользователя», в которых прокси схема не сработает.

P.S. То что я рассказал — это отнюдь не «сакральные» знания. Все достаточно тривиально. Просто сотрудники, работающие с картами ВСЕ это должны были учитывать и понимать, не надеясь на «авось».

Зачем существует «offline plain PIN»? Дыра же.
off-line plain PIN… Потому что:
1. Это было еще в спецификации EMV96 (по историческим причинам, опираясь на опыт чиповых карточных продуктов того времени).

2. Карты без RSA пока еще дешевле и используются для дебетовых чисто on-line карточных продуктов (хотя подозреваю, что это чисто маркетинговая политика NXP, Oberthur, Gemalto и прочих).

3. Криптомодулей (клавиатур/PINPAD), поддерживающих только банальный 3DES PIN-блок для on-line PIN еще очень много и обновление дело не быстрое.

4. В Европе широко распространен примем карт в режиме off-line PIN
— 4.1 Исторически осталось/есть от локальных карточных платежных систем на чипе.
— 4.2 Накладные расходы по загрузке TMK/TPK ключей в модули клавиатур и PINPAD довольно высоки и решение «off-line PIN для чипа» и «подпись на чеке без PIN для магнитки» широко распространены в POS.

В общем… «так получилось». Исторически сложилось. B не всегда требования безопасности определяющие. Иногда важнее удобства 100000 пользователем, чем проблемы одного, у которого деньги стырят.
Фигня все это. Битва шита и меча…
На заре карточных технологий банки (Италия) на 3-ю полосу магнитки остаток писали и в банкомате деньги выдавали в off-line перезаписываю 3-ю полосу.

P.S. Ни разу не видел профиль EMV карты где в CVM был бы «encypted off-line PIN», но не было бы «plain off-line PIN». И во всех рекомендованных платежными системами (Visa, MC, UPI и «другие») профилях карточных продуктах, предусмотрен «off-line plain PIN».

P.S. Меньше знаешь — крепче спишь. У меня на моих картах только необходимый минимум… Хотя карты — это мой хлеб.

НЛО прилетело и опубликовало эту надпись здесь
>У человека украли карту и модифицировали её. Модификация не быстрых процесс…
В принципе, вырезать в пластике карты полость по корпус микросхемы (типа FQFPN толщиной 0.5-0.9 mm и размером 7x7 mm) и подпаять 5 проводков это не так что бы и медленно. С написанием ПО для эмуляции транспорта ISO-7816 справится любой студент, с опытом разработки программ для контроллеров.

>Но тогда как POS терминал знает, что у человека есть эта сумма на счету?
Если упрощенно и без спец. терминологии и без частностей, то во время EMV транзакции терминал, после получения данных с карты:
1. Выполняет все необходимые проверки c использованием карты:
— аутентификации эмитента карты: опционально SDA/DDA/CDA (RSA)
— аутентификации владельца карты: опционально off-line PIN.
2. По своим критериями, заданными настройками, выполняет (если задано) стандартные проверки по лимитам (суммы, количество, случайна авторизация).
опциональность задается настройками/свойствами терминала.

После выполнения всех проверок, терминала принимает решение «может ли он обслужить эту карту в off-line, on-line или вообще отказать в обслуживании».

После чего, это решение передается в карту вместе с суммой транзакции, валютой и пр…
Карта выполняет свои проверки (различные off-line лимиты, включая накопительные, признаки что был ей проверен off-line PIN и в каком режиме и пр.).
Маска принятия решения и уровень лимитов задаются на этапе персонализации (выпуска) карты или (если банк/ПО процессинга умеет) после выпуска во время любой on-line операции, когда карта уже на руках клиента.

После этих проверок (внутри карты) карта может отказаться от предложенного off-line и потребовать on-line или вообще отказать в транзакции.

>Они не занимались клонированием чипов?
Случаев клонирования банковских чипов не было. И скорее всего не будет.
Пусть теоретически это возможно. Ну очень теоретически, деструктивными методами без гарантии и на очень и очень дорогом оборудовании с привлечением специалистов очень высокой квалификации. Есть много способов программных и аппаратных помешать «вытаскиванию» ключей с карты и все они применяются производителями кристаллов и OS.
Овчинка выделки не стоит…
НЛО прилетело и опубликовало эту надпись здесь
Да. Я бы то же предположил что не менее часа и то в идеальном случае.

В общем, лично мне кажется этот способ сомнительным. Сработает только если не спохватились и не заблокировали карту.
Типичный off-line лимит на кредитной карте — 50-100Euro. Ну пусть даже 200Euro…
А POS терминалы в магазинах с потенциальными рисками (ювелирка, электроника и т.п.) обычно в on-line настроены. Банкомат, работающий в off-line — это вообще нонсенс.

А покупка тряпок и т.п. не слишком привлекательна для мошенника… наверное…
А так. по ворованной чиповой карте, можно например:
… Сходить в туалет на вокзале в Осло… (PIN правда не требует)…
… Заплатить за платную дорогу… купить колу…
В общем по мелочи за раз в пределах в среднем 10-20Euro в пределах накопительного off-line лимита по сумме и количеству. Желательно в там где нет on-line в принципе (такое редко), что бы не нарваться на «случайную авторизацию».
Шпану, покупающую колу по ворованной/найденной карте — могу представить. Вора с паяльником/лупой и кучкой прошитых контроллеров для покупки колы — с трудом.

Наверное, всех же эта была ошибка в ПО процессинга, выдававшего разрешение на «без PIN операции» не обращая внимание на тип операции, тип терминала и сумму операции. (В принципе, on-line операции без PIN возможны в пределах определенных сумм и от определенных терминалов)
И банкоматы выдавали деньги в on-line по карте, которой не было PIN. Иначе смысла мошенникам в этой суете с прокси чипом нет вообще.
И то, сработает если не успели/забыли/поленились заблокировать.

Если карта запросила on-line и хост ей ответил «OK», то в card risk management на второй GenerateAC уже проверка выполнения off-pin не входит. Хост сказал «ДА» карта подтвердит транзакцию терминалу.

Все равно, подробной информации не было и не будет.
А все эти статьи — это кто то где то услышал и пересказал в стиле подписи в газете под фотографией высоковольной линии: «По этим изоляторам пойдет ток в родной город»

Есть много способов программных и аппаратных помешать «вытаскиванию» ключей с карты и все они применяются производителями кристаллов и OS.

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

Программные средства на самом низком уровне — это реализация криптографических функций в ядре ОС что бы усложнить криптоанализ на основе анализа энергопотребления в момент вычислений, так же анализ путем искажения данных в ОЗУ внешним воздействие (ренген, УФ на вскрытый чип, питание и пр.)
На более высоком уровне есть куча рекомендаций на разработку прикладных безопасных апплетов.
Например дополнительный контроль порядка выполнения кода апплета. Рекомендация не использовать в Boolean типы в критичных местах, а использовать магические константы как true|false. Дополнительно программными действия для отслеживания транзакционности в критичных местах… ограничение на количество раз использования ключей… и т.д.
Как вишенка на торте — самоубийств апплета при признаках его взламывания.
В общем тема безопасного ПО для чипа она большая и это не на 5 минут…
Иногда (не буду тыкать пальцем в конкретного производителя карт) это доходит, на мой взгляд, до маразма (самоубийство данных апплета) и… в общем не буду углубляться. Кто знает, тот знает кого я имею в виду.

В качестве аппаратной защиты (вскрытия и анализа) на кристаллах используют свои методы. Что то там с матрицей памяти что бы усложнить анализ, металлизацией и пр.
Впрочем, в это вникал только из любопытства и подробности уже не помню, а архивы с материалами семинаров подымать лень.
Читал об этом на Хакере пару недель назад. Эта ситуация была ещё в 2011-м году, и сейчас, если верить статье, данная ошибка уже устранена.
Зарегистрируйтесь на Хабре , чтобы оставить комментарий