- PVSM.RU - https://www.pvsm.ru -
Платежные карты прочно вошли в нашу жизнь. Еще совсем недавно повсеместно использовались только карты с магнитной полосой. Сегодня же никого не удивишь картой с чипом. Всем известно, что чиповая, микропроцессорная или, созвучнее, платежная EMV-карта – современный и надежный способ доступа к расчетному счету. Она безопаснее карты с магнитной полосой и ее практически невозможно подделать. Однако детали реализации «внутренностей» EMV-карты мало известны. Всем кому интересно как работает EMV-карта, почему технология EMV обеспечивает безопасность платежей и насколько стоит всему этому доверять – добро пожаловать под кат.
О каких картах пойдет речь?
Сегодня международные платежные системы (МПС) используют стандарт EMV для проведения операций по банковским картам. Одними из наиболее известных МПС, стоящих у истоков разработки этой технологии, являются компании «VISA Inc» и «MasterCard Worldwide». Поскольку в основе микропроцессорных карт этих компаний лежит общая технология EMV, мы будем рассматривать обобщенную EMV-карту, не вдаваясь в детали реализации той или иной компании.
Стоит сразу отметить, что спецификация EMV достаточно большая, поэтому статья не претендует на полное описание стандарта. Многие вещи будут представлены в упрощенной форме без использования специфической терминологии. Так как стандарт является открытым, при желании всегда можно ознакомиться и разобраться в деталях на сайте EMVCo [1].
Описывая платежные транзакции и функциональность EMV-карты, мы будем ссылаться на других участников системы. Помимо самой платежной системы в процессе проведения транзакции участвуют:
Рассматривая подробнее платежную EMV-карту, мы будем концентрировать внимание не только на возможностях микропроцессора. Технология EMV подвергла изменениям как сами карты, так и сообщения, которыми обмениваются участники системы; расширила функциональность приложений для терминалов, банков-эквайров и эмитентов.
Одна из основных задач банка, выпустившего карту – это аутентификация [2] карты в ходе ее использования. В данном случае под аутентификацией понимается процесс доказательства того, что данная карта (или приложение на карте) выпущена банком, авторизированным на это соответствующей платежной системой.
Как происходит процесс аутентификации карты?
В общем случае, прочитав данные карты, терминал отправляет их через банк-эквайер и платежную систему банку-эмитенту. Эмитент на основании данных карты определяет ее подлинность.
В этом процессе заключается одна из основных проблем безопасности платежей по магнитным картам. С одной стороны, целостность данных магнитной карты надежно защищена кодом CVV/CVC (CVC – Card Verification Code, CVV – Card Verification Value) и модифицировать их бесполезно. С другой стороны, довольно просто скопировать всю карту целиком.
Для аутентификации в транзакциях по магнитной карте используются статические данные карты. Эти данные карты каждый раз передаются в банк-эмитент и не меняются на протяжении всего срока действия карты. Вдобавок, платежный терминал практически не оценивает риски транзакций по картам с магнитной полосой. В итоге – в случае полного копирования карты – банк-эмитент не сможет достоверно определить подлинность такой карты. Соответственно, вероятность проведения мошеннической операции достаточно высока.
Как этот вопрос решают EMV-карты?
Решением вышеописанной проблемы является цифровая подпись статических данных карты и данных транзакции, которые отправляются эмитенту. Поскольку цифровая подпись является уникальной для каждой транзакции, подделка или копирование EMV-карты является нетривиальной задачей.
Рассмотрим подробнее, как происходит динамическая аутентификация карты в ходе EMV-транзакции. Процесс транзакции начинается в момент установки карты в терминал. Терминал передает карте данные транзакции (сумма, валюта, страна и т.д.). Затем карта и терминал производят взаимную проверку рисков транзакции. Если оба устройства все «устраивает» то карта подписывает данные транзакции, а терминал заполняет полученными данными поле (таг или тэг) «DE 55» и отправляет его в банк-эквайер. Тот, в свою очередь, отправляет сообщение банку-эмитенту.
Эмитент, получив поле «DE 55», проверяет подлинность подписи (далее криптограммы) карты, которая рассчитана на основании динамических данных текущей транзакции, тем самым проверяя подлинность самой карты.
Описанный выше процесс является сильно упрощенной моделью EVM-транзакции. Однако он раскрывает главный аспект безопасности EVM-платежей – использование для аутентификации карты динамических данных вместо статических.
Стоит отметить, что у эмитента появляются новые возможности:
Также в EMV-транзакциях существенная роль отведена терминалу и его системе оценки рисков, согласно которой и терминал, и карта могут принимать решения о возможности проведения транзакции.
По большему счету, микропроцессорная карта стандарта EMV является обычной смарт-картой (почитать раз [3], два [4], три [5]), в основе которой лежат стандарты ISO/IEC 7816 [6] или ISO/IEC 14443 [7] (для бесконтактной).
Реализация EMV-карты может быть выполнена как на базе JavaCard [8] и GlobalPlatform [9], так и с помощью нативных методов смарт-карты. Аналогично обычными операционными системами (ОС), карточные ОС также имеют файловую структуру и приложения. В контексте этой статьи, наиболее интересны именно платежные приложения EMV-карты. Поэтому будем рассматривать именно их.
Что представляет собой платежное EMV- приложение?
C точки зрения пользователя (терминала или банкомата), платежное EMV-приложение – это программный продукт с интерфейсом, детально описанным в стандарте EMV.
Интерфейс представляет собой серию команд для проведения транзакций и управления EMV-приложениями. Подробную информацию можно найти в «EMV Book 3 Application Specification» [10]. Несмотря на существование стандарта, платежные приложения компаний Visa и MasterСard имеют отличия в реализации. Также могут отличаться и разные приложения одной компании. Например, «M/Chip 4» и «M/Chip Advance» компании MasterСard.
Вне зависимости от реализации, каждое приложение имеет свой собственный идентификатор, так называемый AID (Application Identifier). Он указывает к какому типу платежной системы относится приложение. По идентификатору приложения AID терминал определяет возможность проведения транзакции или, в случае нескольких приложений строит список поддерживаемых приложений и предлагает выбрать одно из них.
Если на карте реализована файловая структура и управление приложениями, какие же механизмы обеспечивают безопасность данных от доступа извне?
Тут стоит разделить время жизни карты до момента выпуска банком, и после.
Первичный доступ к чистой карте обычно регламентируется производителем чипов. Чаще всего каждая партия карт имеет свой ключ карты, с помощью которого необходимо аутентифицироваться с картой в ходе ее прошивки.
На следующем этапе доступ к файловой системе и приложениям обычно регулируется операционной системой. Она также имеет свой собственный ключ, и, соответственно, для доступа требуется аутентификация.
Далее установленное приложение проходит процесс персонализации карты. Персонализация представляет собой загрузку параметров и ключей приложения, которые определяют безопасность EMV-транзакций. Для доступа к этому процессу также требуется аутентификация с помощью ключа приложения.
После установки приложения и его персонализации вышеперечисленные доступы обычно закрываются навсегда. Что исключает возможность проникновения «внутрь» после выпуска карты.
Итого: ключ карты, ключ ОС и ключ приложения защищают карту от стороннего вмешательства на различных стадиях ее производства. В случае если в ходе изготовления часть карт будет дискредитирована (например, украдена), эти ключи защитят карты от вмешательства извне. А без знания ключей карты становится практически полностью бесполезными.
Некоторые данные приложения могут быть модифицированы и после выпуска карты. Изменения могут быть выполнены так называемыми скриптовыми командами. Исключительные права на внедрение изменений принадлежат эмитенту. Такая возможность предусмотрена, чтобы в любой момент времени, эмитент мог заблокировать или разблокировать карту, обновить лимиты или настройки карты. Обновление данных производится терминалом или банкоматом только после успешной онлайн транзакции (аутентификации с банком). Данные приходят на карту от эмитента в чистом виде, однако имеют в себе аналог цифровой подписи – MAC, который гарантирует целостность данных. Для расчета MAC используется соответствующий ключ приложения (один из трех DES ключей загружаемых в приложение).
Отдельными пунктами являются модификация оффлайн пин-кода (offline PIN) и счетчика лимита неудачных вводов пин-кода (PinTryLimit). Эти изменения также выполняются скриптовой командой с MAC-подписью. Однако, при смене пин-кода эти команды дополнительно шифруются с помощью специального ключа, предназначенного исключительно для выполнения описанного процесса.
Аналогично картам с магнитной полосой, 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 (при невозможности считать чип, терминал проводит операцию по магнитной полосе). В данный момент такие операции не приветствуется платежными системами, а риск по этим операциям ложится на эквайра или эмитента.
Существует два разных (хотя и выполняющих одну и ту же функцию) варианта проведения платежной транзакции – онлайн и офлайн. Выше мы в общих чертах рассматривали онлайн-транзакцию, которую эмитент подтверждает в режиме реального времени. Офлайн-транзакция проводится терминалом без моментального подтверждения банком. Такие транзакции используются для операций с низким уровнем риска или в случае, например, отсутствия связи с банком-эмитентом.
Для этих двух видов транзакций существует соответственно два вида аутентификаций – онлайн и офлайн. В случае выполнения онлайн-аутентификации, операция производится с участием эмитента, а офлайн-аутентификация подтверждается платежным терминалом. Стоит уточнить, что во время проведения онлайн- транзакции может выполняться как онлайн-, так и офлайн-аутентификация одновременно (если и карта, и терминал это поддерживают). Несмотря на избыточность схемы, на этапе аутентификации не всегда понятно в каком режиме будет проходить транзакция.
Порядок выполнения транзакции карта – терминал
Функции безопасности, рассматриваемые ниже, являются только частью 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, которые в сумме с остальными данными помогают понять эмитенту и платежной системе как происходит транзакция и предоставляют множество дополнительных деталей для оценки рисков транзакции.
Особенность офлайн-транзакции заключается в том, что транзакция проводится картой и терминалом без обращения к банку и платежной системе. В процессе такой транзакции карта может одобрить транзакцию в пределах установленного лимита, а терминал, в свою очередь, отправляет информацию в банк позже по расписанию, либо когда появится связь с банком. Такие офлайн-транзакции предоставляют дополнительные преимущества как банку-эмитенту, так и владельцу карты. Например, владелец может расплатиться даже, если связи с банком нет. Либо же, если сумма небольшая – операция пройдет намного быстрее.
Как происходит аутентификация карты при офлайн-транзакции?
Ранее упоминалось, что онлайн- и офлайн-аутентификации используют разные технологии. Если онлайн использует криптографический алгоритм 3DES, то в случае с офлайн используется RSA c ассиметричными ключами. Зачем же использовать такие разные технологии? Все дело в том, что при онлайн-аутентификации, ключи хранят только карта и банк. В случае же офлайна – ключ нужно доверить терминалу. Учитывая наличие большого количества терминалов, существует вероятность, что секретный ключ доверенный терминалам недолго останется секретным.
Т.к. детальное описание офлайн-аутентификации карты достаточно большое, рассмотрим упрощенную модель.
Static Data Authentication
Во главе всего стоит платежная система (точнее центр сертификации), которая выпускает пару ключей: приватный ключ (красный) и публичный ключ (синий). Банк-эмитент также имеет свою пару ключей. Для своих ключей эмитент специальным образом генерирует сертификат (Issuer Public Key Certificate), который содержит в себе публичный ключ эмитента. Этот сертификат подписан (зашифрован) приватным ключом платежной системы. В процессе персонализации этот сертификат загружается на карту.
Когда платежный терминал устанавливают в торговую точку и подключают к системе, публичный ключ платежной системы через банк-эквайер загружается в терминал.
В процессе офлайн-транзакции терминал производит офлайн-аутентификацию карты. Сначала терминал вычитывает из карты Issuer Public Key Certificate, и с помощью публичного ключа платежной системы проверяет правильность подписи сертификата (т.е. расшифровывает). Если подпись верна – извлекается публичный ключ эмитента. Далее, с помощью публичного ключа эмитента, проверяется подпись критических данных карты, чем и подтверждается ее подлинность.
Описанный выше метод относится к статической аутентификации SDA (Static Data Authentication). В настоящее время чаще используются динамические аутентификации: DDA (Dynamic Data Authentication) и CDA (Dynamic Data Authentication), которые включают в себя SDA и дополнительно, по аналогии с онлайн, подписывают данные, которые курсируют между терминалом и картой. Данные подписываются приватным ключом карты, который загружается на карту в процессе персонализации. Подпись проверяется терминалом с помощью публичного ключа, восстановленного из соответствующего сертификата.
Технология SDA позволяет терминалу проверить, что данные на карте не модифицированы. Однако, она не позволяет полностью идентифицировать подлинность карты (существует возможность скопировать SDA-данные). В свою очередь, технологии DDA и CDA позволяют подтвердить подлинность карты, потому что карта является носителем уникального приватного ключа, чей сертификат (публичный ключ) подписан приватным ключом эмитента (сертификат эмитента (его публичный ключ) подписан приватным ключом платежной системы).
Диаграмма DDA/CDA
Технологии DDA и CDA уже содержат в себе SDA и в целом сходны. Оба алгоритма используют уникальный ключ карты и динамические данные. DDA-аутентификация является отдельной операцией и выполняется до основного цикла процесса транзакции. CDA выполняется в основном цикле транзакции, а в качестве подписываемых данных дополнительно используется криптограмма карты. В целом, сегодня, технология DDA более распространена, хотя CDA является более предпочтительной в использовании.
Помимо цифровой подписи, терминал и карта умеют оценивать риски транзакции. Для офлайн-транзакции карта может оперировать несколькими видами счетчиков транзакций и аккумуляторов офлайн-сумм, валютами и странами, офлайн-пином и его лимитами, а также дополнительными правилами. В процессе персонализации карты эмитент имеет возможность ограничить максимальное количество последовательных офлайн-транзакций и/ или максимальную сумму транзакции (нижними и верхними лимитами), таким образом определяя уровень риска.
Для каждой из реализаций приложения конкретной платежной системы существует свой набор правил, на основании которых карта может принимать решения проводить офлайн, онлайн или отклонять транзакцию. Список этих правил достаточно гибкий и может по-разному настраиваться эмитентом для каждого карточного продукта. В процессе решения могут участвовать результаты предыдущих транзакций, офлайн-счетчики, результаты проверки пина и т.д.
Практически вся статья была посвящена транзакциям и процессу аутентификации карты, а пользователю карты уделялось мало внимания. С появлением технологии EMV проверка держателя карты не слишком видоизменились. В данный момент наиболее популярными методами проверки являются: проверка пин-кода (онлайнового и/или офлайнового) и подпись владельца карты. Так сложилось, что с приходом EMV не все платежные терминалы обладают одинаковыми возможностями проверки держателя карты (например, по причине возраста оборудования). В свою очередь, разные EMV приложения также могут быть ограничены в возможностях. Поэтому терминалу и карте приходится выбирать подходящий метод проверки держателя карты. Для этого используются так называемые CVM-списки. В CVM-списке определены методы проверки держателя карты и их приоритеты. И платежное приложение, и терминал имеют свои собственные списки. Итоговый список определяется путем объединения списков терминала и приложения. Из полученного итогового списка терминал выбирает общий CVM- метод с наибольшим приоритетом и осуществляет проверку держателя карты.
Пример такого списка представлен на картинке выше. Например, если карта вставлена в банкомат – будет запрошен онлайн-пин, если в терминал – офлайн-пин. В случае, если устройство не имеет пин-пада – будет запрошена проверка подписи. Во всех остальных случаях проверка держателя карты производиться не будет.
В данной статье былы поверхностно рассмотрены платежное EMV-приложение и хранимые в нем данные, описаны основные отличия в процессах проведения транзакций по магнитным и EMV-картам. Также были рассмотрены процедуры проведения онлайн и офлайн-транзакций и механизмы обеспечения их безопасности. Конечно же, каждый аспект технологии EMV, имеет гораздо большую глубину и степень сложности. Однако, надеюсь, что статья дала общее понимание принципа работы платежных EMV-карт и проведения платежей с их помощью.
В заключении можно сказать, что платежная EMV-карта сложный и высокотехнологичный продукт, надежно защищающий доступ к вашему счету в банке. Микропроцессорную EMV-карту практически невозможно скопировать, а каждая транзакция защищена уникальной цифровой подписью. Любые действия, происходящие внутри карты, регламентируются строгим набором правил с указаниями как поступать в каждом конкретном случае. В процессе создания платежные EMV-приложения проходят обязательную многоуровневую сертификацию и получают разрешение от платежной системы на их использование. Программировать такие карты сложно и интересно. Впрочем, описание этого процесса может растянуться еще не на одну статью.
Спасибо за внимание!
P.S. Буду рад ответить на ваши вопросы в комментариях
Автор: AlexGre
Источник [11]
Сайт-источник PVSM.RU: https://www.pvsm.ru
Путь до страницы источника: https://www.pvsm.ru/informatsionnaya-bezopasnost/117705
Ссылки в тексте:
[1] EMVCo: https://www.emvco.com/
[2] аутентификация: https://ru.wikipedia.org/wiki/%D0%90%D1%83%D1%82%D0%B5%D0%BD%D1%82%D0%B8%D1%84%D0%B8%D0%BA%D0%B0%D1%86%D0%B8%D1%8F
[3] раз: https://habrahabr.ru/post/210062/
[4] два: https://habrahabr.ru/post/74092/
[5] три: https://habrahabr.ru/post/255529/
[6] ISO/IEC 7816: https://ru.wikipedia.org/wiki/ISO/IEC_7816
[7] ISO/IEC 14443: https://ru.wikipedia.org/wiki/ISO/IEC_14443
[8] JavaCard: http://www.oracle.com/technetwork/java/embedded/javacard/overview/index.html
[9] GlobalPlatform: https://www.globalplatform.org/
[10] «EMV Book 3 Application Specification»: https://www.emvco.com/specifications.aspx?id=223
[11] Источник: https://habrahabr.ru/post/281438/
Нажмите здесь для печати.