Google+
Журнал Плас Плас Журнал http://www.plusworld.ru/
ул. Кржижановского, д. 29, корп. 5 Москва, 117218 Россия
+7 495 961 1065 http://www.plusworld.ru/upload/templates/logo_plus_ru.png
RSS RSS RSS RSS

EMV-проект: step-by-step

(Голосов: 1, Рейтинг: 5)

11.01.2006 Количество просмотров 4793 просмотра
Данной статьей, посвященной детальному анализу практических аспектов реализации EMV-проекта, журнал “ПЛАС” открывает новую рубрику – “Взгляд эксперта”, которая, как мы надеемся, станет своего рода открытой трибуной для обмена практическим опытом между нашими читателями – представителями банковского сообщества, компаний-вендоров и специалистами платежных систем. Как известно, в карточном бизнесе существует широкий ряд аспектов практического характера, по каждому из которых многие из специалистов могут выступать в качестве экспертов, рассказав своим коллегам много интересного. При этом очевидно, что каждый банк, сталкиваясь с тем или иным из этих практических вопросов, решает их по-разному. Как решать их правильно и эффективно – именно этому посвящена наша новая рубрика.

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

Редакция журнала “ПЛАС”


EMV-миграция:от Шекспира к Чернышевскому
Несмотря на то что в настоящий момент многие российские банки уже начали процесс перехода на EMV, а некоторые из них уже достаточно давно осуществляют выпуск и эквайринговое обслуживание микропроцессорных карт, вопрос EMV-миграции по-прежнему остается весьма актуальным. Во-первых, с 1 января 2006г. в регионе СЕМЕА (Visa International) вступил в силу перенос ответственности по мошенническим операциям (liability shift). В результате, если ранее для некоторых банков объем диспутных операций, которые можно было бы “отбить”, используя новые правила проведения chargeback, оставался некой размытой величиной, то теперь он должен приобрести достаточно четкие и реальные очертания.

Во-вторых, международные платежные системы продолжают стимулировать своих участников к повышению темпов процесса EMV-миграции, выпуская более совершенные и универсальные версии своих платежных приложений, расширяя функционал карточных продуктов, развивая программы поощрения EMV-миграции, что в совокупности делает микропроцессорные карты все более привлекательным платежным инструментом для банков, уделяющих внимание новым технологиям. Также не следует сбрасывать со счетов имиджевую составляющую. Внедряя новые платежные технологии, банк подтверждает свой имидж инновационной и технологически развитой кредитно-финансовой организации. В итоге банки, каждый из которых руководствуется в этих вопросах своими собственными, внутренними доводами и мотивациями, все чаще принимают решение мигрировать на EMV-карты, переходя от выжидательной позиции, схожей с известной шекспировской дилеммой “To be or not to be”, к чисто “чернышевской” постановке вопроса – “Что делать?” Действительно, перед ними неминуемо встают вопросы: каков план действий по внедрению EMV? Какие шаги следует предпринять? Какой функционал выбрать? Список потенциальных вопросов может включать в себя как технические и процедурные аспекты, так и аспекты развития бизнеса. На часть из этих вопросов призвана ответить настоящая статья.

Проектный подход

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

Суть проектного подхода состоит в максимальной формализации задачи и четком формировании рабочей группы для ее решения. При формализации задачи перед рабочей группой или проектной командой ставится одна или несколько целей, которую банк стремится достигнуть в ходе реализации проекта. Достижение этих целей будет означать его успешное завершение. При этом цели должны быть изложены с максимальной точностью. Например, удачной формализацией задачи проекта можно считать “Выпуск первой 1000 EMVкарт к 01.02.07” или “Получение сертификации в платежной системе на АТМ SMSэквайринг к 20.05.06 и последующий перевод всей банкоматной сети банка на обслуживание EMV-карт в течение 6 месяцев”. Если же перед проектной командой поставить неоднозначную цель (как-то: “Мигрировать на EMV как можно скорее”), то более чем вероятно, что в результате реализации проекта можно получить столь же неоднозначные результаты.

