курс цб на 23.03:
57.636
62.2699
Лента новостей

Новые механизмы управления рисками для карт стандарта CPA

Количество просмотров11 просмотров
Want create site? Find Free WordPress Themes and plugins.

В одном из ранее опубликованных материалов Игоря Голдовского (см. статью “Что день грядущий нам готовит? Часть II”, “ПЛАС” № 3/2006) автором уже было уделено внимание таким значимым событиям индустрии платежных карт, как появление в конце 2005 г. спецификаций Common Payment Application (CPA), разработка EMVCo единой процедуры тестирования приложения карты (EMVCo Type Approval Process for Card Application ) и единых процедур оценки безопасности карт стандарта EMV – EMV Security Evaluation Process. Продолжая данную тему, в этот раз мы предлагаем вниманию читателей анализ новых механизмов управления рисками, реализованных в рамках стандарта CPA.

лизу другой записи Profile Selection Table Entry. Фактически таблица Profile Selection Table представляет собой компьютерную программу (набор инструкций), а каждая запись таблицы – Profile Selection Table Entry – является оператором условного перехода вида “если выполняется X, то Y, иначе Z”. При этом выполнение условия X определяется по значениям определенных в Profile Selection Table Entry параметров транзакции, терминала и карты, а решения Y и Z, как уже отмечалось выше, представляют собой либо значение идентификатора выбранного профиля карты Profile ID, либо указание на следующую запись таблицы (в нашей интерпретации – указание на следующий оператор, который должен быть исполнен в программе), к обработке которой следует перейти. Вид записи Profile Selection Table Entry показан на рис. 1.
 Как показывает рис. 1, каждая запись таблицы определяет:
• номер первого байта (Position) в данных команды Get Processing Options, используемого для выбора профиля карты (обозначим этот номер через Х);
• количество байтов поля данных команды Get Processing Options, используемых для выбора профиля карты (Comparison Block Length); обозначим это количество байтов через L; таким образом, для выбора профиля используются байты X,…,X + L – 1 поля данных команды Get Processing Options;
• маску (Bit Mask), представляющую собой последовательность из логических 0 и 1 длиной L байтов; с помощью маски путем по-битового логического умножения ее битов с соответствующими (с теми же последовательными номерами) битами байтов X,…,X+L–1 поля данных команды Get Processing Options получается маскированная последовательность Z. Элемент Check Type определяет тип сравнения данных Comparison Value 1, …, Comparison Value (n – 1) записи Profile Selection Table Entry с маскированной последовательностью Z.Если тип сравнения – “=”, то количество блоков Comparison Value может быть любым натуральным числом. Если тип сравнения – “>” или “<”, то используется единственный блок Comparison Value 1. Если тип сравнения – “=”, то считается, что проверка завершилась успешно в случае, если маскированная последовательность Z совпадает с какимлибо из блоков Comparison Value 1, …, Comparison Value (n – 1).

Элементы Positive Action и Negative Action записи Profile Selection Table Entry определяют дальнейшие действия карты по выбору своего профиля. Описанный выше алгоритм показан на рис. 2. В рамках этой статьи мы не будем подробно рассматривать процедуру выбора профиля карты. Отметим только, что данная процедура позволяет задать профиль карты по практически любому набору параметров операции, терминала и карты, состав которого (набора) выбран эмитентом карты. Теперь поговорим о том, что определяет выбранный профиль карты при обработке транзакции (см. рис. 3). Профиль карты определяет: • набор данных, которые должны быть прочитаны терминалом для обработки транзакции (Application File Locator, или AFL), а также возможности карты, связанные с обработкой текущей транзакции (Application Interchange Profile, или AIP), – поддержка методов аутентификации приложения и процедур верификации держателя карты, способ аутентификации эмитента; • объекты данных – триплеты Card Issuer Action Code (CIAC), с помощью которых после получения картой результатов выполнения процедур управления рисками (объекта ADR) она принимает решение (с учетом решения, принятого терминалом) о способе продолжения транзакции: завершить операцию одобрением или отклонением в офлайновом режиме или отправить операцию на обработку эмитенту карты; при этом триплеты CIAC в CPA стали развитием объектов данных спецификации M/Chip4 и представляют собой альтернативу объекту Application Default Actions, используемому в спецификациях VIS 1.4; • объект Issuer Options, о котором будет рассказано ниже;
• два кумулятивных счетчика Accumulator 1 и Accumulator 2, позволяющих вводить ограничения на использование средств по карте при выполнении операции в офлайновом режиме;
• два циклических кумулятивных счетчика Cyclic Accumulator 1 и Cyclic Accumulator 2, позволяющих вводить ограничения на использование средств по карте при выполнении операции в офлайновом режиме;
• три счетчика транзакций Counter 1, Counter 2, Counter 3, позволяющих вводить ограничения на количество операций, выполняемых по карте в офлайновом режиме;
• значение кумулятивного счетчика VLP (VISA Low Value Payment), используемого в продуктах Visa International для реализации офлайновых операций на небольшие суммы;
• максимальное значение суммы операции по карте Maximum Transaction Amount, с помощью которого можно устанавливать максимальный размер операции, при котором она еще может быть выполнена в офлайновом режиме.

