С появлением на рынке микропроцессорных платежных карт наряду с хорошо и давно знакомым к этому времени методом для верификации держателя карты PIN Online, когда значение ПИН проверяется эмитентом карты на его хосте, начал повсеместно применяться метод PIN Offline.

Суть метода PIN Offline состоит в том, что эмитент карты делегирует проверку ПИН своей карте. Сама карта проверяет значение ПИН, введенного пользователем на терминальном устройстве, сравнивая его с референсным значением, защищенным образом хранимым в платежном приложении карты.

Несмотря на то, что оба метода верификации параллельно используются вот уже 15 лет, до сих пор иногда приходится слышать вопросы: какой метод обеспечивает более высокую безопасность при обработке операции- PIN Online или PIN Offline? И вообще- можно ли эмитенту (банку, выпустившему карту) обойтись только одним из указанных методов проверки ПИН? Например, методом PIN Online. Очевидно, с точки зрения эмитента этот метод проще метода PIN Offline при реализации процедур персонализации карты, изменения ПИН держателем карты, контроля лимита на число попыток ввода неверных значений ПИН, поскольку в этом случае перечисленные процедуры выполняются только на хосте эмитента и не требуют применения дополнительных действий на стороне платежного приложения карты.

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

Проще всего ответить на вопрос о том, можно ли на практике обойтись одним методом верификации. Более универсальным для применения является метод PIN Online, который поддерживается практически всеми терминалами, обеспечивающими верификацию ПИН-кода. Исключение составляют терминалы, способные функционировать только в офлайновом режиме (Offline Only терминалы).

Заметим, что отказ от применения метода PIN Offline не приводит к отказу от использования офлайновых операций. Для офлайновых транзакций можно применять альтернативные методы верификации держателя карты- подпись и/или биометрическую верификацию (справедливости ради отметим, что биометрия на картах сегодня практически не используется).
Метод PIN-offline не применяется в банкоматах и в операциях с использованием бесконтактных карт — может возникнуть ситуация, когда карта блокируется из-за превышения лимита неуспешных попыток ввода ПИН, а клиент об этом даже не знает. Кроме того, из-за необходимости шифрования ПИН-блока открытым ключом карты время выполнения операции существенно увеличивается, что плохо отражается на бесконтактных платежах, выполняемых в режиме Tap&Go. Поэтому обойтись только методом PIN Offline для обработки карточных транзакций не получается.

Может быть, имеет смысл ограничиться использованием метода PIN Online?
Мне, Igorgold, эта идея кажется плохой.

PIN Offline — надежный инструмент для верификации держателя карты в офлайновых операциях и менять его на подпись (единственный альтернативный массово доступный метод верификации для офлайновых операций) – заметная потеря уровня обеспечиваемой безопасности операции.

Таким образом, оба метода верификации держателя карты востребованы в карточных технологиях, и можно вернуться к первому вопросу: какой метод проверки ПИН обеспечивает более высокую безопасность карточной операции?

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

При использовании метода PIN Offline проверка ПИН делегируется эмитентом карте. В отличие от метода PIN Online, когда ПИН шифруется на банкомате/POS-терминале и в зашифрованном виде (после нескольких перешифрований на пути к хосту эмитента) попадает на проверку к эмитенту, в случае PIN Offline эмитент сам значение ПИН не проверяет и может пользоваться только информацией карты и терминала относительно результатов верификации держателя карты. Заметим, что этими данными эмитент может воспользоваться только в случае онлайновой авторизации операции. При офлайновой транзакции все решения по ее авторизации делегируются эмитентом своей карте (точнее платежному приложению на карте).

Ниже рассмотрим две угрозы, которые могут возникнуть при таком делегировании проверки ПИН, т.е. при использовании метода PIN Offline. Еще раз заметим, что речь пойдет об угрозах второго порядка малости. На практике реализация этих угроз не фиксировалась, и они носят в основном академический характер. Их внедрение слишком дорого и сложно в сравнении с другими известными методами мошенничества…