Во главе проектной группы стоит менеджер проекта, который отвечает за координацию работы над проектом и за своевременное выполнение задач. Причем не обязательно, чтобы менеджер проекта был “корифеем карточного бизнеса”, скорее, у него должны быть обширные навыки организации бизнес-процессов. Помимо менеджера проекта в проектную команду рекомендуется включить экспертов в различных областях розничного банковского бизнеса, а также бизнес-аналитика, которые будут отвечать за конкретные задачи в рамках работы над проектом. К работе над проектом следует привлечь и специалистов в области хостовой системы, информационной безопасности и криптографии, маркетинга и т.д. В качестве примера можно привести тот факт, что, например, в документации Visa International перечислено порядка 10 функциональных ролей (roles), которые рекомендуется реализовывать в рамках проектной группы. Для организации эффективной работы проектной команды следует также уделить особое внимание вопросам обмена данными и курирования работы над проектом. Во-первых, члены команды должны находиться в постоянном контакте друг с другом. Безусловно, выделение сотрудников банка на постоянную работу над проектом (даже над таким важным, как EMV-миграция) представляется затруднительным. Поэтому для эффективного обмена информацией между участниками проекта необходимо как минимум проводить еженедельные встречи, на которых будут подводиться итоги по работе над проектом за неделю, планироваться работы на будущее и обсуждаться “горячие” вопросы.

Во-вторых, для эффективной работы над проектом участники рабочей группы должны однозначно понимать, кто является “Заказчиком проекта” (зачастую для его обозначения используется термин “Customer”, хотя проектная терминология, используемая различными компаниями, может отличаться). Именно этот топ-менеджер будет оценивать успешность работы над проектом, выступая арбитром при разрешении споров между участниками команды. По очевидным причинам “заказчиком” должен выступать один из руководителей банка, имеющий по крайней мере четкое представление об основных аспектах в области карточного бизнеса и банковской розницы. После формализации цели проекта следует приступить к разработке детального плана реализации проекта, в котором необходимо принять во внимание совокупность внутрибанковских мероприятий и взаимодействия с внешними организациями и платежными системами. В качестве примера для разработки такого бизнес-плана можно использовать план сертификации, получаемый из офиса платежной системы. В нем в обязательном порядке отражаются основные этапы проекта с точки зрения платежной системы и даты проведения тестов. Хотя такой план и не включает в себя широкий спектр внутренних операций и мероприятий, которые предстоит провести банку в ходе реализации проекта, он дает достаточно полное представление о временных рамках проекта – с момента его открытия в платежной системе и до подтверждения проведения первой EMV-операции или активации BIN. Другими словами, проектный план платежной системы может служить удобным “лекалом” для создания собственного единого плана проекта банка.

Стадии проекта

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

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

Так, почти каждый эмиссионный проект будет включать в себя следующие стадии:

• предварительные работы;

• формирование бизнес-требований к карточному продукту, на базе которых формируется техническое описание;

• выбор поставщика карт;

• управление криптографическими ключами;

• разработка политики риск-менеджмента карты;

• выбор персонализационного бюро или подготовка собственного персонализационного центра;

• подготовка процессинговой системы;

• сертификация карт в платежной системе;

• маркетинговая поддержка;

• пилотный проект;

• завершение проекта: выход на плановые объемы эмиссии EMV-карт и постепенную адаптацию POS-терминальной сети. Подготовка обновлений. Что необходимо учитывать после закрытия проекта (например, регулярные процедуры обновления ключей).

С другой стороны, всем эквайринговым проектам также присущи общие стадии:

• предварительные работы;

• формирование требований;

• выбор поставщика терминального ПО и модернизация оборудования;

• управление криптографическими ключами;

• разработка политики риск-менеджмента терминала;

• подготовка процессинговой системы;

• сертификация в платежной системе;

• маркетинговая поддержка – работа с торгово-сервисными предприятиями;

• проведение обучения сотрудников банка и торгово-сервисных предприятий;

• пилотный проект;

• завершение проекта: адаптация к приему EMV-карт необходимого количества терминальных устройств или всей эквайринговой сети банка. Также необходимо учесть постпроектный этап – обновление ключей, процедуры работы с новым ПО и т.п.

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

Так, например, при сертификации на эквайринг в Visa International банк должен пройти end-to-end-тестирование, подтверждающее возможность корректной отправки чиповых транзакционных данных с хоста банка в тестовую среду Visa, а также ADVT-тестирование (Acquirer Device Validation Tool), подтверждающее возможность работы терминала с различными профилями EMV-карт. Что касается тестовых возможностей, то международные платежные системы с готовностью снабжают банки объемным пакетом тестовых инструментов, начиная с тестовых карт и заканчивая системами подготовки персонализационных данных. Причем зачастую для получения доступа к этим ресурсам достаточно направить соответствующий запрос менеджеру проекта со стороны платежной системы. Главное – не “заиграться” с тестовыми инструментами и помнить о том, что работа в “боевом” режиме в любом случае имеет свои особенности, которые необходимо изначально принимать во внимание.

Безусловно, банк должен отдельно проходить сертификационные мероприятия для АТМ- и мерчант-эквайринга, а также для операций Manual Cash (снятие наличных в кассах отделений банка при помощи POS-терминала). End-to-end-тестирование может проходить по упрощенной (confort) или полной схеме. Упрощенная схема актуальна прежде всего для тех случаев, когда банк пользуется услугами стороннего процессингового центра, который уже сертифицирован платежной системой на обслуживание EMV-карт. При этом все эти мероприятия призваны гарантировать полную готовность банка к обслуживанию смарткарточных продуктов.

Для сравнения: при сертификации на эмиссию EMV-карт в той же платежной системе банк должен провести аналог end-to-end-тестирования, подтверждающий готовность хоста банка к обработке авторизационных запросов, содержащих чиповые данные, и выслать EMV-карту на сертификацию в офис платежной системы, где производится проверка корректности персонализации карты. Следует отметить, что при этом российские банкиучастники Visa International находятся в заведомо более выгодном положении, т. к. в московском офисе платежной системы работает команда специалистов, которая самостоятельно производит сертификацию карт без привлечения регионального лондонского офиса, что очевидно экономит время реализации проекта.

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

Что касается сроков реализации EMVпроекта, то этот показатель в значительной мере зависит прежде всего от текущего состояния процессинговой системы и терминальной сети банка. Например, закупка, инсталляция и тестирование обновления хостовой системы могут занять несколько месяцев. То же самое можно сказать и о терминальном ПО, хотя зачастую банк может получить у производителя поддержку в этом вопросе вплоть до подготовки терминальной платформы для тестирования и загрузки тестовых сертификатов платежной системы силами сервисной службы компании-поставщика. Однако существуют минимальные временные рамки реализации EMV-проекта, которые устанавливаются сроками прохождения обязательных сертификационных процедур платежных систем (более подробно мы вернемся к этому вопросу чуть позже). Например, сертификация публичных эмитентских ключей (Public Issuer Keys) в Visa Certification Authority занимает порядка 1,5 месяца.

Для предварительной оценки срока реализации проекта опять же крайне полезно взглянуть на сертификационный план платежной системы, который наглядно продемонстрирует минимальные сроки сертификации и прохождения банком сертификационных процедур. Исходя из практики и опыта российских банков, средний срок реализации проекта, включающего сертификацию на эмиссию и эквайринг EMV-карт в одной платежной системе, составляет порядка 1,5 года. Эффективное планирование и использование услуг аутсорсинговых компаний (сторонних персонализационных и процессинговых центров) может сократить этот срок, и наоборот.

Бизнес-требования как краеугольный камень

При формализации требований важно соблюдать порядок: бизнес-требования являются базисом для технического описания, а отнюдь не наоборот. Необходимо понимать, что переход на EMV может в значительной степени сузить или расширить функционал карт как платежного инструмента. Например, EMV-карта может самостоятельно осуществлять риск-мониторинг транзакций, принимать решение об их проведении в off-line или on-line, обновлять офлайновые счетчики и т.д. Это справедливо и для терминального оборудования. Поэтому на стадии формирования требований каждое из бизнес-подразделений банка должно однозначно определиться, какой именно карточный продукт оно желает увидеть на выходе. В конце концов именно этим специалистам придется продавать созданную услугу, зарабатывать прибыль и тем самым окупать затраты на внедрение этого продукта. Справедливо будет также отметить, что представители бизнес-подразделений редко имеют полное представление о потенциальной функциональности смарт-карт и их возможностях для развития бизнеса. Именно для формирования требований в проектную команду необходимо включить и представителей бизнес-подразделений, и “карточников”, которые в той или иной мере обладают компетенцией и знаниями в области функциональности EMV-карт.

EMV-транзакция: 12 этапов

