Модель 3d secure
Протокол 3D Secure базируется на концепции трех доменов. Общая схема протокола представлена на рисунке.
После того, как владелец карты подтвердил торговому предприятию свою готовность произвести покупку и в защищенной SSL-сессии передал ТП реквизиты карты, приложение ТП инициирует специальное программное обеспечение, устанавливаемое на сервере ТП и называемое Merchant Plug-In.
Программа Merchant Plug-In обращается к серверу платежной системы (Directory) с запросом на проверку поддержки владельцем карты протокола 3D Secure. Данный запрос содержит номер карты, идентификатор торговой точки и ее пароль (опционно). Сервер Directory по идентификатору торговой точки проверяет наличие данного ТП в БД интернет-магазинов, поддерживающих протокол 3D Secure. Кроме того, в случае использования пароля ТП проводится идентификация ТП. После этого сервер Directory по номеру карты покупателя определяет ее принадлежность к диапазону карт, поддерживающих протокол 3D Secure, а также URL сервера эмитента карты, называемого Access Control Server (ACS), и передает по этому URL запрос на поддержку данной конкретной картой протокола 3D Secure. Сервер ACS проверяет поддержку владельцем карты протокола 3D Secure и результат проверки через Directory сообщает программе Merchant Plug-In.
Следует отметить, что диалоги Merchant Plug-In — Directory и Directory ACS происходят по защищенным SSL-сессиям с использованием SSLсертификатов, выданных Root Certificate Authority, что обеспечивает не только конфиденциальность передаваемых данных, но и что крайне важно- взаимную аутентификацию участников диалогов.
Если в результате проверки на ACS карта покупателя поддерживает протокол 3D Secure, то Merchant Plug-In формирует запрос на аутентификацию владельца карты. Данный запрос содержит информацию о сумме покупки, торговом предприятии, специальный идентификатор владельца карты (Account ID), поддерживаемый на сервере ACS, URL ТП и передается на сервер ACS, через браузер покупателя с одновременной переадресацией владельца карты на сервер ACS.
Сервер ACS, получив запрос, производит аутентификацию владельца карты по установленному с клиентом защищенному SSL-соединению. За банком-эмитентом остается свобода выбора метода аутентификации. В частности, владелец карты может однажды получить от эмитента пароль. В этом случае проверка выглядит следующим образом. Сервер ACS подготавливает для покупателя страничку, содержащую логотип банка-эмитента, название ТП, сумму транзакции, специальные позывные (по сути — тот же пароль, но в легко запоминаемой форме), придуманные владельцем карты на стадии его регистрации для участия в программе ЭК банка и хранимые на ACS, а также запрос к покупателю на ввод секретного пароля владельца карты. С помощью позывных сервер ACS идентифицирует себя перед владельцем карты. В ответ владелец карты сообщает серверу ACS свой пароль, идентифицируя себя перед эмитентом.
После успешного завершения аутентификации клиента, сервер ACS подготавливает ответ, подписанный на ключе эмитента. Подпись эмитента используется для решения проблемы потенциального отказа владельца карты от результатов транзакции. Ответ передается на сервер обслуживающего банка с одновременным переключением клиента на этот же сервер. Результат аутентификации передается ACS также на сервер Directory, который выступает в роли третейского судьи в случае возникновения диспута по транзакции. Merchant Plug-In проверяет подпись эмитента и формирует стандартный авторизационный запрос для передачи его в платежную сеть.
Таким образом, протокол 3D Secure удовлетворяет основным требованиям безопасности, предъявляемым к ЭК. В частности, решается проблема аутентификации участников транзакции, отказа от транзакции и т. п. И в то же время говорить о протоколе 3D Secure как об устойчивом протоколе невозможно, поскольку он определяет только часть процесса обработки транзакции (Interoperability Domain), оставляя протоколы в зонах Issuer Domain и Acquirer Domain на выбор соответственно эмитента и обслуживающего банка. У протокола 3D Secure имеются следующие очевидные достоинства. Во-первых, в общем случае для совершения транзакции ЭК клиент помимо браузера не должен содержать специального ПО на своем компьютере. Хотя в некоторых случаях наличие электронного бумажника целесообразно. Например, когда эмитент использует более сложные по сравнению с паролями схемы аутентификации владельца карты (например, с помощью смарт-карты и т. п.). Здесь важно, что электронный бумажник предоставляется владельцу карты его эмитентом. Его функционирование никак не регламентируется платежными системами.
Во-вторых, резко упрощается процедура сертификации. В протоколе 3D Secure используется одноуровневая система центров сертификации. В третьих, и это достоинство всех протоколов, укладывающихся в концепцию трех доменов, процедуры аутентификации ТП и владельцев карты определяются банками и не регламентируются сетью, что дает банкам свободу выбора и возможность интегрирования уже существующих решений (например, в области Интернет-бэнкинга).
Наконец, ПО, устанавливаемое на стороне обслуживающего банка и банка-эмитента, гораздо проще по своей функциональности и потому должно быть существенно дешевле ПО, реализующего SET.
- Оглавление
- История становления электронного банкинга
- Основные определения интернет-банкинга
- Основные услуги, предоставляемые посредством интернет-банкинга
- Преимущества интернет банкинга по сравнению с обычным банковским обслуживанием
- Интернет-банкинг корпораций
- Основные определения электронных платежных систем
- Участники электронных платежей
- Классификация моделей электронных платежей
- Механизмы поддержки проведения электронных платежей
- Требования к платежным системам организации, занимающиеся наблюдением за соблюдением законности в области информационной безог
- Руководящие документы в области информационной безопасности
- Основные понятия криптографии
- Криптографические алгоритмы
- Шифрование с закрытым ключом
- Шифрование с открытым ключом
- Модель osi, место протокола ssl
- Основные сведения о протоколе ssl
- Алгоритм работы ssl
- Использование сертификатов в протоколе ssl
- Основные сведения о протоколе set
- Архитектура системы центров сертификации протокола set
- Процедуры генерации, обновления и отзыва сертификатов по протоколу set
- Реализация транзакций в протоколе set
- Модель трех доменов
- Модель 3d secure
- Интернет-кредитование
- Тенденции развития интернет-банкинга
- Мобильная коммерция, устройства и технологии
- Мобильная коммерция, сети передачи данных
- Смарт-карты
- Виртуальные платежные карты
- Электронный маркетинг
- Интернет-магазины с точки зрения электронной коммерции
- Архитектура интернет-магазинов
- История европейского валютного союза
- Первый этап Европейской интеграции
- Второй этап европейской интеграции
- Третий этап Европейской интеграции
- Четвертый этап Европейской интеграции
- Новейшая история Европейской интеграции
- Электронные системы межбанковских операций, основные понятия
- Система электронных банковских расчетов Saggitattarie
- Система электронных банковских расчетов chips
- Система электронных банковских расчетов chaps
- Система электронных банковских расчетов цб рф
- Система электронных банковских расчетов FedWire
- Платежная система есцб Target
- Правовые основы функционирования европейских платежных систем
- Система клиринговых расчетов ева
- Локальные rtgs системы
- Всемирная межбанковская система swift, цели создания и история
- Всемирная межбанковская система swift, архитектура
- Всемирная межбанковская система swift, сообщения
- Определение swot анализа, пример
- Матрица стратегий использования swoTaHariH3a
- Цифровые водяные знаки
- Система сетевых денег
- Система Yandex Деньги
- Система WebMoney Transfer
- Примеры платежных систем