Первая угроза связана с попыткой мошенника, у которого оказалась карта с неизвестным ему ПИН, обойти проверку ПИН. Для этого мошенник «вживляет» в карту специальный микропроцессор (т.н.wedge device), который с одной стороны подключен к контактной площадке карты, а с другой- работает с настоящим чипом карты, полностью контролируя APDU-команды терминала и ответы карты на эти команды (атака типа Man-in-the-Middle). В результате построенной конструкции все команды терминала попадают на чип карты через wedge device. Для проверки PIN Offline терминал передает карте команду Verify с зашифрованным значением ПИН, которая попадает на wedge device. Значение ПИН вводится мошенником, а потому с высокой вероятностью оно не совпадает (мошенник не знает значение ПИН) с референсным значением, хранимым на карте.

Далее мы покажем, что на «правильной» карте, каковой является, например, карта «Мир», обойти проверку ПИН возможно только по решению эмитента, готовому взять на себя риски, связанные с отсутствием проверки ПИН или даже со знанием факта о проваленной проверке PIN Offline. Я не стану здесь утруждать читателя номерами байт и бит используемых для этого объектов данных и терминала, а также детальным описанием выполняемых картой проверок.

Для понимания дальнейшего читателю понадобится минимальное знание о следующих объектах данных:
Card Verification Results (CVR) — объект данных карты, в том числе фиксирующий факт проверки картой PIN Offline, а также результат проверки PIN Offline (успешная/неуспешная). Кроме того, объект CVR содержит 4 младших бита двоичного представления количества доступных держателю карты проверок PIN Offline;
Terminal Verification Results — объект данных терминала, в том числе указывающий на результат верификации держателя карты, факт использования метода PIN Online при обработке транзакции и факт превышения лимита на ввод неверных значений ПИН;
CVM Results – объект данных терминала, указывающий на способ верификации держателя карты (например, PIN Offline, PIN Online, Подпись, No CVM) и результат верификации.

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

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

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

Далее, в зависимости от злонамеренного поведения устройства wedge device, возможны следующие случаи.

Случай 1. Устройство wedge device не меняет содержание команды Verify, проверка PIN Offline оказывается проваленной. Этот факт будет зафиксирован в объекте CVR и CVM Result, и эмитент карты вряд ли решится в этом случае авторизовать транзакцию на существенную сумму. Чаще всего в подобных случаях эмитент транзакцию отклоняет независимо от размера транзакции.
Поэтому во всех описанных далее случаях wedge device пытается изменить диалог терминала с картой с тем, чтобы обмануть эмитента и не продемонстрировать ему факта незнания держателем карты ПИН.

Случай 2. Устройство wedge device на команду Verify отвечает терминалу подтверждением факта успешной проверки ПИН и не передает команду карте. После этого возможны варианты a-c, описанные ниже.

2a. Команда Generate AC не содержит объекта CVM Results (для карты Мир этот объект является обязательным). В этом случае карта на основании того, что проверка PIN Offline не выполнялась, формирует криптограмму ARQC, требующую обработки операции в онлайновом режиме, или криптограмму ААС (отклонение операции) в случае, если терминал имеет тип Offline only (функционирует только в офлайновом режиме).
Эмитент, получив авторизационный запрос, сравнивает флаги CVR (PIN Offline not performed) и CVM Results (PIN offline successful) и из-за противоречия данных в этих объектах отклоняет транзакцию.

2b. Команда Generate AC содержит CVM Results, и wedge device передает его карте без искажения (PIN offline successful).
Карта фиксирует противоречие с данными CVM Results (терминал ошибочно считает проверку PIN offline успешной) и либо отклоняет операцию в случае Offline Only терминала, либо отправляет авторизационный запрос эмитенту на его решение. Эмитент на основании своих процедур управления рисками принимает решение. Конечно, учитываются данные карты PIN Offline not Performed и того, что была попытка обмануть карту при принятии ею решения.

2с. Команда Generate AC содержит CVM Results, и wedge device передает этот объект данных на карту измененным (например, указывает в нем в качестве метода верификации держателя карты Подпись).