Остановимся на наиболее важных параметрах, задаваемых профилем карты. В первую очередь отметим, что выбор профиля задает объекты AIP/AFL, фактически определяющие способ обработки транзакции. Например, для транзакций на небольшие суммы с помощью AIP можно заявить о том, что карта не поддерживает верификацию ее держателя или даже не поддерживает процедуру динамической аутентификации. Такой подход ускоряет обработку транзакции и в то же время является допустимым для безопасности операции с точки зрения эмитента карты. Объекту AIP должен соответствовать и другой объект данных – AFL, определяющий линейные файлы/записи, которые должны быть прочитаны терминалом до начала обработки транзакции. Например, в предыдущем примере AFL не должен указывать на записи, содержащие объект CVM List, описывающий способы верификации держателя карты, поддерживаемые картой, а также на реквизиты карты, используемые при проведении процедуры динамической аутентификации.

Триплеты CIAC, определяющие правила принятия решения по результатам выполнения процедур управления рисками (объекту ADR), также могут задаваться профилем карты. Например, можно определить профиль высокорискованных транзакций (например, по коду страны обслуживающего банка и/или типу торгового предприятия), для которого все операции должны обслуживаться только в онлайновом режиме. Такой режим обслуживания транзакции можно установить с помощью соответствующего триплета CIAC. Можно также выставить условие, чтобы операции покупки при выборе профиля высокорискованных транзакций обрабатывались с использованием метода верификации держателя карты PIN Offline. Если проверка ПИН-кода не производилась, то операция должна быть картой отклонена. Очень важным объектом данных является объект Issuer Options. Этот объект определяет:
• необходимость логирования транзакций на карте;
• необходимость выполнения двух дополнительных проверок в рамках процедуры управления рисками карты (CRM);
• необходимость использования в рамках CRM счетчика максимального количества дней, прошедших с момента выполнения последней онлайновой операции (Max Days Offline Counter); • необходимость шифрования значений счетчиков карты при их передаче эмитенту в рамках объекта данных Issuer Application Data;
• необходимость установки картой начального значения Max Days Offline Counter после обработки онлайновой транзакции;
• возможность обойти решение CIAC-Default для торговых терминалов, способных функционировать только в офлайновом режиме;
• ряд других параметров карты. На рис. 4 показаны определяемые Issuer Options объекты данных.

В свою очередь, наиболее интересным элементом объекта Issuer Options являются две дополнительные проверки, определенные для платежного приложения карты независимо от выбранного профиля – профиль карты в данном случае лишь определяет необходимость выполнения каждой из проверок. Дополнительные проверки выполняются для данных, полученных картой в командах Generate AC. Если некоторые полученные данные равны одному из определенных заранее эмитентом значений, то проверки считаются завершенными с положительным результатом (соответствие найдено). Результаты проверок определяют соответствующие биты ADR и таким образом влияют на результат обработки транзакции (на результат выполнения процедуры CAA).

Блок-схема алгоритма выполнения дополнительной проверки показана на рис. 5. Как уже ранее отмечалось, для CPAприложения карты могут быть определены три счетчика операций, выполняемых по карте. Независимо от профиля карты каждый счетчик определяется условиями, заданными эмитентом при персонализации карты, при которых его текущее значение должно увеличиваться на единицу. Эти условия включают в себя определение необходимости учета:
• ARQC-операций (операций, при выполнении которых вычислялась криптограмма ARQC);
• офлайновых транзакций, завершившихся отказом;
• офлайновых успешно завершенных операций;
• только международных транзакций;
• только внутренних (domestic) транзакций;
• только транзакций, не изменяющих значение какого-либо кумулятивного счетчика. При этом профиль карты для каждого счетчика определяет:
• необходимость использования данного конкретного счетчика;
• значения верхнего и нижнего лимитов, определяющих необходимость обработки транзакции в онлайновом режиме в случае применения, соответственно, только офлайнового (Offline Only) терминала и терминала, способного выполнять операции в онлайновом режиме;
• необходимость переустановки счетчика после выполнения онлайновой операции;
• необходимость передачи значения счетчика эмитенту в рамках объекта Issuer Application Data (IAD).

