Платежные карты прочно вошли в нашу жизнь. Еще совсем недавно повсеместно использовались только карты с магнитной полосой. Сегодня же никого не удивишь картой с чипом. Всем известно, что чиповая, микропроцессорная или, созвучнее, платежная EMV-карта – современный и надежный способ доступа к расчетному счету. Она безопаснее карты с магнитной полосой и ее практически невозможно подделать. Однако детали реализации «внутренностей» EMV-карты мало известны. Всем кому интересно как работает EMV-карта, почему технология EMV обеспечивает безопасность платежей и насколько стоит всему этому доверять – добро пожаловать под кат.
1. Введение
О каких картах пойдет речь?
Сегодня международные платежные системы (МПС) используют стандарт EMV для проведения операций по банковским картам. Одними из наиболее известных МПС, стоящих у истоков разработки этой технологии, являются компании «VISA Inc» и «MasterCard Worldwide». Поскольку в основе микропроцессорных карт этих компаний лежит общая технология EMV, мы будем рассматривать обобщенную EMV-карту, не вдаваясь в детали реализации той или иной компании.
Стоит сразу отметить, что спецификация EMV достаточно большая, поэтому статья не претендует на полное описание стандарта. Многие вещи будут представлены в упрощенной форме без использования специфической терминологии. Так как стандарт является открытым, при желании всегда можно ознакомиться и разобраться в деталях на сайте EMVCo.
Описывая платежные транзакции и функциональность EMV-карты, мы будем ссылаться на других участников системы. Помимо самой платежной системы в процессе проведения транзакции участвуют:
- банк-эмитент – банк, который выпустил платежную карту, и счет которой находится в этом банке
- банк-эквайер – банк, который обслуживает терминал платежной точки
- платежный терминал – устройство, которое обеспечивает работу с платежной картой
Рассматривая подробнее платежную EMV-карту, мы будем концентрировать внимание не только на возможностях микропроцессора. Технология EMV подвергла изменениям как сами карты, так и сообщения, которыми обмениваются участники системы; расширила функциональность приложений для терминалов, банков-эквайров и эмитентов.
2. Аутентификация магнитной и EMV-карты
Одна из основных задач банка, выпустившего карту – это аутентификация карты в ходе ее использования. В данном случае под аутентификацией понимается процесс доказательства того, что данная карта (или приложение на карте) выпущена банком, авторизированным на это соответствующей платежной системой.
Как происходит процесс аутентификации карты?
В общем случае, прочитав данные карты, терминал отправляет их через банк-эквайер и платежную систему банку-эмитенту. Эмитент на основании данных карты определяет ее подлинность.
В этом процессе заключается одна из основных проблем безопасности платежей по магнитным картам. С одной стороны, целостность данных магнитной карты надежно защищена кодом CVV/CVC (CVC – Card Verification Code, CVV – Card Verification Value) и модифицировать их бесполезно. С другой стороны, довольно просто скопировать всю карту целиком.
2.1 Аутентификация магнитной карты на основе статических данных
Для аутентификации в транзакциях по магнитной карте используются статические данные карты. Эти данные карты каждый раз передаются в банк-эмитент и не меняются на протяжении всего срока действия карты. Вдобавок, платежный терминал практически не оценивает риски транзакций по картам с магнитной полосой. В итоге – в случае полного копирования карты – банк-эмитент не сможет достоверно определить подлинность такой карты. Соответственно, вероятность проведения мошеннической операции достаточно высока.
2.2 Аутентификация EMV-карты на основе динамических данных
Как этот вопрос решают EMV-карты?
Решением вышеописанной проблемы является цифровая подпись статических данных карты и данных транзакции, которые отправляются эмитенту. Поскольку цифровая подпись является уникальной для каждой транзакции, подделка или копирование EMV-карты является нетривиальной задачей.
Рассмотрим подробнее, как происходит динамическая аутентификация карты в ходе EMV-транзакции. Процесс транзакции начинается в момент установки карты в терминал. Терминал передает карте данные транзакции (сумма, валюта, страна и т.д.). Затем карта и терминал производят взаимную проверку рисков транзакции. Если оба устройства все «устраивает» то карта подписывает данные транзакции, а терминал заполняет полученными данными поле (таг или тэг) «DE 55» и отправляет его в банк-эквайер. Тот, в свою очередь, отправляет сообщение банку-эмитенту.
Эмитент, получив поле «DE 55», проверяет подлинность подписи (далее криптограммы) карты, которая рассчитана на основании динамических данных текущей транзакции, тем самым проверяя подлинность самой карты.
Описанный выше процесс является сильно упрощенной моделью EVM-транзакции. Однако он раскрывает главный аспект безопасности EVM-платежей – использование для аутентификации карты динамических данных вместо статических.
Стоит отметить, что у эмитента появляются новые возможности:
- проверка динамической криптограммы карты
- взаимная аутентификация: эмитент может выслать свою криптограмму карте
- возможность обновить данные карты после аутентификации (например, заблокировать карту или сменить лимит).
Также в EMV-транзакциях существенная роль отведена терминалу и его системе оценки рисков, согласно которой и терминал, и карта могут принимать решения о возможности проведения транзакции.
3. Внутренняя структура и безопасность EMV-карты
По большему счету, микропроцессорная карта стандарта EMV является обычной смарт-картой (почитать раз, два, три), в основе которой лежат стандарты ISO/IEC 7816 или ISO/IEC 14443 (для бесконтактной).
Реализация EMV-карты может быть выполнена как на базе JavaCard и GlobalPlatform, так и с помощью нативных методов смарт-карты. Аналогично обычными операционными системами (ОС), карточные ОС также имеют файловую структуру и приложения. В контексте этой статьи, наиболее интересны именно платежные приложения EMV-карты. Поэтому будем рассматривать именно их.
Что представляет собой платежное EMV- приложение?
C точки зрения пользователя (терминала или банкомата), платежное EMV-приложение – это программный продукт с интерфейсом, детально описанным в стандарте EMV.
Интерфейс представляет собой серию команд для проведения транзакций и управления EMV-приложениями. Подробную информацию можно найти в «EMV Book 3 Application Specification». Несмотря на существование стандарта, платежные приложения компаний Visa и MasterСard имеют отличия в реализации. Также могут отличаться и разные приложения одной компании. Например, «M/Chip 4» и «M/Chip Advance» компании MasterСard.
Вне зависимости от реализации, каждое приложение имеет свой собственный идентификатор, так называемый AID (Application Identifier). Он указывает к какому типу платежной системы относится приложение. По идентификатору приложения AID терминал определяет возможность проведения транзакции или, в случае нескольких приложений строит список поддерживаемых приложений и предлагает выбрать одно из них.
Если на карте реализована файловая структура и управление приложениями, какие же механизмы обеспечивают безопасность данных от доступа извне?
Тут стоит разделить время жизни карты до момента выпуска банком, и после.
Первичный доступ к чистой карте обычно регламентируется производителем чипов. Чаще всего каждая партия карт имеет свой ключ карты, с помощью которого необходимо аутентифицироваться с картой в ходе ее прошивки.
На следующем этапе доступ к файловой системе и приложениям обычно регулируется операционной системой. Она также имеет свой собственный ключ, и, соответственно, для доступа требуется аутентификация.
Далее установленное приложение проходит процесс персонализации карты. Персонализация представляет собой загрузку параметров и ключей приложения, которые определяют безопасность EMV-транзакций. Для доступа к этому процессу также требуется аутентификация с помощью ключа приложения.
После установки приложения и его персонализации вышеперечисленные доступы обычно закрываются навсегда. Что исключает возможность проникновения «внутрь» после выпуска карты.
Итого: ключ карты, ключ ОС и ключ приложения защищают карту от стороннего вмешательства на различных стадиях ее производства. В случае если в ходе изготовления часть карт будет дискредитирована (например, украдена), эти ключи защитят карты от вмешательства извне. А без знания ключей карты становится практически полностью бесполезными.
Некоторые данные приложения могут быть модифицированы и после выпуска карты. Изменения могут быть выполнены так называемыми скриптовыми командами. Исключительные права на внедрение изменений принадлежат эмитенту. Такая возможность предусмотрена, чтобы в любой момент времени, эмитент мог заблокировать или разблокировать карту, обновить лимиты или настройки карты. Обновление данных производится терминалом или банкоматом только после успешной онлайн транзакции (аутентификации с банком). Данные приходят на карту от эмитента в чистом виде, однако имеют в себе аналог цифровой подписи – MAC, который гарантирует целостность данных. Для расчета MAC используется соответствующий ключ приложения (один из трех DES ключей загружаемых в приложение).
Отдельными пунктами являются модификация оффлайн пин-кода (offline PIN) и счетчика лимита неудачных вводов пин-кода (PinTryLimit). Эти изменения также выполняются скриптовой командой с MAC-подписью. Однако, при смене пин-кода эти команды дополнительно шифруются с помощью специального ключа, предназначенного исключительно для выполнения описанного процесса.
4. Данные EMV-приложения
Аналогично картам с магнитной полосой, EMV-приложения также имеют открытые данные доступные для чтения. И хотя само приложение прочитать невозможно, как невозможно добраться и до ключей и пин-кода – доступ к открытым данным приложения всегда открыт.
Данные EMV приложения
О каких данных идет речь?
На картинке выше приведен ориентировочный список данных, хранящихся внутри EMV-приложения. Конечно, для каждого конкретного приложения он может несколько отличаться. На данном этапе важно отметить, что персональная информация клиента не хранится в EMV-приложении. Действительно, больший объем памяти чипа позволяет платежным системам и банкам хранить на карте больше информации – однако персональной информации клиента там нет.
Предыдущая картинка наглядно иллюстрирует факт того, что на карте хранится множество технических данных, необходимых для эффективного проведения операций и доступа к счету. Данные EMV-приложения размещаются в записях (рекордах или треках). Их список можно получить в ответ на команду «Get Processing Options». Конкретную запись можно прочитать с помощью команды «Read Record». Внутри могут находиться: сертификаты ключей, номер карты (PAN – Primary Account Number), списки методов проверки карты (CVM list– Card Verification Methods list) и множество другой информации. Чтение этих записей очень похоже на чтение треков с магнитной полосы. Данные технических настроек карты, счетчики и лимиты можно получить командой «Get Data», указав требуемый тип.
Интересно, что практически все данные о счете держателя карты и настройках приложения можно вычитать из карты без каких либо трудностей. Единственное до чего не добраться – это ключи приложения и значение пин-кода.
Можно ли скопировать данные на с одной чиповой карты на другую?
Если у вас есть карта с «чистым» (не персонализированным) приложением, то технически это реализуемо. Однако за счет отсутствия возможности сделать копию ключей карты – приложение будет генерировать неверные подписи транзакции. В результате – эмитент будет отклонять любые онлайн-операции. Также отсутствие ключей не позволит провести CDA /DDA аутентификацию. Единственная брешь — это SDA офлайн. Однако на данный момент этот метод в виде единственного метода аутентификации считается устаревшим. Далее будет детально рассмотрено, как защищена EMV-транзакция.
Можно ли скопировать данные EMV-приложения на магнитную полосу?
Из данных EMV-приложения можно составить треки для карты с магнитной полосой, за исключением одного небольшого параметра – кода обслуживания (Service Code). В качестве данных для EMV-приложения, код обслуживания указывает терминалу, что транзакция должна быть проведена с использованием приложения карты. Если взять этот код «как есть» и скопировать на магнитную дорожку – терминал будет пытаться выполнить транзакцию с помощью приложения. Казалось бы, можно отредактировать код обслуживания, но целостность данных защищена кодом CVV/CVC кодом. Он является ближайшим аналогом цифровой подписи.
Создается ощущение, что EMV-карта защищена от копирования со всех сторон. Хотя все-таки известна одна тривиальная возможность. Для режима совместимости производители выпускают EMV-карты комбинированного типа – то есть с микропроцессором и магнитной полосой. Существует возможность скопировать данные магнитной полосы на другую комбинированную карту с нерабочим чипом (чистым или сожженным) и попытаться провести так называемый fallback (при невозможности считать чип, терминал проводит операцию по магнитной полосе). В данный момент такие операции не приветствуется платежными системами, а риск по этим операциям ложится на эквайра или эмитента.
5. Безопасность EMV-транзакции
Существует два разных (хотя и выполняющих одну и ту же функцию) варианта проведения платежной транзакции – онлайн и офлайн. Выше мы в общих чертах рассматривали онлайн-транзакцию, которую эмитент подтверждает в режиме реального времени. Офлайн-транзакция проводится терминалом без моментального подтверждения банком. Такие транзакции используются для операций с низким уровнем риска или в случае, например, отсутствия связи с банком-эмитентом.
Для этих двух видов транзакций существует соответственно два вида аутентификаций – онлайн и офлайн. В случае выполнения онлайн-аутентификации, операция производится с участием эмитента, а офлайн-аутентификация подтверждается платежным терминалом. Стоит уточнить, что во время проведения онлайн- транзакции может выполняться как онлайн-, так и офлайн-аутентификация одновременно (если и карта, и терминал это поддерживают). Несмотря на избыточность схемы, на этапе аутентификации не всегда понятно в каком режиме будет проходить транзакция.
Порядок выполнения транзакции карта – терминал
Функции безопасности, рассматриваемые ниже, являются только частью EMV-транзакции. Помимо аутентификации, к функциям безопасности можно отнести: оценку рисков проведения транзакции и верификацию держателя карты (онлайн и офлайн-пин, размер суммы транзакции, страна, валюта, прочее).
5.1 Онлайн EMV-транзакция
Основным методом подтверждения подлинности карты в онлайн-транзакциях является аутентификация карты онлайн. В основе данного метода лежит генерация картой криптограммы ARQC (Authorisation Request Cryptogram) для каждой платежной операции. Давайте рассмотрим этот процесс подробнее.
Онлайн EMV-транзакция
В основе генераций и проверок криптограмм лежит алгоритм 3DES. Эмитент и карта владеют общим секретным ключом MKac (Application Cryptogram Master Key). В начале транзакции карта генерирует на основе MKac сессионный ключ SKac (Application Cryptogram Session Key). Криптограмма ARQC длинной 8 байт генерируется картой с помощью алгоритма MAC, на сессионном ключе SKac с использованием данных транзакции.
В процессе транзакции, сгенерированная картой криптограмма ARQC, отправляется в банк-эмитент, Банк сверят пришедшую ARQC с криптограммой которую, рассчитал самостоятельно. Для этой операции банком генерируется сессионный ключ, затем на основании пришедших данных транзакции, рассчитывается собственный ARQC. Если собственный (сгенерированный эмитентом) ARQC и ARQC карты сходятся – карта подлинная.
Далее эмитент по похожему алгоритму на основе динамических данных транзакции и данных ответа генерирует ARPC (Authorisation Response Cryptogram) и отсылает эту криптограмму назад карте. В тот момент, когда карта подтвердит пришедший ARPC, взаимная аутентификация карты и эмитента – выполнена.
Выше описан основной механизм аутентификации карты, который используется для онлайн-транзакций. Как уже было сказано, в онлайн-транзакции может присутствовать офлайн-аутентификация. Однако, чтобы не усложнять, рассмотрим детальное описание офлайн-аутентификации в контексте офлайн-транзакции.
Следующим методом безопасности являются расширенные данные в Field/DE 55 которые передаются в банк-эмитент. Field/DE 55 содержит результаты работы карты и терминала, оценки рисков и анализа транзакции.
Как показано на изображении выше, в Field/DE 55 содержится важная информация. Например, Terminal Verification Result, Сard Verification Result, которые в сумме с остальными данными помогают понять эмитенту и платежной системе как происходит транзакция и предоставляют множество дополнительных деталей для оценки рисков транзакции.
5.2 Офлайн EMV-транзакция
Особенность офлайн-транзакции заключается в том, что транзакция проводится картой и терминалом без обращения к банку и платежной системе. В процессе такой транзакции карта может одобрить транзакцию в пределах установленного лимита, а терминал, в свою очередь, отправляет информацию в банк позже по расписанию, либо когда появится связь с банком. Такие офлайн-транзакции предоставляют дополнительные преимущества как банку-эмитенту, так и владельцу карты. Например, владелец может расплатиться даже, если связи с банком нет. Либо же, если сумма небольшая – операция пройдет намного быстрее.
Как происходит аутентификация карты при офлайн-транзакции?
Ранее упоминалось, что онлайн- и офлайн-аутентификации используют разные технологии. Если онлайн использует криптографический алгоритм 3DES, то в случае с офлайн используется RSA c ассиметричными ключами. Зачем же использовать такие разные технологии? Все дело в том, что при онлайн-аутентификации, ключи хранят только карта и банк. В случае же офлайна – ключ нужно доверить терминалу. Учитывая наличие большого количества терминалов, существует вероятность, что секретный ключ доверенный терминалам недолго останется секретным.
Т.к. детальное описание офлайн-аутентификации карты достаточно большое, рассмотрим упрощенную модель.
Static Data Authentication
Во главе всего стоит платежная система (точнее центр сертификации), которая выпускает пару ключей: приватный ключ (красный) и публичный ключ (синий). Банк-эмитент также имеет свою пару ключей. Для своих ключей эмитент специальным образом генерирует сертификат (Issuer Public Key Certificate), который содержит в себе публичный ключ эмитента. Этот сертификат подписан (зашифрован) приватным ключом платежной системы. В процессе персонализации этот сертификат загружается на карту.
Когда платежный терминал устанавливают в торговую точку и подключают к системе, публичный ключ платежной системы через банк-эквайер загружается в терминал.
В процессе офлайн-транзакции терминал производит офлайн-аутентификацию карты. Сначала терминал вычитывает из карты Issuer Public Key Certificate, и с помощью публичного ключа платежной системы проверяет правильность подписи сертификата (т.е. расшифровывает). Если подпись верна – извлекается публичный ключ эмитента. Далее, с помощью публичного ключа эмитента, проверяется подпись критических данных карты, чем и подтверждается ее подлинность.
Описанный выше метод относится к статической аутентификации SDA (Static Data Authentication). В настоящее время чаще используются динамические аутентификации: DDA (Dynamic Data Authentication) и CDA (Combined Data Authentication), которые включают в себя SDA и дополнительно, по аналогии с онлайн, подписывают данные, которые курсируют между терминалом и картой. Данные подписываются приватным ключом карты, который загружается на карту в процессе персонализации. Подпись проверяется терминалом с помощью публичного ключа, восстановленного из соответствующего сертификата.
Технология SDA позволяет терминалу проверить, что данные на карте не модифицированы. Однако, она не позволяет полностью идентифицировать подлинность карты (существует возможность скопировать SDA-данные). В свою очередь, технологии DDA и CDA позволяют подтвердить подлинность карты, потому что карта является носителем уникального приватного ключа, чей сертификат (публичный ключ) подписан приватным ключом эмитента (сертификат эмитента (его публичный ключ) подписан приватным ключом платежной системы).
Диаграмма SDA
Диаграмма DDA/CDA
Технологии DDA и CDA уже содержат в себе SDA и в целом сходны. Оба алгоритма используют уникальный ключ карты и динамические данные. DDA-аутентификация является отдельной операцией и выполняется до основного цикла процесса транзакции. CDA выполняется в основном цикле транзакции, а в качестве подписываемых данных дополнительно используется криптограмма карты. В целом, сегодня, технология DDA более распространена, хотя CDA является более предпочтительной в использовании.
Помимо цифровой подписи, терминал и карта умеют оценивать риски транзакции. Для офлайн-транзакции карта может оперировать несколькими видами счетчиков транзакций и аккумуляторов офлайн-сумм, валютами и странами, офлайн-пином и его лимитами, а также дополнительными правилами. В процессе персонализации карты эмитент имеет возможность ограничить максимальное количество последовательных офлайн-транзакций и/ или максимальную сумму транзакции (нижними и верхними лимитами), таким образом определяя уровень риска.
Для каждой из реализаций приложения конкретной платежной системы существует свой набор правил, на основании которых карта может принимать решения проводить офлайн, онлайн или отклонять транзакцию. Список этих правил достаточно гибкий и может по-разному настраиваться эмитентом для каждого карточного продукта. В процессе решения могут участвовать результаты предыдущих транзакций, офлайн-счетчики, результаты проверки пина и т.д.
6. Проверка держателя карты CVM (Cardholder verification method)
Практически вся статья была посвящена транзакциям и процессу аутентификации карты, а пользователю карты уделялось мало внимания. С появлением технологии EMV проверка держателя карты не слишком видоизменились. В данный момент наиболее популярными методами проверки являются: проверка пин-кода (онлайнового и/или офлайнового) и подпись владельца карты. Так сложилось, что с приходом EMV не все платежные терминалы обладают одинаковыми возможностями проверки держателя карты (например, по причине возраста оборудования). В свою очередь, разные EMV приложения также могут быть ограничены в возможностях. Поэтому терминалу и карте приходится выбирать подходящий метод проверки держателя карты. Для этого используются так называемые CVM-списки. В CVM-списке определены методы проверки держателя карты и их приоритеты. И платежное приложение, и терминал имеют свои собственные списки. Итоговый список определяется путем объединения списков терминала и приложения. Из полученного итогового списка терминал выбирает общий CVM- метод с наибольшим приоритетом и осуществляет проверку держателя карты.
Пример такого списка представлен на картинке выше. Например, если карта вставлена в банкомат – будет запрошен онлайн-пин, если в терминал – офлайн-пин. В случае, если устройство не имеет пин-пада – будет запрошена проверка подписи. Во всех остальных случаях проверка держателя карты производиться не будет.
Заключение
В данной статье былы поверхностно рассмотрены платежное EMV-приложение и хранимые в нем данные, описаны основные отличия в процессах проведения транзакций по магнитным и EMV-картам. Также были рассмотрены процедуры проведения онлайн и офлайн-транзакций и механизмы обеспечения их безопасности. Конечно же, каждый аспект технологии EMV, имеет гораздо большую глубину и степень сложности. Однако, надеюсь, что статья дала общее понимание принципа работы платежных EMV-карт и проведения платежей с их помощью.
В заключении можно сказать, что платежная EMV-карта сложный и высокотехнологичный продукт, надежно защищающий доступ к вашему счету в банке. Микропроцессорную EMV-карту практически невозможно скопировать, а каждая транзакция защищена уникальной цифровой подписью. Любые действия, происходящие внутри карты, регламентируются строгим набором правил с указаниями как поступать в каждом конкретном случае. В процессе создания платежные EMV-приложения проходят обязательную многоуровневую сертификацию и получают разрешение от платежной системы на их использование. Программировать такие карты сложно и интересно. Впрочем, описание этого процесса может растянуться еще не на одну статью.
Спасибо за внимание!
P.S. Буду рад ответить на ваши вопросы в комментариях
Комментарии (111)
mtt
12.04.2016 16:07Как понять что происходит, когда в магазине спрашивают одновременно и подпись и пин-код?
AlexGre
12.04.2016 16:21Пин-код спрашивает терминал, подпись — кассир (следуя указаниями терминала или внутреннему порядку работы с терминалом). Возможно кассир не разобрался с терминалом, либо банк эквайер по своим соображениям заложил такую возможность.
mtt
12.04.2016 16:31Т.е. эквайер может требовать и то и другое? Просто с моей стороны выглядит так: я оставляю подпись, как подтверждение операции, а мне ещё подсовывают какой-то калькулятор с проводом и просят оставить там пин-код. Хотя очевидно, что операция может быть проведена без него.
tendium
12.04.2016 16:39Я сталкивался с еще более непонятной ситуацией — в РЖД несколько лет назад мою карту провели магнитной лентой И заставили ввести пин-код. Больше с таким нигде не сталкивался.
AlexGre
12.04.2016 16:52Это был fallback. Либо терминал вообще не поддерживал chip модуль, либо что-то не работало в терминале или в системе.
AlexGre
12.04.2016 16:51По спецификации терминал должен требовать что-то одно. Если коробочка вам не нравится — не платите в такой торговой точке, а если заплатили — обратитесь в банк. Особенно если операция проводится/проводилась fallback-ом по магнитной полосе.
shape
13.04.2016 15:34При сертификации терминального приложения есть сценарии при котором И ПИН, И подпись требуются одновременно. Зависип от предпочтений банка эмитента и рисков.
Semy
12.04.2016 16:16Почему бы не идентифицировать владельца банкоматом не пин-кодом, а отпечатком пальца например? Я попал в такую ситуацию — после снятия денег в банкомате вытащили кошелек и сняли все деньги с карты введя мой пин. Видимо где-то была скрытая камера (поскольку рядом со мной никого не было, что бы подсмотреть) или подложная клавиатура.
От копирования карты защитили, а от кражи пина — нет.
Angelina_Joulie
12.04.2016 16:27+4А что бы вы предпочли: потерять деньги или палец/глаз?
(отпечатки пальцев до сих пор не вводят, т.к. есть риск отделения последних от владельца)ITurchenko
12.04.2016 18:02+1Плюс в случае их компрометации (утечки отпечатков), сменить отпечатки будет несколько проблематично.
AlexGre
12.04.2016 16:30Разработки идут в этом направлении. MasterCard экспериментирует с распознаванием образов и со сканером отпечатков пальцев.
Angelina_Joulie
12.04.2016 16:37Я не сказала, что технологии нет.
Имелось ввиду, что вводить в эксплуатацию — опасно.
Более того, отпечаток пальцев не удобен. Те же проблемы что и с телефоном зимой — перчатки приходится снимать.
К тому же есть ряд профессий, как бармены, их кожа постоянно поддаётся воздействию разных кислот (попробуйте за 8 часов сделать 100 махито), итд. Но это вы и без меня знаете :)
tendium
12.04.2016 16:36Отличная статья!
Я вот только хотел спросить:
Представим ситуацию, когда я через интернет-банк поменял PIN-код на своей EMV-карте. Дальше я иду в банкомат или магазин, где принимают карты. Я ввожу там свой новый пин-код. Вопрос: в этой ситуации пин-код отправляется в банк или же делаются некие математические (криптографические) операции, чтобы не передавать непосредственно пин? Ну и побочный вопрос: офлайн пин устанавливается на основе того нового пина, что я ввел, или же присылается из банка?
Прошу прощения, если это освещено в статье. Возможно, эта информация от меня ускользнула или я что-то недопонял.
art_linux
12.04.2016 23:03Пойдет ли ваш пин-код, введенный с банкомата в банк, зависит от настройки банкомата и карты. Если требуется использовать Онлайн-PIN, то он отправится в банк и там уже конечно будут сравнивать его с новым установленным. Далее от банка придет Issuer Script, который вам поменяет пин на самой карте.
shape
13.04.2016 16:12Банкомат — это, по правилам, всегда онлайн терминал. Ваш банкоматный Online-PIN уходит прямиком к вашему банку, в зашифрованном виде естессно, и проверяется с вашим ПИНом измененным в интернет-банкинге. В онлайн терминале от банка может прийти ответ (Issuer script) — изменить Offline-PIN на карте. Поэтому, пока вы не сунулись в онлайн терминал, ваш Offline-PIN физически на карте останется прежним и будет валидным например в оффлайновых «торговых» терминалах.
AlexGre
12.04.2016 17:00Вот тут много информации про пин. Тут больше вопрос к поведению банкомата. Так как банкоматы всегда онлайн, скорее всего банкомат сначала сменит онлайн пин в системе, после чего банк-эмитент пришлет скриптовые команды нового оффлайн пина для карты, и банкомат сразу сменит офлайн пин на карточке. Хотя я точно не уверен.
mmMike
12.04.2016 17:51+1В общем правильно, чуть формулировка не точна :)
Хост авторизации сменит on-line PIN и отправит скрипт с установкой нового PIN.
Вот только жаль, что эту операцию не стандартизировали и смена PIN в общем случае доступна только в «своей» инфраструктуре.
Нет стандарта (в разных реализациях ПО процессинга) на данный тип «транзакции» и способ передачи нового PIN (PIN блок с новым PIN). У каждой реализации свои особенности и… межхост с большой долей вероятности запрос смены PIN не пройдет.
Ну и для подобных служебных операций в EMV зарезервирован фактически (ну по крайней мере его так используют) режим, когда терминал карте на первый GenerateAC говорит AAC и идет в on-line что бы получить скрипт.
lumag
13.04.2016 02:00Если первый Generate AC вернет AAC терминал может завершить транзакцию без выхода в online и получения скриптов.
Вероятно, имелся в виду запрос ARQC в первом Generate AC, выход онлайн с проверкой ARQC и получением ARPC и скриптов.mmMike
13.04.2016 06:25+1Нет именно AAC карте(!) передает терминал в первой GenerateAC. Понятно что карта возвращает то же AAC и криптограмму. И с этой криптограммой терминал идет на авторизацию.
Авторизацию опять же служебной операции специально «раскрашенную» как служебный запрос.
Хочу обратить внимание, что по EMV не специфицированно ограничений и скрип выполняется вне зависимости от того AAC, или ARQC терминал выдал после первой GenerateAC.
Используется для служебных функций (не платежных!) в служебном терминале и/или ATM.
Например — запрос баланса.
Некоторые вендоры ПО, запрос баланса по EMV карте делают через обычный ARQC с '00..0' полями сумм, а некоторые через AAC. Видел и тот и другой вариант. И то и другое работает (нет стандарта на служебные операции).
Лично мне кажется, из очень общих соображений, что через AAC правильнее. Ну что бы точно было видно «ЭТО НЕ платежная транзакция»
Аналогично и смена PIN то же служебная операция.
Конечно смену PIN можно запрашивать и совместно с платежом, но концептуально не правильно мешать…
AlexGre
13.04.2016 10:18Все верно, для любой скриптовой команды изменяющей данные приложения потребуется состояние ONLINE или SCRIPT (выход в онлайн с любым результатом). Через AAC в первом GenerateAC просто получается быстрее.
Нет смысла выполнять второй GenerateAC, потому что не нужно оценивать риски (это не платежная операция, как было сказано выше) и не нужно аутентифицировать картой банк через ARPC (потому что данные придут, как минимум макированые на ключе эмитента).
vlivyur
14.04.2016 17:24Т.е. в чужом банкомате я смогу снять по новому пину, а если потом попробовать ввести новый пин в офлайн-терминале, то могу обломаться?
zikher
14.04.2016 18:07+1после первого же снятия по онлайн-пину (если это операция по чипу) на карту придёт issuer script, который обновит данные, в том числе и оффлайн-пин.
mmMike
15.04.2016 05:56>Хост авторизации сменит on-line PIN и отправит скрипт с установкой нового PIN.
Конечно, поскольку операция установки нового on-line PIN на хосте и замена PIN приложения карты, командой скрипта с хоста не транзакционна, то есть вероятность того, что on-line PIN сменился, а off-line нет.
(термин «транзакционна» в данном случае — это термин… ну как в СУБД. т.е. завершена полностью или откачена операция).
За все реализации и вендоров ПО хоста говорить не буду, но варианты компенсации этой ситуации прозрачно для клиента можете сами прикинуть.
Кто то просто игнорирует с сакраментальным «обращайтесь в офис банка».vlivyur
15.04.2016 09:26Я про этот кусок:
смена PIN в общем случае доступна только в «своей» инфраструктуре
т.е. если я буду снимать деньги в чужом банкомате, то существует вероятность что мне не придёт новый пин.mmMike
15.04.2016 09:32+1Функция (кнопка/пункт меню в интерфейсе банкомата) смены PIN доступна обычно только для «своего» банкомата (банкомат знает про эмитента карты и знает что ему разрешена эта операция).
Если Вы говорите про установку PIN через IVR (телефон) или интернет банк… то новый off-line PIN придет в рамках первой же успешной on-line авторизации по чипу в ЛЮБОМ терминале любого типа.
Ну должен по крайней мере. (были прецеденты, когда промежуточные хосты «резали» скрипт эмитента)
amarao
12.04.2016 17:11Я отказываюсь считать такую схему безопасной. До тех пор, пока кто-то может списать деньги с моего счёта без моего ясного «да, я разрешаю списать 100 денег пупкину А А» — это не безопасность, а филькина грамота.
Paypal уделывает по этому вопросу все банковские сервисы вместе взятые. Целиком. Просто потому, что требует нажать «да, заплатить» со стороны пользователя.
xBrowser
12.04.2016 18:33Этого парня все устраивает в безопасности вашей карточкиAlexGre
12.04.2016 21:50+1Этот парень, похоже, просто вез терминал в руках и неожиданно стал «звездой» интернета. Можно еще с натяжкой поверить что он считывал mifare проездные платежным терминалом. Далеко не все бесконтактные карты можно просто так считать, и даже если считали — делать с этими данными практически нечего. По поводу проведения таким способом транзакций приведу цитату из указанного вами источника:
«Сделать терминал, который будет считывать данные карты «из кармана» клиента, теоретически возможно. Но этот терминал должен иметь «на борту» криптографические ключи, полученные у банка-эквайера и платежной системы. Ключи выдаются по договору с юридическим лицом, то есть с банком-эквайером. Таким образом, мошенничество будет легко обнаружить и расследовать»xBrowser
12.04.2016 23:14Расследовать все легко, если вы следователь. Я сам сталкивался со случаями, когда расследование было завершено на стадии подачи заявления, а ход делу не давали. Взять любые мошеннические действия с утекающими через онлайн банкинги через вирусы/малвари/скрипты или «ваша карта заблокирована». Как правило всегда ответ от банка «это с вашего компьютера/мобильника/планшета действия а как эквивалент ваша воля, мы не видим тут противоправных действий и деньги не вернем». Хотя контрагенты это реальные физически/юридические лица, а не биткоин кошельки. Так же и тут, вы просто не заметите пропажи 500р.
AlexGre
13.04.2016 11:04Со скомпрометированным юрлицом будет другой разговор. Хватит нескольких запросов ведущих в одну и ту же платежную точку.
Да и прав mmMike — как то это мелко при большой сложности. Оформить юрлицо, пройти 10 кругов ада получения терминала, долго искать карты у которых есть лимиты на операции без пина, что-бы потом красть по 1000 рублей. Затраты не отобьются.
СМС оповещения помогают заметить все списания по счету.bonv
13.04.2016 13:14> пройти 10 кругов ада получения терминала
А в чем сложность?
Года 4 назад получал терминал в ВТБ24: подписываешь договор и через несколько дней привозят.
mmMike
13.04.2016 06:37В принципе можно организовать в режиме on-line платеж путем создания канала между картой в кармане жертвы и сотовым телефоном, эмулирующим работу бесконтактной карты (HCE приложение).
Всего то нужно два телефона с NFC, хост с белым IP для проброса трафика в on-line между двумя телефонами и очень четкая синхронизация двух злоумышленников.
И… они могут получить бесплатный завтрак в макдональс! (а на большее без ПИН лимита не хватит) или от 5 лет… Если кассир заподозрит неладное.
Но как то это фриково… Мелочь по карманам в том же общественном транспорте тырить — навар больше будет.
А уж просто стырить карту и расплатится ей в пределах без PIN лимита — еще безопаснее.
Не верю я в таких квалифицированных в области программизма мелких карманников.
Vicrius
12.04.2016 17:11+1Спасибо за статью.
Хотелось бы еще статей на тему банкинга и проведения транзакций.
state13
12.04.2016 18:49Мне еще вот эта статья понравилась про способы проверки пин-кода. Там в частности написано, что «зашифрованный офлайн-ПИН – самый современный и защищенный способ верификации».
AlexGre
12.04.2016 22:06Стоит уточнить что «защищенный способ верификации держателя карты», но не аутентификации карты. По большому счету, офлайн-пин больше предназначен для офлайн-транзакций, чем общий способ верификации. В итоге не корректно говорить о том, что какой-то из способов проверки пинов более защищенный и современный. У них разные задачи.
mmMike
15.04.2016 06:06офлайн-пин больше предназначен для офлайн-транзакций
Очень много инфраструктур POS, где POS терминалы вообще без on-line PIN (Франция… Германия...)
И используется off-line PIN с on-line авторизацией.
Особенно там, где традиционно работали с чиповыми картами (местные не EMV платежные системы а чиповых картах).
Накладные расходы на загрузку TMK/TPK ключей в криптомодуль клавиатуры — это не мало…
Mingun
15.04.2016 19:18Накладные расходы на загрузку TMK/TPK ключей в криптомодуль клавиатуры — это не мало…
Ну вообще говоря, мастер-ключи в клавиатуры банкоматов (про ПОСы не скажу) можно загрузить при помощи ассимметричной криптографии, и уже довольно давно (если не ошибаюсь, то больше 5 лет). Так что особых накладных расходов быть не должно.
mmMike
15.04.2016 19:45Я говорил про POS терминалы.
В масштабах большей инфраструктуры, 2-20 Euro на загрузку POS терминала — это не мало
(по разным оценкам и по разным технологиями и разных странах… в сумму входят и зарплаты сотрудникам… чел./часы и пр.)
А накладные расходы на загрузку ключей в криптомодуль клавиатуры банкомата это малая часть расходов по установке и настройке банкоматов.
Разница, на общем фоне затрат на установку железки, между классической загрузкой компонент симметричных ключей с бумажек и более продвинутыми вариантами не столь принципиальна по стоимости.
Да и банкомат по определению (требования ПС) с on-line PIN. вариантов нет.
Ну и сети банкоматов обычно на порядок меньше чем POS (в общем случае)
Tuzik
15.04.2016 23:55>> офлайн-пин больше предназначен для офлайн-транзакций
оффлайн-пин прекрасно подходит и используется для онлайн транзакций, так как проводит верификацию пина моментально, ускоряя тем самым общее время проведения транзакции в целом.mmMike
16.04.2016 14:01не по этой причине все же…
экономия 10-100ms на проверку PIN блока в HSM, это не основополагающая причина.Tuzik
16.04.2016 16:39отправка и ожидание онлайн верификации пина на хосте вместо мгновенной проверки в чипе — это как раз одна из весомых причин.
mmMike
16.04.2016 16:50Мы же об одном говорим и подразумеваем?
А именно авторизацю транзакции на хосте эмитента.
Или вы имеете в вижу что то другое. Я не понял
отправка и ожидание онлайн верификации пина на хосте вместо мгновенной проверки в чипе
В контексте авторизационного запроса эмитенту.
Поясните пожалуйстаTuzik
19.04.2016 10:09Нет, мы говорим об онлайн и оффлайн проверке PIN-кода.
При проведении оффлайн проверки, общая скорость обслуживания клиента возрастает, так как оффлайн проверка проходит гораздо быстрее нежели онлайн.mmMike
19.04.2016 10:43+1Мне было бы очень интересно услышать Ваше представление об порядке выполнении платежной транзакции в режиме on-line в POS терминале для EMV карты, включая запросы к хосту и действия хоста на запросы.
Порядок выполнения по шагам + оценка времени каждого шага.
В двух вариантах: c off-line PIN и on-line PIN.
Ну очень интересно, где по вашему мнению возникает «гораздо быстрее нежели онлайн».
Если уж высказали так уверено свое мнение, то его нужно обосновывать…
mmMike
19.04.2016 10:59Еще раз уточню. Не в общем абстрактном случае, а именно в случае on-line авторизации
При выполнении авторизации транзакции на хосте эмитента, не важно с точки зрения скорости обслуживания клиента, какой вариант проверки PIN используется.
JediPhilosopher
12.04.2016 20:17На самом деле вся эта система работает ровно до тех пор пока банковское ПО работает в соответствии с гайдлайнами и стандартами платежных систем, а органы отвечающие за сертификацию этого дела — знают что они делают и делают это ответственно.
Волею судеб оказался вовлеченным в процесс платежей, причем не в России, а внезапно в Нигерии (да-да, шутка про нигерийские письма), так что немного расскажу про свой опыт и творящийся там бедлам. Очень хочется услышать комментарии тех, кто занимается этим в РФ, надеюсь у нас все гораздо лучше с безопасностью.
История 1. Захотели они сделать POS-терминалы из смартфона. Окей, закупаются кардридеры (сертифицированные EMV, стоят они дешево, в итоге смарт + ридер выходит дешевле классического POS-терминала), они подключаются к смартфону (по блютусу или через аудиоразъем), пишется софт, все хорошо. Но тут же всплывают нюансы. Например чтобы сделать подешевле — закупаются ридеры без pin-pad. По задумке создателей они могут использоваться только с верификацией подписью на экране смартфона. Я такое даже в РФ один раз в такси использовал. Но есть нюанс — в Нигерии все банки признают только PIN авторизацию. Что же делать? Ну ясен пень, вводим пин просто на экране смартфона. Пофиг что это запрещено правилами EMV (нигерийцам правда тоже на них слегка пофиг, у них распространена своя платежная система Verve), пофиг что никакой секьюрности пина в таком случае нет.
В итоге все работает, да. Карта думает что транзакция подтверждена подписью (ей ридер сообщает это в списке поддерживаемых CVM), нигерийский процессинговый центр думает что подтверждено пином.
То есть обмануть карту вполне можно. При этом софт получил сертификацию их центрального банка.
История 2. Запросы в ПЦ шлются по незашифрованному каналу. Эти умники до сих пор не осилили запустить свой iso8583 — канал поверх SSL. И это вообще пц, так как получается что открытым текстом шлются почти все платежные данные. Кроме PIN — он шифруется отдельным ключом. В общем взломав вайфай в магазине и просмотрев траффик с терминала можно получить достаточно данных для совершения платежей.
Причем NIBSS — это прям серьезная центральная государственная организация, которая пользуясь неограниченным административным ресурсом за несколько лет до этого выдавила с рынка обработки платежей всех конкурентов, а теперь вот такое учиняет. Что-то мне это напоминает…
История 3.
Как раз насчет processing code. Нормально он подделывается =) Во всяком случае опять же если те, кто отвечает за софт на стороне банка, кладут на него болт. В какой-то момент приходилось составлять данные для платежа вручную, имея лишь часть необходимой информации. Так как ридер выдавал большую часть данных в зашифрованном виде, но ПЦ не поддерживал этот вид шифрования, а расшифровать перед отправкой их было нельзя (для этого нужен ключ девайса, который производитель не дает кому попало, а только важным банкам и организациям, но не разработчикам). В общем почти все нужные данные и так получилось выдрать, но вот как раз этот код был в итоге захардкожен и все работало нормально.
Короче не храните деньги в нигерийских банках, хехе.shape
13.04.2016 16:24+1расслабьтесь, такой бедлам везде, Нигерия ли, Европа. Потому что все для бизнеса, все для захвата очередного сегмента на рынке. Мало где прислушиваются к технарям предпочетая ловить грабли в продакшене. Страховка покроет.
lumag
13.04.2016 02:01+1Самое забавное, применительно к картам, что даже в 2015 году оставались банки, которые выдавали SDA-only карты (их можно частично склонировать).
Tuzik
13.04.2016 13:10Скорей всего это банки, которые закупили когда-то добротную партию SDA-карт и теперь пытаются раздать ее клиентам под любым предлогом. Такое к сожалению встречается повсеместно.
mmMike
15.04.2016 06:09И что такого? Зачем дебетовым карточным продуктам возможность обслуживаться в On-line?
Если это даже правилами запрещено для таких продуктов.
Рекомендованные профили, в которых нет DDA есть у всех платежных систем.mmMike
15.04.2016 06:28>Зачем дебетовым карточным продуктам возможность обслуживаться в On-line?
Зачем дебетовым карточным продуктам возможность обслуживаться в off-line?
опечатка…
Ну и вдогонку. на чисто On-line картах зачастую даже SDA не делают. Вполне нормальный вариант.
lumag
15.04.2016 15:10Вполне обычная Visa Standard. Персонализирована с возможностью off-line операций. Как не сложно догадаться, клонируется на ура.
mmMike
15.04.2016 17:12Visa Standart c SDA и не нулевыми off-line лимитами???!!!
Технически, создать такой профиль персонализации конечно можно.
Но… как то не верю в таких идиотов в банках. Не пуганных идиотов…
Названием банка не поделитесь? страна должна знать своих героев.lumag
15.04.2016 21:46Сбер. Лимиты X и Y в CVM нулевые. Остальные оффлайновые лимиты для offline-only клона не принципиальны, если я правильно понимаю.
mmMike
16.04.2016 13:49Т.е. Вы хотите сказать, что у Сбера выдаются карты без DDA(CDA) и off-line PIN в CVM??!!! Да еще с нулевыми XY
Если это так, то у меня нет слов! Такие «дыры» в безопасности дискредитирую саму технологию. Хотя она не причем.
Явно у Сбера сознательный выбор, подставляющий невинных клиентов.
Если кто такую карту втихушку продублирует — это даже не магнитку скопировать. Это хуже!
Операции без PIN по магнитке хотя бы весьма ограничены без знания PIN. А тут клон, который «выглядит» гораздо защищенней чем магнитка, а по сути…
И что бы выпустить клон достаточно сосем не много
Любого низкуровнего лога (DGI данных персонализации, лога транзакции на уровне APDU или уже разобранных данных и т.д.) или 2 сек доступа к карте (засунуть в ридер)
Вы точно уверенны, что такие карты есть?
Постараюсь найти такую карту по знакомым с картами Сбер, что бы иметь доказательство…
Все же ссылаться на «слышал» для таких серьезных обвинений это мало.
Поскольку к Сберу отношения не имею, то смотрел (ради любопытства когда то) только свою личную Сберовскую карту. Был и есть честный MChip select c CDA…lumag
16.04.2016 14:10Off-line PIN в CVM не важен. клон спокойно вернет 90 00 на любой пин.
Завтра скину обезличенный дамп. Может быть, я чего-то не понимаю. Я тоже очень удивился, когда Сбер мне такую карточку выдал. Такое впечатление, что они почти не меняли шаблон с 2003 года, когда мне предыдущую Visa Standard выдавали.mmMike
16.04.2016 14:26CVM входит в подпись. Хотя бы и SDA…
Т.е. если в исходной карте не предусмотрен off-line PIN в CVM, то и в дубле его не будет.
Ну и терминал его никогда у карты не спросит. и остается только on-line PIN.
даже подпись клиента на чеке в CVM не так плохо как off-line PIN в CVM на клоне карты.
А вот если есть…
Терминал с off-line транзакцией и без PIN — ну это… например оплата туалета жд. вокзале (в Осло кажется с таким курьезом столкнулся) или… платная дорога.
А вот off-line операцию с off-line PIN вполне могу себе представить как разрешенную в каком ни будь супермаркете на сумму до 50Euro.
И мне было бы обидно кормит на 50Euro «несчастного беженца» которому местная диспора продала клон моей карты, сделанный по украденным в банке данным.
И это не магнитка… с EMV транзакцией замучишься доказывать что «не я там был».lumag
16.04.2016 14:32Доказывается-то на ура (в идеале): криптограмма TC не сойдется. По идее, эквайер может сам послать chargeback, после проверки криптограмм в presentment.
mmMike
16.04.2016 15:05эквайрер… chargeback? после проверки криптограммы? (крипторамму может только эмитент проверить)
И не совсем понял… зачем это эквайреру. Товар отдан. Транзакция по EMV карте по всем правилам ПС. Ничего у эквайрера не нарушено.
Не магнитка. никаких «смещений отвественности». Эмитент обязан ему возместить…
А дальше: TC транзакции проверяет (а чаще всего никто не проверяет) эмитент. И он что? «автоматически» компенсирует потери клиенту? слабо верится.
Все проблемы по подаче заявления и т.п. ложатся на клиента. Это я имею в виду «замучаешься».
Именно «замучаешься», а не «невозможно»
В сущности вопрос, лично у меня остается открытым, как такие диспуты решаются в ПС. По идее, это же эмитент выпустил карту с таким профилем и дырой в безопасности.AlexGre
18.04.2016 11:55После проверки поддельной криптограммы эмитентом карта сразу должна улететь в стоп-листы. Ответственность по SDA, вроде как, делят эмитент и эквайер. Один такую карту выпустил, второй провел офлайн операцию по такой карте.
mmMike
18.04.2016 12:42После проверки поддельной криптограммы эмитентом карта сразу должна улететь в стоп-листы.
Хм… по секрету скажу (не тыкая пальцем в конкретных...), что TC off-line транзакции обычно мало кто проверяет.
второй провел офлайн операцию по такой карте.
Не так все просто.
Карта с SDA… или карта DDA/CDA
В TVR нет ни одного бита позволяющего различить эти два варианта.
Terminal Action Code — по это все что обычно конфигурируется (можно сконфигурировать) в стандартном EMV терминале (*).
(*) — остальные параметры: Лимиты, публичные ключи и пр. к этой теме отношения не имеют.
И только этим эквайрер может повлиять на принятие решение терминалом.
Все остальное — не стандарт и частные/опциональные кастомизации ПО терминала.
Все же в EMV все очень четко прописано.
Так что эквайрер тогда становится (равная ответственность) невинной жертвой, действующей по правилам!
А насчет равной ответственности… Ссылку на правила Visa/MC, если можно.
И если знаете вендора ПО EMV терминала, где можно указать что SDA только on-line, то пожалуйста поделитесь.AlexGre
18.04.2016 13:34Честно говоря, про ответственность не могу вспомнить где читал. Возможно я и ошибаюсь.
lumag
16.04.2016 14:22Got tag 8e len 10 'Cardholder Verification Method (CVM) List': X: 0 Y: 0 41 03: 'Plaintext PIN verification performed by ICC' 'If terminal supports the CVM' and 'continue' if this CVM is unsuccessful 42 03: 'Enciphered PIN verified online' 'If terminal supports the CVM' and 'continue' if this CVM is unsuccessful 5e 03: 'Signature (paper)' 'If terminal supports the CVM' and 'continue' if this CVM is unsuccessful 1f 00: 'No CVM required' 'Always' and 'fail' if this CVM is unsuccessful 00: 00 00 00 00 00 00 00 00 41 03 42 03 5e 03 1f 00 |........A.B.^...mmMike
16.04.2016 14:34Да… отсутствие «Enciphered PIN verification performed by ICC» практически кричит о том что это карта без RSA
Спасибо! буду знать точно теперь. Сбербанк конечно не пинает только ленивый, но это уже перебор у них.
вот такой CVM, как мне кажется только и может быть допустим для карты без DDA/CDA.
00000000 00000000 0203 1F00
Чисто on-line приложения как прямая замена мегнитки.lumag
17.04.2016 17:28Я бы только ставил… 4203 1f00.
mmMike
17.04.2016 18:53В данном случае, разницы практически никакой (всего одно «действующее» правило связанное с фактической cardholder аутентификацией).
и если CVM по правилу "_203" будет failed, то бит 40 влияет только на то какой будет CVM бит в TVR,
и какая разница, если все одно транзакция по этой карте без on-line PIN запрещена?
может быть даже лучше, если терминал сразу откажет (по маске в TVR) чем пойдет на хост за отказом.
Впрочем, если хочется фиксировать все попытки провести операцию… то почему бы и нет.
в общем не однозначно. и то и то имеет право на жизнь.
главное для всех комбинаций в CVM тщательно расписать все сценарии и настойки хоста, что бы случайно не осталось «дырок» и нежелательных вариантов.
Хотя для такой карты сценарий хоста по CVM прост: нет успешной проверки PIN блока — нет транзакции.
mmMike
16.04.2016 13:57Приложение карты без DDA|CDA не должна поддерживать off-line PIN вообще. Иначе она легко клонируется.
Банк, выпускающий такие карты сознательно подставляет клиентов. Клиент даже доказать ничего не сможет если что.AlexGre
18.04.2016 11:38Или, перефразируя, приложение с off-line PIN должно быть с DDA/CDA аутентификацией. SDA как единственный метод офлайн аутентификации давно устарел (в отдельных регионах запрещенный к выпуску) и риски по SDA офлайн операциям, насколько я знаю, лежат на эквайервах и эмитентах.
Tuzik
13.04.2016 13:37+1Спасибо коллеге по цеху за добротную статью :)
Хочу только добавить, что не смотря на все спецификации и стандарты, случаются иногда на практике различные нюансы, когда например коряво написанный софт терминала ломает схему использования чип-карт. На практике были случаи, когда сторонний чиповый терминал обслуживал чиповую карту с прописанным в CVM-листе обязательным запросом пин-кода просто по подписи.mmMike
15.04.2016 06:23Судя по нашумевшей в узких кругах ситуации с перехватом команды проверки PIN (дополнительный чип на карте).
Ошибки бывают и на ПО хоста.
Интересно, кому в таких случаях идет претензия.
Банку эмитенту который разрешил операцию или вендору ПО через суд…
Как то даже не задумывался, содержит ли лицензия на банковский софт типичную фразу насчет отказа от ответственности при использовании ПО.lumag
15.04.2016 15:16Претензия явно эмитенту (клиент же заключал договор только с эмитентом), а он уже по внутренним договорам (или в суде) будет разбираться с эквайером и ПС.
Но сдается мне, что, если не удастся доказать факт обхода команды VERIFY, виноватым окажется клиент.mmMike
15.04.2016 17:03Ситуация когда «карта» а точнее прокси чип, имплантированный в украденную карту, выдал SW:9000 (ok) на проверку off-line PIN, а хост эмитента почему то проигнорировал значение в CVR и подтвердил транзакцию, наверное это проблема разработчиков ПО эмитентского хоста… Ну и банка эмитента заодно.
При этом эквайрер все сделал честно!
n_demitsuri
13.04.2016 14:35Возможно мне кто-нибудь сможет объяснить мою ситуацию.
Мне выдали карту с возможностью бесконтактной оплаты, но конкретно бесконтактная оплата не работала (терминал или телефон с nfc никак не реагировали на поднесение карты), однако оплата по чипу работала. Я написал заявление в банке, и через несколько дней бесконтактная оплата заработала сама собой (то есть те несколько дней работал все так же только чип, а теперь можно без проблем оплачивать пейпассом).
Выглядело для меня все так, как будто банк удаленно включил на карте возможность бесконтактной оплаты, которая ранее была выключена. Девочка из банка не в курсе всего этого, конечно.
Возможно ли такое управление включением/выключением бесконтактных платежей удаленно банком?AlexGre
13.04.2016 14:39Да такое возможно. Во многих дуальных картах можно включать/выключать бесконтактную часть приложения настройками карты. При очередной операции в терминале или банкомате, банк мог прислать обновление настроек приложения в скриптовой команде, и таким образом включить бесконтактную часть.
n_demitsuri
13.04.2016 14:46Значит, такое возможно, здорово. Тогда странно, что такое не реализовали как дополнительную функцию (параноики с радостью бы отключили бесконтактный интерфейс).
Раз вы все знаете про карты, я вас еще спрошу. При замене карты мне выдали карту с теме же реквизитами. Я знаю, что сейчас много где выдают карты с теми же номером и сроком действия. Но тут и CVV2-код тоже полностью совпадал с предыдущей картой.
Раньше я думал, что эти 3 цифры (CVV2) генерируются случайно, что-то типа пин-кода. Это мне так повезло или там все по-другому устроено?AlexGre
13.04.2016 15:12Насчет CVV2 я не скажу. По аналогии с первым СVV (который на магнитной карте) скорее всего в расчете участвуют номер карты и срок действия. На основании этих данных и секретного ключа, по 3DES рассчитывается подпись. Далее нехитрыми манипуляциями получают 3х-значный код. Алгоритмы и данные для разных платежных систем разные и к сожалению я их точно не знаю (и насколько я помню они под NDA).
Tuzik
13.04.2016 23:57Код CVV2 (Card Verification Value) высчитывается на основе данных карты, которые статичны. Рассчитывается так же как и CVV, но с немного иным набором входных параметров. Так что если параметры карты у вас не изменились (номер, срок действия), то CVV2 код будет точно такой же.
lumag
15.04.2016 15:17PSN в рассчете CVV2 не принимает участия?
Tuzik
15.04.2016 15:27PIN не принимает участие с расчете CVV2, иначе после любой процедуры смены PIN-кода, у вас менялся бы и CVV2.
К тому же CVV — это Card Verification Value, т.е. защитный код, верифицирующий корректность статических данных самой карты, не зависимо от значения PIN-кода на хосте.
PIN-код участвует в формировании значения PVV — PIN Verification Value, но это уже другая история :)
Kastrulya0001
Все это разбивается о продавщицу, которая не смотрит на документы того, кто платит.
AlexGre
Об продавщицу разбивается только проверка подписи, и то если она требуется. А все остальное — остается в силе.
Kastrulya0001
В Европе у меня везде ID спрашивали, приходилось таскать права с собой. Без ID что-то купить невозможно.
AlexGre
А карта у вас была не европейская? Скорее всего повышенное внимание к international currency / international country транзакциям.
Kastrulya0001
Я видел как местного завернули.
Ryotsuke
Где в Европе? Я сколько ни катаюсь, паспорт показываю ровно два раза: на въезде и на выезде из Европы. А так даже в самолет просто по посадочному пускают часто, на документы не смотрят. Везде и всё оплачиваю карточкой.
pupsegadm
Британия — тотальный EMV.
США — тотальная магнитка.
Автору — коллеге привет!
Elph
Из за США как раз не не переходят на чип, а давно уже всем пора.
pupsegadm
Там другая вселенная. Они перепрыгнут EMV и перейдут сразу на какую-нибудь биометрическую аутентификацию.
Переоснастить всю страну устройствами с поддержкой EMV — не реально…
Vicrius
Аналогично. Только в Мадриде, в медиамаркт, за покупку под 300 евро спросили паспорт. А так паспорт показывал на въезде и выезде из Европы.
Kastrulya0001
У вас пин надо вводить? У меня нет, наверно поэтому нужен ID. ID это не обязательно паспорт, подойдут и российские права. А в Европе, например в Швеции.
AlexGre
У вас просят подписать чек? Если для вашей карты не нужно вводить пин, скорее всего в приоритете CVM стоит проверка подписи. Для этого и требуют ID, на них обычно есть ваша подпись.
Kastrulya0001
Нет, там фамилия и имя написаны и фото есть. Речь не об этом, а о том, что в России можно взять карту чью-то с пином или без и ходить спокойно ей расплачиваться. Спрашивается, какая разница, что там в чипе?
Morthan
Странно, у меня не получалось дать другому свою карту, чтобы он ею расплачивался. Несмотря на то, что там ни фамилии нет, ни фотографии. Всегда пин просит. Может, есть разница, что там в чипе?
Mingun
В статье же написали: и чип и терминал имеют приоритезированный список методов аутентификации. Два списка объединяются по «И» и наиболее приоритетный метод используется для проведения транзакции.
Morthan
Ну, как бы, да. Меня смутила фраза: «в России можно взять карту чью-то с пином или без и ходить спокойно ей расплачиваться». Непонятно, чем Россия от прочих стран отличается и почему с моей картой такие фокусы не проходят.
Mingun
«Можно» не означает, что будет работать всегда. Принципиальная возможность есть. Я, во всяком случае, прочитал этот комментарий именно так.
Думаю, ничем, просто у автора комментария нет карт жителей других стран и он не может говорить за всех. Вполне здравая позиция.
Вероятно, в вашей карте в приоритете другие методы. Или вы в других местах расплачиваетесь.
Приоритет методов от карточной программы может зависеть. Может, где-то его даже самому менять можно, не знаю. Во всяком случае, технических ограничений на это нет.
Morthan
Я этот комментарий прочитал по-другому, если отталкиваться от начала обсуждения. Там человек говорит, что все эти чипы бессмысленны, если продавщица документы не смотрит. Потом говорит, что у него на карте пин вводить не надо. Потом обобщает свой опыт на все российские карты, неважно, с пином или без и спрашивает, какая разница, что там в чипе?
Но разница-то есть, о чём я и попытался сказать в комментарии. Если в чипе стоит в приоритете «всегда спрашивать пин», то он и будет всегда спрашиваться. Особенно в моём случае, когда на карте нет ни фамилии, ни фотографии.
У меня как-то спросили в магазине документы, я в ответ спросил, на какую фамилию? ;-) И показал, что на карточке фамилии нету, с чем сверяться будете? Они посмеялись и сказали, что хозяин потребовал, чтобы продавцы всегда документы спрашивали. Против инструкции не попрёшь.
AlexGre
Чип позволяет провести аутентификацию карты, то есть проверить ее подлинность, и оценить риски транзакции. Вы говорите о верификации пользователя карты.
mtxd
Не затруднит раскрыть тему ввода пина\подписи? В моём случае имеется карта аж с 3 возможностями оплаты: полоса, чип и paypass. Иногда, при оплате чипом и успешном вводе кода, продавцы требую расписаться на чеке. Что-то мне подсказывает, что это, во-первых, не безопасно, а во-вторых не понятно, имеют ли они на это право? Кто регулирует процедуру и как она должна выглядить?
AlexGre
В пункте 6. Проверка держателя карты CVM есть небольшое описание. Также вот хорошая статья. Пин имеет больший приоритет над подписью и после его ввода проверять подпись не нужно. У вас все продавцы требуют пин и подпись в разных торговых точках?
mtxd
Сталкивался несколько раз, закономерности какой-то нет. Все разы были в точках, в которых я первый и, вероятно, последний раз.
Я читал этот пункт, и представляю себе так: если введён и принят пин, то ни о какой подписи речи не идёт. Если терминал по какой-то причине не поддерживает ввод пина, то я его и не должен вводить, расписавшись лишь на чеке после успешной транзакции.
Отсюда опять вопрос — имеют ли право требовать (именно требовать, а не «не могли бы ещё и тут подписать»), и что об этом говорит сам мастеркард, например, или банк-эквайер? При требовании слышал такую версию, что якобы «нам хозин велит» требовать подпись. Должны же быть какие-то общие правила?
AlexGre
shape уточняет что такой порядок возможен.