Итак, определившись с основными аспектами планирования EMV-проекта, перейдем к рассмотрению его технологических составляющих, начав с такого определяющего момента, как особенности EMV-транзакции. Прежде всего следует поэтапно рассмотреть прохождение обычной операции по EMV-карте в POS-терминале, адаптированном для приема чиповых карт. Это позволит, во-первых, получить более детальное представление о тех процедурах и информационном обмене, который происходит между картой, терминальным оборудованием и процессинговой системой, и во-вторых, сформировать необходимый базис для последующего анализа, пожалуй, наиболее сложного аспекта EMV-миграции – построения процедуры управления ключевым материалом. Кроме того, акцентирование внимания на технологии проведения операций с чиповыми картами как таковой позволяет внести ясность в такой важный вопрос, как потенциал смарт-карты с точки зрения расширения ее функционала по сравнению с традиционными картами, использующими технологию магнитной полосы. Говоря о дополнительной функциональности чиповых карт, в большинстве случаев имеют в виду прежде всего различные дополнительные приложения, которые можно разместить в памяти ее микропроцессора помимо основного платежного апплета. Однако не следует забывать, что благодаря самому стандарту EMV в любую EMVкарту с минимальными конфигурациями изначально заложен широкий функциональный потенциал, который задействуется при проведении каждой операции.

При описании EMV-транзакции в рамках данной статьи будут использоваться доступные официальные документы EMVCo, с которыми можно подробно ознакомиться на сайте этой организации (www.emvco. com), а также соответствующая открытая документация Visa International. Следует отметить, что документация EMVCo служит набором общих рекомендаций и правил. На их базе создавались частные правила в области чиповых карт Visa International и MasterCard International, которые носят общие наименования VIS (Visa Integrative Circuit Card) и M/Chip, соответственно. Этим объясняется тот факт, что между EMV-правилами этих международных платежных систем так мало принципиальных различий. Итак, несмотря на то что для пользователя карты операция по ней занимает считаные секунды (хотя, конечно, наблюдательный пользователь легко заметит увеличение времени операции на пару секунд в случае использования смарт-карты), стандартная EMV-транзакция имеет следующие 12 этапов:

1. Выбор приложения;

2. Инициализация обработки приложения;

3. Считывание данных приложения;

4.Офлайновая аутентификация;

5. Обработка ограничений;

6. Проверка держателя карты;

7. Риск-менеджмент на стороне терминала;

8. Анализ действий терминала;

9. Риск-менеджмент на стороне карты;

10. Анализ действий карты;

11. Процессинг в режиме on-line (этот этап имеет место только в случае, если операцию по каким-то причинам не удалось провести в офлайновом режиме);

12. Завершение операции. Разберем каждый из перечисленных этапов и детально рассмотрим его наиболее важные моменты.

1. Выбор приложения

Как следует из определения, на этом этапе карта и терминал (POS-терминал, ATM, платежно-информационный терминал и т.п.) совместно выбирают приложение, по которому будет проведена операция. В установках терминала существует список карточных приложений, с которыми он может работать. Помимо базовых приложений Visa International и MasterCard International – VSDC и M/Chip – в нем могут присутствовать также и другие апплеты, такие как, например, программы лояльности, бонусные или идентификационные приложения. В специальной области памяти карты размещен список всех приложений, которые на нее загружены.

Здесь следует отметить, что всем EMVкартам присуща общая структура хранения информации. Например, список приложений должен храниться в определенной области файловой структуры карты. Это обеспечивает возможность использования карт в любом терминале, соответствующем требованиям EMV. Для выбора приложения используются так называемые Идентификационные коды приложения (Application Identifier – AID). Любое приложение, записываемое в память EMV-карты, должно получить специальный идентификационный номер ISO. Даже если тот или иной банк захочет выпустить собственное приложение, доступное только для его клиентов, ему все равно придется пройти процедуру получения AID. AID записываются в память карты на этапе персонализации и устанавливаются в POS-терминалах. AID состоит из двух элементов:

• Зарегистрированного идентификационного кода приложения (Registered application identifier – RID), который соответствует конкретной платежной системе или, например, организации-эмитенту локального приложения;

• Кода продукта (Product Identifier Extension – PIX), который соответствует типу карточного продукта.

Например, картам Visa International присвоен RID A000000003, а также два кода PIX: –”2010” – для карт Visa Electron, и “1010” – для всех остальных карточных продуктов платежной системы. Таким образом, AID карты Visa Classic будет выглядеть следующим образом: A0000000031010. Когда EMV-карта помещается в терминал, происходит сверка AID в памяти карты и в памяти устройства. Так происходит выбор приложения для проведения операции.

