В данной статье будут рассмотрены различные аспекты безопасности технологии виртуальных карт (e-card), созданной специально для ведения расчетов через сеть. Идея виртуальной карты (е-card) основана на том, что во время проведения CNP-транзакции (CPN-Cardholder Not Present операция покупки по пластиковой карте, в момент совершения которой клиент лично не присутствует лично в торговой точке, а сообщает ей реквизиты своей карты, необходимые для проведения авторизации) пластиковая карта как физический объект не применяется. Используются лишь реквизиты карты, и совсем необязательно, чтобы они были нанесены на пластик. Поэтому можно выделить отдельные предназначенные специально для электронной коммерции номера карт с сопутствующими им реквизитами и «привязать» к таким виртуальным картам счета с небольшим остатком. В этом случае клиент будет застрахован от крупных потерь, связанных с риском мошенничества.

Таким образом, смысл виртуальной карты заключается в том, чтобы психологически «раскрепостить» клиента при совершении электронных покупок. Действительно, карта, которой пользуется покупатель, связана с небольшим по размеру счетом, и потому весь риск покупателя ограничен потерей средств на этом счете.

Гута Банк стал первым российским банком, который приступил к эмиссии виртуальных карт платежной системы VISA, получивших название VISA E-c@rd и специально предназначенных для осуществления платежей в Интернете. Проект был запущен летом 2000 г. после того, как компания VISA International завершила сертификацию VISA E-c@rd и официально санкционировала их эмиссию Гута Банком.

Карты VISA E-c@rd предназначены для оплаты через Интернет любых видов товаров и услуг в любых электронных магазинах во всем мире, в том числе для оплаты услуг операторов сотовой связи, Интернет-провайдеров, туристических компаний, предприятий гостиничного бизнеса и т. д. Для проведения других операций (расчетов в обычной торговой сети, получения наличных денежных средств) карта VISA E-c@rd не предназначена.

Использование виртуальной карты удобно для клиента в случае, когда банк-эмитент дополнительно предоставляет ему услуги Интернет-банкинга для управления своими счетами. В этом случае клиент в удаленном режиме при помощи только персонального компьютера, подключенного к Интернету, может в режиме реального времени перевести средства со своего «главного» счета на счет, связанный с виртуальной картой, в количестве, необходимом для совершения намеченных электронных покупок.


Требования к виртуальным картам состоят в следующем:

— виртуальная карта должна иметь номер (система MasterCard требует, чтобы номер карты состоял из 16 цифр) и срок действия;

— система MasterCard требует, чтобы с виртуальной картой была связана величина CVC2 (VISA оставляет вопрос использования величины CVV2 для виртуальной карты на решение эмитента карты);

— к виртуальным картам применяются те же правила, что и к обычным картам, за исключением правил, которые связаны с физическими характеристиками карт;

— эмитенты должны понятным для клиента образом передать ему номер карты, ее срок действия и т. п., а также способ ее использования;

— эмитенты должны утвердить выпуск виртуальных карт в соответствующих департаментах сертификации карт международных платежных систем;

— эмитент должен ясно объяснить владельцу виртуальной карты, что она не может использоваться в режиме Dual Mode, когда авторизация производится по виртуальной карте, а презентмент сформирован по обычной карте, привязанной к тому же счету, что и виртуальная карта.

Для того чтобы передать клиенту реквизиты виртуальной карты, эмитент может использовать некоторый физический носитель информации о реквизитах карты (Reference Device RD). RD по своим физическим характеристикам должен явным образом отличаться от обычной карты. В частности, RD не должен иметь тех же размеров и пропорций, что и обычная карта, содержать голограмм платежных систем, а также магнитной полосы и чипа.

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

Другое важное требование международных платежных систем заключается в том, что виртуальная карта может быть выдана:

— владельцу «физической» карты;

— клиенту, не имеющему «физической» карты платежной системы, но имеющему возможность получить ее по его первому требованию.

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

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

Виртуальные номера карт

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

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

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

Например, система MasterCard к обязательным параметрам относит номер карты, срок ее действия, имя магазина (Merchant Name), идентификатор магазина (Merchant ID), сумму транзакции и валюту транзакции. Эмитент определяет реальный номер карты, выполняя обратное преобразование, проводит с его использованием авторизацию транзакции и результат возвращает в платежную сеть, предварительно вновь подставив в авторизационный ответ виртуальный номер карты.

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

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

В то же время, идея виртуальных номеров карт имеет и ряд недостатков.


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

