pan в чеке что это
Маскирование ИЛИ усечение номера PAN: в чем разница?
Я, конечно, не получаю пачками вопросы по безопасности платежных карт, однако, время от времени кто-нибудь да и задаст мне такой вопрос, который заслуживает отдельной публикации в блоге. Буквально на днях одна читательница, Мишель, задала мне такой вопрос, который, в целом отражает часто встречающееся непонимание в сфере безопасности платежных карт:
Вчера я перечитывала PCI DSS 2.0, требование 3.4, и была немало удивлена тем, что для защиты хранимых номеров PAN не предлагается такая мера как «маскирование». Правильно ли я понимаю, что эти номера подлежат шифрованию перед помещением их на хранение, а при извлечении, они подлежат расшифрованию и маскированию? И потом, если мы получаем номер PAN уже в маскированном виде, а затем храним его, то попадает ли такое хранение под действие стандарта PCI DSS? С технической точки зрения, как я думаю, не попадает, т.к. PAN уже маскирован при получении, а значит нет возможности найти номер PAN в незашифрованном виде.
Вот в этом как раз и кроется основная суть непонимания сути маскирования. Многие люди либо вообще не знают о существовании усечения и полагают, что если они не могут видеть полный номер карты, то это маскирование, либо считают, что усечение и маскирование — это одно и то же. Несомненно это разные вещи, поэтому я позволю себе процитировать определения маскирования и усечения прямо из Глоссария PCI SSC:
Маскирование (Masking)
Метод сокрытия сегмента данных при отображении или печати. Маскирование используется, когда нет служебной необходимости в просмотре всего номера PAN.
Усечение (truncation)
Метод приведения номера PAN к нечитаемому виду посредством удаления сегмента данных PAN.
Представьте себе данные о держателе карты (далее – ДДК) в виде цифр на листке бумаги. При маскировании мы словно берем коррекционную ленту и наносим ее на большую часть цифр таким образом, чтобы человеку, которому передается этот листок, было видно только последние 4 цифры. Очевидно, что при этой операции данные по прежнему существуют под коррекционной лентой, хотя она их и скрывает. Разумеется, с этого листка бумаги, приложив некоторые усилия, можно счистить коррекционную ленту, а значит этот лист бумаги по прежнему нуждается в защите, при которой никакие злоумышленники не могли бы восстановить и использовать данные о держателе карты.
В свою очередь, если бы мы хотели выполнить усечение на этом листке бумаги, то мы бы либо вообще изначально не писали эти цифры, либо стерли их настолько надежно, что их никогда нельзя было бы воссоздать. Такие данные никогда не были бы написаны на листе бумаги, а значит никак не могли бы быть использованы для мошенничества с платежными картами. В таком сценарии, этот лист бумаги не имеет никакой ценности для злоумышленника, а значит нет необходимости его защищать, по крайней мере в той же степени, в которой следует защищать маскированные данные. Конечно, к этим усеченным данным могут быть привязаны какие-то дополнительные данные или значения, но сами по себе усеченные данные ценности не имеют.
Если на экране отображаются данные, из которых видна только малая часть, то нельзя знать наверняка, какие именно представлены данные — усеченные или маскированные. Для того, чтобы это узнать, необходимо глубже понимать процессы их обработки. Только понимая процессы, можно сказать, можно ли каким-либо воссоздать эти данные или же в базе данных хранятся те же данные, которые видны на экране. Находясь в обычном магазине, можно увидеть на чеках последние 4 цифры номера карты. Если платежное приложение написано корректно, то должность персонала – будь то руководитель торгового зала или продавец — не должна иметь значения: в любом случае никто не должен видеть ничего кроме последних 4 цифр номера. Дело в том, что в таком приложении данные не сохраняются, а значит ни у кого из сотрудников магазина нет возможности извлечь данные из системы — данные усечены и их в системе больше нет.
Совсем иная ситуация в бэк-офисе, в бухгалтерии и в службе, отвечающей за предотвращение ущерба. По умолчанию, сотрудники этих отделов и служб должны видеть только 4 последних цифры номера платежной карты. Однако при возникновении претензионных платежей или подозрений на вероятное мошенничество, сотрудники компании в рамках расследования должны иметь возможность отменить маскирование полного номера карты. Эти номера по-прежнему существуют на сервере, однако, они там в основном хранятся в маскированном (скрытом) виде, и отображаются только должным образом уполномоченному персоналу. Поскольку имеется возможность извлечения этих данных на серверах, они полностью входят в область оценки на соответствие стандарту PCI DSS и подлежат соответствующей защите.
Таким образом, отвечая на вопрос читательницы, я скажу, что хранимые данные не могут быть «маскированы». Они маскируются только при извлечении и считаются маскированными, если отображены частично. Именно поэтому, в требовании 3.4 отсутствует маскирование. Если же ТСП получает ДДК, в которых имеется только сегмент номера PAN (например, сегмент из первых 6 или последних 4 цифр), то такие данные являются усеченными. В таком случае полный номер PAN отсутствует, воссоздание его невозможно, а значит нет необходимости его защищать так же, как и ДДК. Я не говорю, конечно, о том, что данные, привязанные к этому номеру не имеют ценности и не подлежат защите, просто усеченные данные не входят в область применения требований стандарта.
Если же ТСП получает полный номер PAN, но сотрудникам он отображается в маскированном виде, то, даже если никто в ТСП не имеет доступа к ДДК, оно все равно отвечает за их защиту согласно требованиям стандарта. Если в этих данных нет необходимости, есть смысл просить о предоставлении усеченных данных, тем самым, сэкономив кучу сил и нервов на общении с аудиторами, выполнении требований стандарта, да и вообще на процессе приведения среды в соответствие со стандартом PCI DSS. Например, я приятный в общении человек, но даже самые большие мои поклонники среди клиентов подтвердят, что я становлюсь противным и невыносимым, как минимум, раз в год, когда прихожу к ним для проведения аудита.
Зачем в пречеке скрывают цифры номера карты?
Когда я пополняю свою карту по ее номеру в каком-нибудь салоне связи, мне дают пречек на проверку. Номер карты в нем частично скрыт. Зачем скрывают цифры в середине номера карты? Как я могу их проверить, если сотрудник салона мне их не диктует, ссылаясь на требования безопасности?
Буду рад, если объясните, зачем это нужно, ведь просто по номеру карты списать деньги невозможно.
Павел, действительно, номер карты скрывают в целях безопасности. Чтобы ответить на ваш вопрос, нужно объяснить, из чего состоит номер карты.
Из чего состоит номер карты
Последняя цифра — специальная, рассчитывается по алгоритму «Луна». Это особая формула, которая формируется из остальных цифр карты и выступает проверкой правильности и подлинности карты.
Вы могли обратить внимание, что даже в личном кабинете номер карты полностью не указан. В Тинькофф-банке это выглядит так:
Почему не указывают данные карты
Полностью данные чеков и пречеков не указываются в связи с требованиями стандартов безопасности данных индустрии платежных карт. В них прописано, что в чеке максимально могут быть указаны первые 6 и последние 4 цифры карты.
Раньше у Тинькофф-банка была договоренность с партнерами, через которых можно было пополнять счет так, чтобы на пречеке номер карты указывался полностью. Но в связи с обращениями клиентов и принятыми стандартами теперь в пречеках стали указывать только последние 4 цифры номера карты.
Сотрудники салона чаще всего сами предлагают устно проверить номер введенной карты. Если вы переживаете, что могли ошибиться в номере карты, попросите сотрудника сверить с вами номер карты или пополняйте карту по номеру договора.
Если у вас есть вопрос о личных финансах, правах и законах, здоровье или образовании, пишите. На самые интересные вопросы ответят эксперты журнала.
Платежные технологии – просто о сложном. Часть 1
Давайте поговорим о платежных технологиях и что происходит, когда клиент хочет оплатить услугу на сайте или в интернет-Банке, сделать перевод или нам просто необходимо настроить интеграцию с агрегатором, магазином или платежной системой в целях вывода их услуг в своих дистанционных каналах обслуживания.
Здесь будет представлена серия статей, которая поможет начинающим специалистам в ИТ, занимающихся платежными технологиями, ответить на вопрос: «как писать исходящий шлюз с платежной системой или агрегатором», «как решить вопрос с расхождениями при сверках», как реализовать интеграцию с международной платежной системой.
Устраивайтесь поудобнее, будет интересно.
Часть 1: Проведение и подтверждение платежа
Клиент для оплаты услуг как правило авторизуется в интернет-Банке, выпустившим его карту: Банку-Эмитенту его карты.
Далее в интернет-Банке, выбирает услугу для оплаты: пополнение мобильного телефона, оплаты интернета или услуг ЖКУ.
В базе поставщика услуги, например оператора сотовой связи, у клиента есть свой уникальный идентификатор – номер телефона.
Чтобы оплатить услугу клиент вводит свой идентификатор и сумму пополнения, нажимает кнопку «подтвердить платеж».
А дальше ему отображается пред чек с идентификатором пополнения и суммой пополнения. Он подтверждает оплату и далее интернет-Банк отображает ему чек. Клиент радостный уходит. Деньги «моментально» поступают на его номер телефона.
Это для клиента так. А давайте посмотрим, как это выглядит внутри систем.
Наш онлайн обмен сообщениями, будет состоять из нескольких участников:
Витрина – в данном случае, интернет-Банк клиента;
Банк клиента – он же оператор по переводу денежных средств, он же Банк-Эмитент, выпустивший карту клиента, и он же расчетный Банк по переводам средств клиента Сервис-Провайдеру;
Сервис-Провайдер – юридическое лицо, оказывающее услуги зачисления средств Поставщику, его часто называют «Мерчант». Сервис-Провайдер имеет прямые договора со многими поставщиками услуг, и чтобы Банку не настраивать интеграцию с каждым из них, на рынке есть компании-посредники: Сервис- Провайдеры, еще их называют агрегаторами, платежными системами. Они уже настроили интеграцию с Поставщиками услуг и предоставляют большое количество сервисов за определенный процент;
Наш оператор сотовой связи – Поставщик услуг;
И у Сервис-Провайдера и у Поставщика услуг есть свои расчетные Банки. В итоге, Банк Сервис-Провайдера в офлайне перечислит денежные средства на счет Поставщика услуг в целях зачисления на счет клиента. Но об этом в следующих статьях.
Я буду использовать сущности: Банк, Мерчант и Витрина для описания онлайн взаимодействия внутри систем.
Центральной фигурой в нашем взаимодействии является Банк клиента.
У Банка задача не только проверить наличие денежных средств у клиента, но и доставить их Сервис-Провайдеру. Для выполнения этого условия Банк, как правило, пишет два шлюза либо использует текущие:
Входящий: от Витрины к Банку;
Исходящий: от Банка к Мерчанту;
Оба эти шлюза могут работать как по тождественному протоколу, так и по разным.
Мы рассмотрим самый простой вариант: витрина Банка, Банк и Мерчант работают по одному сквозному протоколу, представленному всего двумя методами: check и pay.
Описание процесса проведения и подтверждения платежа в этом случае выглядит следующим образом:
Сиквенс проведения и подтверждения платежа
Описание процесса проведения и подтверждения платежа
Клиент выбирает услугу;
Витрина Банка проверяет наличие услуги у себя в Базе данных;
2.1 Если услуга найдена, формирует запрос в Банк на холдирование денежных средств в Процессинге. Далее формирует запрос на возможность совершение платежа check:
2.2 Если услуга не найдена, завершает процесс ошибкой, клиент уходит;
Витрина инициирует check;
В Банк поступает запрос check. Далее Банк маршрутизирует запрос Мерчанту;
Мерчант принимает запрос, выполняет проверку совершения платежа;
5.1 Если зачисление возможно, отправляет успех, клиенту отображается пречек. Система Банка ожидает подтверждение платежа;
5.2 Если зачисление невозможно, Банк отправляет код ошибки, витрина завершает процесс, проведение невозможно, клиент уходит;
Клиент знакомится с пречеком, нажимает кнопку «подтвердить платеж». Витрина инициирует pay;
Банк присваивает идентификатор транзакции и сразу отправляет ответ на витрину;
Зачисление денежных средств у Мерчанта уже выполняется в офлайне. Банк инициирует pay и, если зачисление возможно, Мерчант присваивает свой идентификатор транзакции и отправляет в Банк успешный ответ. А если зачисление невозможно – спросите Вы? Тогда Мерчант отправляет ответ в Банк с кодом ошибки, и Банк выполняет возврат денежных средств клиенту в автоматическом режиме в тот же день.
Теперь рассмотрит рассмотрим формат запроса и ответа для каждого из методов, за что они отвечают и для чего они нужны
CHECK – проведение платежа
Метод отвечает за возможность совершения платежа. На этом шаге выполняется проверка доступности услуги на витрине, в Банке и у Мерчанта. Мерчант в свою очередь, в онлайне, может сходить к Поставщику и проверить валидность идентификатора пополнения у Поставщика, и, если, он не найден или ошибка, отклонить платеж.
Очень часто на этом шаге закладывают минимальные требования к времени отклика ответа на запрос от Мерчанта, т.к. клиент не будет ждать, пока Витрина Банка, сам Банк и Мерчант проверят доступность услуги.
Отличительной особенностью этого шага является так же расчет комиссии. Комиссии бывают:
Верхняя, или горячая – это комиссия с клиента сверх тела платежа (суммы зачисления);
Нижняя или холодная, это комиссия, которую платит Банку Мерчант;
Смешанная – в этой рубрике мы не будем о них говорить;
В нашем примере на check рассчитывается только комиссия с клиента, нижняя и смешанная комиссии рассчитываются в отдельно. Об этом с следующих статьях.
Структура запроса check/XML, шлюз контура Витрина – Банк:
Time – дата платежа;
type – тип источника списания;
code – код валюты перевода, в примере рубли;
amount – сумма зачисления или, по-другому, тело платежа
commission_amount – сумма с учетом верхней комиссии;
service – цифровой идентификатор услуги, который проверяет есть ли вообще такая услуга в Банке и на витрине;
account – контейнер с идентификатором пополнения, в нашем случае – номер телефона;
Когда клиент на витрине нажимает иконку с оплачиваемой услугой, первое, что выполняет система, это проверяет доступность услуги и если она доступна, то дальше обращается в процессинг для проверки источника списания (поля Type и type_number)
Далее если денежные средства есть, проверяет возможность зачисления денежных средств на номер телефона (phone_number в значении 86248541234)
Подождите, секундочку – спросите вы. Что-то здесь не сходится. Как по маскированному PAN в поле type_number можно проверить наличие денежных средств на карте клиента?
Все верно, внимательные читатели обратили внимание, что по маскированному PAN это сделать нельзя.
Авторизация в процессинге выполняется перед check и это отдельный метод и отдельный процесс, посмотрите выше на диаграмму процесса. На проведении платежа мы уже работаем с маскированным PAN, т.к. на этом шаге мы проверяем возможность проведения платежа, а не наличие денежных средств на карте клиента.
Далее мы формируем запрос Мерчанту.
Мы не указываем ни PAN, ни тип источника списания, нас интересует только возможность совершения платежа для конкретного сервиса.
Структура запроса check/XML, шлюз контура Банк – Мерчант:
В ответе Мерчант возвращает все те же самые поля, но появляется дополнительный контейнер со статусом обработки операции, а также идентификатор транзакции в поле id
Структура ответа check/XML, шлюз контура Мерчант – Банк:
Такой ответ будет означать, что Мерчант готов к подтверждению платежа клиентом.
В ответе мы у нас будет временный id транзакции у Мерчанта, а так же статус обработки платежа: status_id == Success (успех) и код ошибки равный 0 (успех) в поле errorCode
Не всегда к нам приходят успешные статусы транзакций и не всегда у нас отсутствуют коды ошибок, но об этом мы поговорим в следующих статьях.
Мы сохраняем ответ и обогащаем его необходимыми для витрины полями, присваиваем идентификатору транзакции мерчанта – идентификатор в Банке и отправляем ответ на витрину.
Структура ответа check/XML, шлюз контура Банк – Витрина
Клиент видит экранную форму пречека, с который каждый из нас знаком: там будет сумма платежа, дата, а так же идентификатор пополняемой услуги.
Если клиент со всем согласен, он нажимает кнопку «оплатить». Теперь отменить платеж можно только по письменному распоряжению плательщика, как правило – при личном обращении в Банк.
В запросе витрина может передать как все поля из предыдущего ответа check, так и просто сумму платежа и идентификатор транзакции, полученной на предыдущем шаге.
Мы будем использовать первый вариант.
PAY – подтверждение платежа
Структура запроса pay/XML, шлюз контура Витрина – Банк :
Банк регистрирует платеж, и сразу отправляет ответ с промежуточным статусом обработки операции «в проведении» в ответ витрине
Структура ответа pay/XML, шлюз контура Банк – витрина:
Клиенту печатается чек о приеме к исполнению платежа, с печатью Банка и он уходит.
Но вы еще к Мерчанту не сходили, не подтвердили у него оплату, не зарегистрировали у него платеж, а уже отпускаете клиента – снова спросите вы?
Все верно, клиент не будет ждать, пока мы сходим и зарегистрируем платеж у Мерчанта, а он свою очередь к своим поставщикам на удаленные системы. Мы уже проверили возможность совершения платежа в онлайне на предыдущем шаге check, а теперь можем отпустить клиента с печатью Банка «в проведении» и зарегистрировать оплату у мерчанта в офлайне.
Для регистрации оплаты у мерчанта, для переданного id транзакции витрины, находим транзакцию мерчанта из предыдущего шага и с ней уже регистрируем платеж.
Структура запроса pay/XML, шлюз контура Банк – мерчант:
В ответ мерчант сообщает статус обработки транзакции, который может принимать статус успех, в проведении или, если оплата была отклонена, ошибка.
Два статуса финальные, а один промежуточный.
Можно сказать, что на этих статусах обязательства и Банка и Мерчанта перед клиентом завершены.
Да, такое бывает достаточно часто, и для решения этой задачи существует отдельный процесс по запросу финального статуса операции как на стороне витрины, так и на стороне Банка, но об этом в следующих статьях.
Платежная EMV-карта. Механизмы обеспечения безопасности платежа
Платежные карты прочно вошли в нашу жизнь. Еще совсем недавно повсеместно использовались только карты с магнитной полосой. Сегодня же никого не удивишь картой с чипом. Всем известно, что чиповая, микропроцессорная или, созвучнее, платежная 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-платежей – использование для аутентификации карты динамических данных вместо статических.
Стоит отметить, что у эмитента появляются новые возможности:
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-приложения проходят обязательную многоуровневую сертификацию и получают разрешение от платежной системы на их использование. Программировать такие карты сложно и интересно. Впрочем, описание этого процесса может растянуться еще не на одну статью.