На карте определены два кумулятивных счетчика, Accumulator 1 и Accumulator 2, позволяющие вводить ограничения на использование средств в операциях, выполняемых по карте в офлайновом режиме. Для каждого счетчика независимо от выбранного профиля карты заданы два набора значений верхнего и нижнего лимитов, позволяющие вводить ограничения на использование средств в офлайновых операциях. Превышение верхнего и нижнего лимитов требует обработки транзакции в онлайновом режиме в случае применения, соответственно, только офлайнового (Offline Only) терминала и терминала, способного выполнять операции в онлайновом режиме. Профиль карты для каждого счетчика определяет один из двух наборов значений верхнего и нижнего лимитов, а также:
• необходимость использования счетчика при выполнении текущей операции;
• необходимость переустановки кумулятивного счетчика после выполнения онлайновой операции,
• необходимость передачи значения счетчика эмитенту в рамках объекта Issuer Application Data (IAD);
• возможность конверсии суммы транзакции в валюту лимитов;
• таблицу конверсии валюты.

На карте также заданы два циклических кумулятивных счетчика, Cyclic Accumulator 1 и Cyclic Accumulator 2, позволяющие вводить ограничения на использование средств в офлайновых операциях, выполненных по карте в течение заданного периода времени (день, неделя, месяц). Для каждого счетчика независимо от выбранного профиля определены тип счетчика (дневной, недельный, месячный), валюта счетчика и необходимость включать в него успешно завершенные онлайновые операции. Профиль карты для каждого счетчика определяет необходимость использования данного счетчика при выполнении текущей операции, значение лимита, превышение которого означает необходимость выполнения операции в онлайновом режиме, а также таблицу конверсии валюты транзакции в валюту счетчика. Значения циклических кумулятивных счетчиков эмитенту не отправляются. Помимо перечисленных счетчиков каждый эмитент карты CPA имеет возможность использовать дополнительные счетчики и дополнительные проверки в рамках процедуры управления рисками.

В спецификациях M/Chip4 на карте используются следующие счетчики: • VCC (velocity checking count) – количество последовательных офлайновых операций, выполненных картой после выполнения онлайновой операции. Очевидно, что VCC = ATC – LATC (LATC – Last Online Application Transaction Counter, Tag ‘9F13’ – номер последней онлайновой транзакции). • COTA (cumulative offline transaction amount) – сумма денежных средств, выраженная в валюте Application Currency Code и потраченная по карте в последовательных успешных офлайновых транзакциях. Для перечисленных счетчиков в спецификациях M/Chip4 эмитент может установить следующие лимиты:
• Lower Consecutive Offline Limit (LCOL, Tag ’9F14’, 1 байт) – определяет максимальное количество последовательных офлайновых операций, которые карта может выполнить на терминале, способном обработать транзакцию в онлайновом режиме;
• Upper Consecutive Offline Limit (UCOL, Tag ’9F23’, 1 байт) – определяет максимальное количество последовательных офлайновых операций, которые карта может выполнить на терминале, не способном обработать транзакцию в онлайновом режиме;
• Lower Cumulative Off-line Transaction Amount (LCOTA) – определяет максимальную величину денежных средств, выраженную в валюте Application Currency Code (Tag ‘9F42’), которую эмитент разрешает потратить по карте в рамках последовательных офлайновых операций на терминале, способном обработать транзакцию в онлайновом режиме;
• Upper Cumulative Off-line Transaction Amount (UCOTA) – определяет максимальную величину денежных средств, выраженную в валюте Application Currency Code (Tag ‘9F42’), которую эмитент разрешает потратить по карте в рамках последовательных офлайновых операций на терминале, не способном обработать транзакцию в онлайновом режиме. Все операции в M/Chip4 делятся на локальные (domestic) и остальные – трансграничные (non-domestic) транзакции. Транзакция считается локальной, если:
• Terminal Country Code = Issuer Country Code;
• Transaction Currency Code = Application Currency Code. Проверки параметра VCC производятся с помощью анализа неравенств ATC – LATC > LCOL/NDCF и ATC – LATC > UCOL/NDCF, где коэффициент NDCF (Non-Domestic Control Factor) равен 1 для локальных транзакций и NDCF1 для трансграничных транзакций.

Каждый эмитент карты CPA имеет возможность использовать дополнительные счетчики и дополнительные проверки в рамках процедуры управления рисками При проверках параметра COTA может случиться так, что код валюты транзакции (Transaction Currency Code) не равен коду валюты приложения (Application Currency Code). В этом случае стандарт EMV предусматривает возможность конверсии суммы транзакции АА в валюту приложения (Application Currency). Для этого карта должна поддерживать для валюты транзакции курс обмена Reference Currency to Application Currency Conversion Rate. Курс обмена умножается на сумму транзакции в валюте транзакции для того, чтобы получить сумму транзакции АА1 в валюте приложения. Далее проверки параметра COTA производятся с помощью анализа неравенств LCOTA – COTA < AA1 и UCOTA – COTA < AA1.

