Студопедия
Случайная страница | ТОМ-1 | ТОМ-2 | ТОМ-3
АрхитектураБиологияГеографияДругоеИностранные языки
ИнформатикаИсторияКультураЛитератураМатематика
МедицинаМеханикаОбразованиеОхрана трудаПедагогика
ПолитикаПравоПрограммированиеПсихологияРелигия
СоциологияСпортСтроительствоФизикаФилософия
ФинансыХимияЭкологияЭкономикаЭлектроника

Модель 3D SECURE

Читайте также:
  1. Samasource: модель стрекозы в действии
  2. Американская модель
  3. Американская модель
  4. Английская модель
  5. Аристотелева модель разума
  6. Базовая искусственная модель
  7. Базовая модель

Протокол 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.

 


Дата добавления: 2015-11-30; просмотров: 32 | Нарушение авторских прав



mybiblioteka.su - 2015-2024 год. (0.015 сек.)