Если карта и терминал содержат несколько общих приложений (например, VSDC и приложение лояльности Petrol Check), то терминал отобразит на экране список всех общих приложений и предложит держателю карты выбрать приложение, по которому будет проходить транзакция (см. рис. 1). В то же время при планировании EMVпроекта специалисту банка, ответственному за развитие POS-терминальной сети, следует взять на заметку, что не все POS-терминалы поддерживают опцию выбора приложения. В этом случае для проведения операции будет выбрано приложение с наибольшим приоритетом (Application Priority Indicator – API), который устанавливается эмитентом при персонализации карты. Обычно эмитент выбирает в этом качестве платежное приложение, которому по умолчанию отдается наибольший приоритет.

И, наконец, если карта и терминал не имеют общих приложений, то операция будет автоматически отменена терминалом, а карта – возвращена клиенту.

2. Инициализация обработки приложения

На этом этапе терминал сообщает карте о том, что он готов начать транзакцию. В ответ на это карта должна осуществить следующие две операции.

• Проверка так называемых географических ограничений на проведение операции. Карта проверяет регион, в котором происходит операция, запрашивая соответствующие данные у терминала (Terminal Country Code). Далее карта сравнивает полученные данные с информацией, записанной в свою память (Card Country Code). Эта операция позволяет эмитенту застраховаться от использования своих карт в определенных регионах мира (например, с наиболее высокими показателями мошенничества). Кроме того, банк может ограничить использование эмитированной им в рамках международной платежной системы карты только внутри страны (локальные карточные продукты), как, например, в случае с некоторыми картами MasterCard Electronic, или ограничить проведение по ней определенных операций в данной стране (например, разрешить карте осуществлять только операции по снятию наличных). Очевидно, платежные системы внедрили данную операцию для того, чтобы предоставить эмитентам возможность применять существующие онлайновые методы риск-менеджмента (отказ от авторизации операций, инициированных в определенном регионе мира) при проведении офлайновых операций. На этом этапе транзакция может быть отменена по инициативе карты, если данный тип операции запрещен в данной стране мира. Эта операция является опциональной, и эмитент может отказаться от ее проведения путем использования специальных установок при персонализации карты.

• Карта отсылает терминалу Профиль взаимообмена приложения (Application Interchange profile – AIP). Эта операция является обязательной для всех EMV-приложений. Карта передает терминалу набор специально структурированной информации, содержащей описание функциональности карты и приложения, которое было выбрано для проведения операции. Эти данные форматированы в отображение TVL (Tag, Value, Length). Следует отметить, что при всей кажущейся открытости обмена данными между картой и терминалом существует информация, которая никогда не передается картой на терминал. Это прежде всего значение ПИН-кода и секретные ключи, записанные в специальную область памяти чипа карты.

3. Считывание данных приложения

На этом этапе карта передает терминалу данные, необходимые для проведения транзакции (используя данные AIP), и информацию, применяемую на этапе офлайновой аутентификации.

4.Офлайновая аутентификация

На основании AIP терминал определяет типы офлайновой аутентификации, которые поддерживает карта. Как известно, существует три типа офлайновой аутентификации – статичная (Static Data Authentication – SDA), динамическая (Dynamic Data Authentication – DDA) и комбинированная (Combined Data Authentication – CDA). В настоящий момент на мировом рынке продолжают превалировать SDA-карты, однако все больше банков начинают отдавать предпочтение DDA как более безопасной технологии аутентификации. В свою очередь, CDA, совмещающая в себе свойства DDA и SDA, при всех своих преимуществах сегодня пока еще является крайне редкой технологией аутентификации. Следует отметить, что не все терминалы поддерживают использование DDA. Связано это с тем, что криптографические операции, выполняемые в ходе процедуры DDA, требуют от терминала дополнительных процессинговых мощностей, которыми не обладают устаревшие модели. Именно поэтому использование SDA по-прежнему является обязательным для эмитентов EMV-карт. Таким образом, даже если банк намерен выпускать карты с более безопасной DDA-технологией, ему придется также обеспечить поддержку картой SDA. Все перечисленные методы аутентификации работают в офлайновом режиме без обращения к хосту банка эмитента или эквайера и основываются на технологии асимметричных ключей.