В спецификациях VIS 1.4 эмитенты карт используют лимиты на количество офлайновых транзакций и объем потраченных по ним средств, отличные от применяемых в M/Chip4. К этим лимитам относятся:
• Consecutive Transaction Limit (International, Currency) – максимально допустимое количество последовательных офлайновых операций, в которых код валюты транзакции отличается от кода валюты карты (Application Currency Code);
• Consecutive Transaction Limit (International, Country) – максимально допустимое количество последовательных офлайновых операций, в которых код страны эмитента (Issuer Country Code) отличается от кода страны терминала (Terminal Country Code);
• Cumulative Total Transaction Amount Limit – максимальный размер средств, которые можно потратить по карте в рамках последовательных офлайновых транзакций, сумма которых выражена в валюте Application Currency Code;
• Cumulative Total Transaction Amount Limit (Dual Currency) – максимальный размер средств, которые можно потратить в рамках последовательных офлайновых транзакций, сумма которых выражена в валюте Application Currency Code или какой-либо иной валюте, выбранной эмитентом. Очевидно, для каждого из перечисленных лимитов на карте поддерживаются соответствующие счетчики. Заметим, что в спецификациях VIS 1.4 лимиты на количество последовательных офлайновых операций определены только для международных транзакций (отдельно по валюте и коду страны терминала). Таким образом, локальный трафик офлайновых операций в VIS 1.4 регулируется только размером средств, потраченных в рамках офлайновых операций. Очевидно, что параметры управления рисками в спецификациях CPA позволяют описать схемы счетчиков, принятые в протоколах M/Chip4 и VIS 1.4, и более того, дают возможность описать и многие другие ограничения, позволяющие эмитенту формировать разнообразные правила обработки транзакции в офлайновом режиме.

Следует отметить, что процедуры управления рисками не специфицируются в стандарте EMV. EMVCo всегда считала разработку этих процедур прерогативой платежных систем и банков-эмитентов. В рамках спецификаций CPA на основе опыта использования уже используемых процедур на картах VIS 1.4 и M/Chip4 компания EMVCo впервые определила процедуру управления рисками карты. При этом спецификации CPA приняты Visa International и MasterCard Worldwide в качестве альтернативного стандарта для своих микропроцессорных карт.

Совершенно очевидно, что возможности карты CPA в части управления рисками гораздо выше в сравнении с возможностями карт стандартов VIS 1.4 и M/Chip4. Основные преимущества CPA состоят в следующем:
1. Формализована и внедрена процедура выбора способа обработки транзакции в зависимости от ее параметров (выбор профиля).
2. Расширен набор параметров управления рисками карты (большее количество различным образом настраиваемых счетчиков).
3. Эмитенту предоставлены широкие возможности для создания собственных правил принятия решения по способу обработки транзакции (Issuer Options). Следует отметить, что процедура выбора способа обработки транзакции (см. пункт 1) была доступна и в рамках других (не CPA) микропроцессорных карт. Однако стандартный механизм ее реализации был впервые формализован именно в спецификациях CPA.

Отметим, что EMVCo, идя навстречу банкам крупнейших международных платежных систем, к настоящему моменту определила два профиля карты – профиль для реализации процедур аутентификации держателя карты (CAP/TBA – Chip Authentication Program/Token Based Authentication) и профиль для операций на небольшие суммы (low value transactions). Известно, что платежные системы изначально рекомендовали банкам для реализации схем аутентификации держателя карты использовать отдельное (не платежное) EMV-приложение. Это требуется для того, чтобы не оказывать влияния на значения счетчиков платежного EMV-приложения функциональностью операций аутентификации. Для реализации функции CAP/TBA в соответствующем профиле платежного приложения, задаваемого CNP-транзакцией, необходимо определить объект AIP, в соответствии с которым карта не поддерживает ни один из методов динамической или статической аутентификации приложения, а объект CVM List состоит из единственного элемента – Plaintext PIN verification by ICC.Кроме того, в данном профиле не должны использоваться счетчики карты (все они дезактивированы), а объект CIAC-Decline должен указывать на необходимость отклонения транзакции в офлайновом режиме (например, установив бит Offline PIN Verification Performed равным 1).

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

Текст статьи читайте в журнале ПЛАС № 8-9 за 2006 год

Did you find apk for android? You can find new Free Android Games and apps.




В рубриках:
Журнал ПЛАС № 8-9 (118-119)2006

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *