Л.К. Бабенко, В.М. Чепель

Таганрогский государственный радиотехнический университет

АРХИТЕКТУРА ЗАЩИЩЕННОЙ ЭЛЕКТРОННОЙ ПЛАТЕЖНОЙ СИСТЕМЫ

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

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

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

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

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

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

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

Таким образом, кратко описанная выше архитектура защищенной электронной платежной системы достаточно надежна и относительно проста в реализации, так как использует для защиты передаваемых данных хорошо известный протокол SSL, не требует создания специального программного обеспечения для покупателя (все необходимое ПО уже давно стало частью стандартного ПО любого веб-браузера) и все необходимые для покупателя инструкции скачиваются с серверов продавца и платежного шлюза. Серверное программное обеспечение также может быть реализовано с помощью стандартных и хорошо известных средств создания серверных сценариев, таких как PHP, PERL, либо с помощью обычных средств создания прикладных программ, таких как язык C/C++.