Подробнее к особенностям SDA и DDA мы еще вернемся в отдельной статье в одном из следующих номеров журнала “ПЛАС”, посвященной вопросам управления ключевым материалом. Сейчас же остановимся на рассмотрении общих аспектов процедуры аутентификации. И в SDA, и в DDA применяются Сертифицированные публичные ключи платежной системы (Payment System Certificate), загруженные в терминальное устройство (так называемая EMV-библиотека), а также публичные криптографические ключи, записанные на карту (в случае с SDA) или сгенерированные картой специально для каждой операции (в случае с DDA). В результате проведения офлайновой аутентификации эквайер должен удостовериться в принадлежности карты определенному эмитенту и в том, что данные на карте не были изменены после ее персонализации. Недостаток SDA состоит в том, что карта использует одну и ту же криптографическую величину для проведения аутентификации на протяжении всего срока жизни карты. По сути, SDA мало чем отличается от технологии CVV (Card Verification Value), используемой на картах с магнитной полосой. Напротив, DDA-карты генерируют уникальную криптографическую величину для каждой операции, используют уникальный для каждой карты 3DES-ключ, хранящийся в защищенной области ее памяти.

По результатам проведения аутентификации терминал записывает ее результат (Terminal Verification Result – TVR) в специальный отчет. Таким образом, неудачное завершение офлайновой аутентификации не означает завершение транзакции. Также следует отметить, что для терминалов, которые поддерживают постоянную онлайновую связь с хостом банка (например, АТМ), не требуется проведение офлайновой аутентификации. Если авторизация в любом случае будет происходить в онлайновом режиме, то смысл офлайновой авторизации просто отпадает.

5. Обработка ограничений

На этом этапе терминал проводит ряд проверок карты, удостоверяющих ее пригодность для совершения операции. В частности, терминал проверяет срок действия карты, возможность использования карты для совершения данного вида операции, а также версию приложения. Для проверки срока действия карты используется специальный параметр, хранящийся в памяти карты, – Срок действия приложения (Application Expiration Date). В некоторых случаях эмитент может задать дополнительный параметр жизненного срока приложения – Application Effective Date. Последний параметр является опциальным и может отличаться от Application Expiration Date. Например, эмитент может предоставить своему клиенту возможность использовать карту в период ее перевыпуска в связи с истечением срока ее действия. В этом случае период Application Effective Date будет продолжительнее, чем Application Expiration Date. Также терминал проводит проверку версии приложения. В памяти карты и каждого терминала записаны версии поддерживаемых ими приложений. Терминал сверяет данные о приложении, записанном в память карты, со своими данными. Результаты операций, проводимых на данном этапе, также записываются в отчет TVR. По результатам Обработки ограничений транзакция не может быть отменена, даже в случае, если, например, срок действия приложения истек.

6. Проверка держателя карты

Этот этап представляет собой привычную стадию удостоверения личности держателя карты. Исторически наибольшую популярность и распространение получили два метода удостоверения личности держателя карты (Cardholder verification method – CVM) – сверка подписи на карте и на терминальном чеке, а также ввод ПИН-кода. В некоторых странах получили распространение другие методы CVM, например, проверка ПИН-кода в офлайновом режиме при проведении операций в POS-терминалах. Поэтому большинство EMV-карт поддерживают несколько методов CVM, а значит, терминалу и карте вновь придется выбирать подходящий вариант. Принцип выбора CVM аналогичен выбору приложения. В памяти EMV-карты хранится список CVM, заданный эмитентом карты на этапе ее персонализации. Этот список передается терминалу на данном этапе проведения операции. Терминал сравнивает его со своим списком, заданным эквайером, исходя из собственной политики риск-менеджмента. Также эмитент должен установить приоритеты для каждого метода CVM, для того чтобы терминал мог автоматически выбрать оптимальный вариант при совпадении нескольких методов в списках карты и терминала (см. рис. 2).

Если в результате сравнения списков CVM предпочтение было отдано проверке ПИН-кода, то терминал автоматически предложит владельцу карты ввести ПИН-код. Следует отметить, что существует три разновидности проверки ПИН-кода для EMV-карт:

• в режиме on-line (аналогично картам с магнитной полосой);