Во-вторых, эмитент должен предложить клиенту процедуру его аутентификации во время обращения клиента за виртуальным номером в систему эмитента. Как правило, используется система паролей — клиент в защищенной сессии с системой эмитента сообщает последней свой идентификатор и кодовое слово (пароль). Здесь существуют несколько подходов к решению задачи. Наиболее надежным является получение клиентом своих идентификатора и пароля непосредственно в банке (в крайнем случае письмом из банка, причем идентификаторы клиента должны распечатываться в PIN-конверте для того, чтобы сделать информацию закрытой для банковского персонала).
Этот подход является неудобным для клиента. Поэтому на практике находит применение другой, менее надежный метод. Клиент получает свои идентификаторы во время первой сессии с системой эмитента. Он идентифицирует себя, представляя эмитенту реквизиты карты, а также дополнительную информацию, запрашиваемую эмитентом (например, номер паспорта, девичью фамилию матери и т. п.). В ответ в случае положительного результата аутентификации клиент получает свой идентификатор и пароль. Весь обмен информацией между клиентом и системой эмитента происходит в защищенной сессии. Логическое соединение с системой эмитента обеспечивается кошельком клиента. Более низкая защищенность этого метода связана с тем, что в процессе идентификации клиента могут быть различные подставки со стороны мошенников, имитирующих работу эмитента.

В-третьих, помимо виртуального номера карты система эмитента в некоторых случаях должна в режиме реального времени генерировать значения CVC2/CVV2.

Конечно, эмитент, применяющий технологию виртуальных номеров карт, может и не проверять значения CVC2. В этом случае в платежную сеть может направляться любое случайное значение CVC2. Однако при таком подходе эмитент лишается возможности использовать резервную авторизацию (авторизацию Stand-In), предоставляемую в его распоряжение многими платежными системами на случай отказа в работе системы эмитента. В режиме резервной авторизации платежная сеть от лица эмитента в соответствии с параметрами, установленными эмитентом, производит авторизацию транзакции. В системе резервной авторизации существует общий параметр для всех префиксов карт, определяющий действие эмитента на случай неверного значения CVC2/CVV2 отклонить транзакцию сразу или продолжить другие проверки. Если такой параметр установить равным значению, означающему «не отклонять», то и по всем другим операциям и префиксам будет приниматься то же решение, что наверняка противоречит интересам эмитента.

В-четвертых, применение технологии виртуальных номеров карт повлечет за собой проблемы для тех Интернет-магазинов, которые сохраняют номера карт клиентов, уже однажды обращавшихся в торговое предприятие за услугами, чтобы не заставлять клиента набирать свои реквизиты при следующих обращениях в торговую точку. Очевидно, что при массовом применении технологии виртуальных номеров карт БД таких магазинов быстро переполнятся, что повлечет за собой операционные проблемы в их функционировании.

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

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

Требования к технологии виртуальных номеров карт при использовании например карт Maestro состоят в следующем. Эмитент должен генерировать 16-цифровые номера карт (при этом виртуальный номер карты может совпадать с реальным номером карты), а также проверять соответствие между данными, сгенерированными при инициализации транзакции, и данными авторизационного запроса. Как указывалось ранее, соответствие ищется как минимум по номеру карты, сроку ее действия, имени магазина (Merchant Name), идентификатору магазина (Merchant ID), сумме транзакции и валюте транзакции.

Отличительная особенность решения для карт Maestro заключается в том, что владелец карты не должен устанавливать на своем компьютере никакого специального ПО (электронного бумажника). Транзакция выполняется следующим образом. После того как владелец карты сообщил торговой точке о готовности платить с использованием карты Maestro, Интернет-магазин отправляет на сервер эмитента (e-Wallet в терминах Maestro), хранящий информацию о реквизитах своих карт, специальное сообщение. Это сообщение содержит информацию о торговой точке (Merchant Name, Merchant ID), о сумме и валюте покупки, идентификатор транзакции в системе торговой точки и т. п. Одновременно сервер магазина переключает владельца карты на сервер эмитента.

Сервер эмитента устанавливает с владельцем карты защищенное соединение и направляет клиенту форму для проведения его аутентификации. Например, эмитент может запросить у владельца карты ранее предоставленные ему идентификатор и пароль. После того как владелец карты аутентифицирован сервером эмитента, последний формирует запрос на сервер торговой точки, содержащий сгенерированный эмитентом виртуальный номер карты.

По решению Maestro имеется несколько вопросов, ответы на которые явно не следуют из официального описания схемы.

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

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

Распределение ответственности при возникновении диспута по транзакции ничем не отличается от того, каким образом оно производится при использовании модели трех доменов.