Если карта поддерживает CDA (карта «Мир» всегда поддерживает метод CDA), то терминал отклонит операцию в офлайновом режиме, поскольку объект CVM Results был изменен, и это обнаружится после расшифрования подписанных картой данных.

Если CDA не поддерживается, то операция уйдет эмитенту или будет отклонена в офлайновом режиме для терминалов типа Offline Only. Здесь имеет место полная аналогия с п.2a.

Случай 3. Устройство wedge device сообщает терминалу в ответ на команду Get Data с указанием тэга объекта PIN Try Counter (9F17) о том, что PIN Try Limit Exceeded. Команда Get Data всегда используется терминалом до начала проверки PIN Offline, чтобы узнать о возможности проведения этой проверки- если PIN Try Limit превышен, выполнение проверки PIN Offline невозможно и не проводится.

Карта должна ответить отказом из-за противоречия в данных объектов TVR (PIN Try Limit Exceeded) и CVR (PIN Try Counter не равен 0).

Изменить значение TVR устройство wedge device не может, так как при попытке это сделать либо провалится CDA (если карта поддерживает CDA, как в случае карты «Мир»), либо неуспешно завершится проверка ARQC на стороне эмитента, если карта CDA не поддерживает.

Случай 4. Устройство wedge device посылает карте серию команд Verify с неверным значением ПИН, пока в ответ на команду Get Data не получит в ответ PIN Try Limit Exceeded.

В этом случае карта потребует выполнения онлайновой авторизации эмитентом. Честно говоря, шансы на одобрение транзакции эмитентом в этом случае не намного выше, чем в случае, когда провалилась проверка PIN Offline. Но теоретически при обработке операции на незначительную сумму такое событие может произойти.

Обобщая сказанное выше, в некоторых случаях мошенник имеет шанс обойти проверку PIN Offline, хотя потери эмитента при его разумном поведении будут весьма умеренными.

Другой способ обойти проверку PIN Offline – использование виртуального клонирования карты. Суть этой схемы мошенничества состоит в следующем.

Мошенники контролируют терминал в некотором торгово-сервисном предприятии (например, ресторане). Кроме того, они изготавливают специальную микропроцессорную карту, имеющую стандартный контактный интерфейс ISO 7816 и радиоинтерфейс, функционирующий в соответствии с одним из коммуникационных протоколов, обеспечивающих связь на расстоянии от нескольких десятков сантиметров до нескольких метров (например, ISO 15693, ISO 18000). С помощью такого радиоинтерфейса карта может обмениваться данными со специальным оборудованием, которое помимо поддержки связи с картой обеспечивает организацию удаленного радиоканала (например, в соответствии с протоколом Wi-Max (IEEE 802.16), см. рис.1) с контролируемым мошенниками терминалом.

Мошенник, вооружившись описанными выше картой и специальным оборудованием, приходит, например, в ювелирный магазин и выбирает там украшение стоимостью 200 000 рублей. В это время в ресторане завершает обед ничего не подозревающий держатель карты, которую он предъявляет официанту для оплаты обеда стоимостью 200 рублей. Официант является сообщником нашего любителя ювелирных украшений. Он звонит ему и предупреждает, что у него в руках действующая карта посетителя.

Дальше мошенники действуют следующим слаженным образом. Мошенник-официант вставляет карту посетителя в контролируемый мошенниками терминал и вводит в терминал стоимость обеда. В это же время мошенник в ювелирном магазине передает кассиру для оплаты украшения свою поддельную карту, которую кассир вставляет в настоящий терминал. Далее все команды терминала, установленного в ювелирном магазине, через карту мошенника, его специальное оборудование и мошеннический терминал транслируются реальной карте пообедавшего в ресторане господина. При этом ответы реальной карты на команды реального терминала по тому же маршруту, но в обратном направлении возвращаются реальному терминалу.

При этом некоторые команды требуют преобразования содержащихся в них данных. Например, если реальная карта требует выполнения проверки ПИН, то мошенник в ювелирном магазине введет на терминале произвольную последовательность. После того, как команда VERIFY от реального терминала будет транслирована на мошеннический терминал, теперь уже этот терминал затребует ПИН у посетителя ресторана, который введет его на мошенническом терминале. Далее мошеннический терминал передаст реальной карте команду VERIFY со значением ПИН ее держателя, а ответ карты будет передан реальному терминалу в ювелирном магазине. Важно отметить, что команду VERIFY с правильным значением ПИН необходимо довести до карты, чтобы факт проверки PIN Offline был зафиксирован в объекте CVR, предназначенном для эмитента.

Очевидно, что даже онлайновая авторизация операции не помешает успешному выполнению операции по описанной выше схеме. В этом случае в ответ на команду GENERATE AC реального терминала реальная карта сгенерирует криптограмму ARQC, которая будет возвращена терминалу ювелирного магазина и далее передана на хост эмитента. Наоборот, ответ эмитента, содержащий Issuer Authentication Data, будет транслирован реальной карте, вставленной в мошеннический терминал.

В результате операция может закончиться печально для посетителя ресторана и ювелирного магазина. Банковский счет посетителя может уменьшиться на 200 000 рублей. При этом посетитель ресторана получит чек на стоимость обеда и, вероятнее всего, будет находиться в неведении о случившемся до получения справки о состоянии своего банковского счета или SMS-уведомления от эмитента о выполненной мошенником онлайновой операции. Более того, возможно сделать так, что и на чеке, выданном мошеннику в ювелирном магазине, будет красоваться часть номера его карты, так что бдительный продавец ювелирного магазина и здесь не увидит проблем с безопасностью операции.

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

Рис.1. Виртуальное клонирование карты

Очевидно, что приведенная выше схема не работает в случае применения метода PIN Online. Если проанализировать описанное выше мошенничество, то станет ясно, что оно оказалось возможным из-за отсутствия прямого взаимодействия (диалога) держателя карты и карты. Между держателем и картой стоит посредник в виде терминала, способный исказить информацию об операции таким образом, что держатель карты в процессе обработки операции этого искажения не увидит. Этот посредник, помимо прочего, может и украсть важную информацию карты, включая ПИН ее держателя.

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

Таким образом, если говорить о величинах второго порядка малости, то метод PIN Online является более безопасным с точки зрения транзакционной безопасности.

Тем не менее, в заключение все-таки хочется сказать несколько слов в поддержку метода PIN Offline. Оказывается, что если для проверки ПИН методом PIN Online эмитент применяет метод Visa PVV (самый распространенный на практике случай), то вероятность угадать правильный ПИН карты у мошенника выше аналогичной вероятности при использовании метода PIN Offline.

Ниже будем рассматривать ПИН-коды длиной 4 цифры. Обозначим через N и M-соответственно мощности множеств всех возможных значений ПИН и PVV соответственно. Очевидно, N=M=〖10〗^4. Кроме того, обозначим p=1/M=〖10〗^(-4) и q=1-p.

Очевидно, что вероятность того, что значению PVV карты соответствует ровно k значений различных ПИН (очевидно, это количество ПИН является случайной величиной, которую мы обозначим через θ) равна
P{θ=k│θ≥1}=(P{θ=k})/(P{θ≥1})=(C_N^k p^k q^(N-k))/(1-q^N ), откуда вероятность угадать ПИН за одну попытку равна p/(1-q^N )≈p(1+q^N)≈1,368∙〖10〗^(-4).

При использовании метода PIN Offline вероятность с помощью m попыток угадать ПИН равна mp=m〖∙10〗^(-4), а при применении PIN Online эта вероятность приблизительно равна mp(1+q^N)=1,368〖∙10〗^(-4)∙m, т.е. на 0.0368% выше, чем в методе PIN Offline. Это, конечно, смешное увеличение вероятности компрометации ПИН, но тем не менее к величине второго порядка малости его вполне можно отнести.