• в режиме off-line, когда на карте ПИНкод хранится в открытом (незашифрованном) виде – Offline plaintext PIN. В этом случае после ввода ПИН-кода его значение передается карте для сравнения со значением ПИН, хранящимся в защищенной области карты в незашифрованном виде;

• в режиме off-line, когда на карте ПИНкод хранится в закрытом (незашифрованном) виде – Offline enciphered PIN. В этом случае для проведения проверки переданного значения ПИН-кода карта должна произвести манипуляции с зашифрованными данными. Если углубиться в анализ спецификаций EMV, то обнаруживается, что в списке CVM также можно задать и условия, при которых становится доступным использование определенных методов CVM (например, предпочтительное введение ПИН-кода для операций по снятию наличных), а также задать действия терминала в случае неудачной проверки владельца карты (терминал может попробовать провести операцию с другим CVM и т. д.). Другими словами, у эмитента и эквайера существует большее количество инструментов по настройке проверки личности покупателя в офлайновом режиме.

7.Риск-менеджмент на стороне терминала

На этом этапе терминал проводит внутреннюю проверку параметров транзакции, исходя из установок риск-менеджмента банка-эквайера. Терминал проводит следующие тесты:

• Терминал может выбрать транзакцию для ее проведения в онлайновом режиме. В установках терминала, способного принимать EMV-карты, может быть задан случайный алгоритм выбора транзакций для проведения их в онлайновом режиме. Как нетрудно догадаться, это является дополнительным способом борьбы с карточными мошенниками, рассчитывающими на то, что операция будет проведена без обращения к хосту банка эмитента. Произвольный характер выбора операции для отправки в on-line не позволяет мошенникам заранее подготовиться к такому решению терминала.

• Проверка hot-list (списка украденных или потерянных карт). Эта проверка аналогична подобному шагу при проведении операции с картой с магнитной полосой. В ходе этой проверки терминал сверяет номер карты с записями в списке “проблемных” карт. Большинство терминалов поддерживают работу с несколькими hotlist одновременно (например, с бюллетенями различных платежных систем).

• Проверка на превышения лимита операции. Эта операция также аналогична проверке floor-limit при использовании “магнитной” карты.

Важно помнить, что операция не может быть отменена из-за того, что она по каким-то причинам не прошла проверку на этом этапе. Результаты проверок записываются в TVR.

8. Анализ действий терминала

На этом этапе терминал анализирует результаты предыдущих шагов транзакции, записанных в TVR, а также параметры проведения операции, установленные эмитентом в специальных полях памяти чипа, и эквайером – в настройках терминала. По результатам анализа терминал принимает решение о том, следует ли провести операцию в режиме on-line, разрешить ее проведение в офлайновом режиме (off-line) или отклонить (отменить) операцию (decline). В частности, на этом этапе терминал производит следующие действия:

• проводит анализ результатов офлайновой обработки транзакции, которые были произведены до настоящего момента. В памяти терминала и карты существует специальный список, в котором прописаны возможные действия по проведению операции, исходя из результатов, записанных в TVR. Эти списки носят название Terminal Action Codes (TAC) и Issuer Action Codes (IAC) – для терминала и для карты, соответственно. Анализируя TVR и принимая во внимание TAC и IAC, терминал принимает решение о дальнейшей судьбе транзакции;

• далее терминал направляет свое решение карте, запрашивая у нее специальную криптограмму. Другими словами, терминал как бы спрашивает карту: “Я проанализировал параметры операции и думаю, что нам надо провести ее в режиме online. Каково твое мнение?” В ответ на этот запрос карта должна представить терминалу “свое видение” дальнейшего проведения операции.

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

9. Риск-менеджмент на стороне карты

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

• Проверка вновь выпущенной карты (New Card Check). Эмитент имеет возможность установить параметры рискменеджмента карты таким образом, что при проведении первой в своем жизненном цикле операции карта обязательно должна обратиться к хосту банка (т. е. провести операцию в режиме on-line). Это позволяет эмитенту зафиксировать факт начала использования карты ее держателем.

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

• Проверка счетчиков (counters). Карта проверяет состояние различных офлайновых счетчиков, заданных эмитентом. Среди таких счетчиков могут присутствовать: допустимое количество офлайновых операций, максимальная сумма офлайновых операций, количество попыток ввода ПИН-кода и т. д.

10. Анализ действий карты

На этом этапе карта завершает проведение процедур риск-менеджмента и формирует ответную криптограмму терминалу. Другими словами, карта “высказывает свое мнение” о предложении терминала провести операцию в онлайновом режиме. Существует три типа ответных криптограмм (по спецификации VIS):

• Transaction Certificat (TC) – проведение операции в режиме off-line. Представляет собой клиринговое сообщение на проведение расчета (settlement), которое может быть использовано для проведения chargeback. Оно содержит все основные результаты офлайнового проведения операции – TVR и Отчет о проверке личности владельца карты (Cardholder verification results – CVR). TC также генерируется картой в ответ на положительный ответ хоста банка при проведении операции в онлайновом режиме. В этом случае TC представляет терминалу окончательные данные об операции для их дальнейшего использования при разборе спорных транзакций.

• Application Authentication Cryptogram (AAC) – отмена операции в офлайновом режиме. Генерируется в случае “согласия” карты на отмену операции или в случае отрицательного ответа хоста банка. • Authorisation request cryptogram (ARQC) – запрос на проведение операции в онлайновом режиме. Пересылается на хост банка в виде стандартного авторизационного сообщения (например, для VisaNet – сообщения “0100” или “0200”). Для простоты понимания диалог между картой и терминалом можно представить в следующей таблице (см. рис. 3). В результате формирования той или иной криптограммы решается дальнейшая судьба операции – она может быть отменена, отправлена для авторизации на хост банка или проведена в офлайновом режиме. В случае отмены или подтверждения в off-line транзакционный процесс автоматически переходит на 12-й этап, который мы рассмотрим в порядке очередности.

11. Процессинг в режиме on-line

Если карта и терминал пришли к обоюдному решению отправить операцию на обработку в процессинг банка-эмитента, то карта формирует криптограмму ARQC, а терминал пересылает ее в авторизационном сообщении вместе с данными операции. В настоящий момент Visa International и MasterCard International пришли к соглашению использовать единый формат отправки чиповых данных на процессинговую обработку. Транзакционные данные, специфичные для EMV, пересылаются в “3 bit map” стандартного авторизационного сообщения (специальная область сообщения на авторизацию операции).

После получения криптограммы хост банка обрабатывает ее, используя специальный набор ключей (MDK). Далее банк может провести несколько операций:

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

• проверить результаты офлайнового проведения операции (офлайновой аутентификации, проверки ПИН-кода и т. п.);

• сформировать ответную криптограмму хоста Authorisation response cryptogram (ARPC), что позволит карте проверить личность эмитента и удостовериться, что ответ на авторизацию пришел действительно от банковского хоста;

• сформировать скрипт на обновление офлайновых счетчиков или на выполнение картой другой команды – вплоть до автоматической блокировки приложения. В результате анализа полученных данных хост эмитента формирует стандартный авторизационный ответ, содержащий необходимый набор чиповых данных.

12. Завершение операции

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

• Если операция была проведена в офлайновом режиме, то карта формирует криптограмму TC и направляет ее терминалу. Терминал, в свою очередь, направляет стандартное сообщение на хост банка-эквайера. Операция считается успешно выполненной.

• Если транзакция была отменена в офлайновом режиме, то данные о ней в виде AAC направляются эмитенту.

• Если операция была направлена в онлайновую обработку, то при получении ответа от хоста банка эмитента терминал передает необходимые данные (ARPC или скрипт) карте. После этого карта подтверждает корректность ARPC при помощи своих криптографических ключей (UDK), обрабатывает скрипт-команду и формирует соответствующую криптограмму – TC в случае получения положительного ответа от хоста, и AAC – в случае отрицательного. Соответственно, транзакция считается успешно завершенной или отмененной.


Читайте продолжение в одном из ближайших номеров “ПЛАС”. Во второй части материала “EMV-проект: step-by-step”: вопросы управления криптографическими ключами в эмиссионном и эквайринговом EMV-проекте; “подводные камни” EMV-проекта.


Комментарии (0):

Добавлять комментарии могут только зарегистрированные Пользователи


Читайте в этом номере:
обновить

а вы знаете, что...

… предоплаченные платежные карты возникли как платежный инструмент в середине 1990-х гг., и первыми из них были карты Electronic Benefits Transfer (EBT) в США, на которые заменили ранее выдаваемые нуждающимся бумажные продовольственные сертификаты?