Защита удаленных банковских транзакций (стр. 12 из 18)
Таблица 3.4
| Шаг | Действие |
| 1 | Верифицировать каждый сертификат в цепи согласно правилам X.509 |
| 2 | Проверить то, что расширения KeyUsage, CertificatePolicies, PriviteKeyUsage и AuthorityKeyIdentifier находятся в согласии c Х.509. |
| 3 | Если получено новое значение BCI:- проверить его подпись, используя сертификат CRL центра сертификации платежной системы- проверить, что BrandName в BCI соответствует тому, что проверено в цепочке сертификации- проверить, что дата NotAfter меньше текущей датыг. Проверить SequenceNum. Если оно больше чем SequenceNum из кэша BCI запомнить BCI и проверить, что все CRL, содержащиеся в BCI находятся в кэше CRL. Запомнить любой CRL, который пока нет в кэше |
| 4 | Провести верификацию для каждого нового полученного CRL, |
| 5 | Проверить каждый сертификат |
Основу потока платежных сообщений SET составляют пары запрос/отклик, следующие между владельцем карты и продавцом, а также между продавцом и расчетным центром. Основу обмена между владельцем карты и продавцом составляют сообщения PReq/PRes. Сообщение PRes может быть прислано немедленно или спустя некоторое время. Присылаемая информация зависит от фазы реализации протокола, в которой находится система.
Авторизация продавца в расчетном центре выполняется с помощью сообщений AuthReq/AuthRes.
На рисунке 3.4 показан типичный пример обмена сообщениями при реализации протокола покупки.
Рисунок 3.4 – Диаграмма обмена для протокола покупки
На рисунке 3.5 показаны все возможные сообщения, которые могут иметь место при обработке транзакции (опционные сообщения отмечены курсивом). Следует заметить, что приведенный порядок обмена является рекомендуемым, и допускается его изменение.
а)
б)
Рисунок 3.5 – Опции обмена сообщениями при покупке: а) начало, б) продолжение
Пары сообщений InqReq/InqRes позволяют владельцу карты получать информацию о состоянии транзакции. Запрос InqReq может быть послан в любое время после посылке продавцу PReq. В паре сообщений PReq/PRes владелец карты уведомляет продавца о том, что же он хочет купить. Сообщения AuthRevReq и AuthRevRes используются тогда, когда необходимо возобновить авторизацию. Сообщения CapRevReq и CAPRevRes организуют процесс отмены оплаты покупки, прежде чем сделка будет завершена. Пара CredReq и CredRes сходна с предыдущей парой, но используется после завершения сделки. Сообщения PCertReq/PCertRes обеспечивают для продавца механизм получения сертификата шифрования, который необходим для шифрования сообщения расчетному центру. BatchAdminReq и BatchAdminRes служат продавцу для открытия, закрытия и выяснения статуса транзакции его платежной линии с расчетным центром. Сообщения Error служат для уведомления об ошибках в протоколе или при обработке.
Протокол SЕТ является устойчивым протоколом. Доказательство этого следует из приведенного описания протокола.
SET обладает следующими свойствами:
- мошеннику недостаточно знать реквизиты платежной карты для того, чтобы успешно выполнить SET-транзакцию. Помимо рекви-зитов карты необходимо иметь закрытый ключ владельца данной карты, а также сертификат соответствующего ему открытого ключа;
- торговая точка при выполнении SET-транзакции точно знает, что владелец карты, совершающий транзакцию, является подлинным, то есть обладает секретным ключом RSA, для которого открытый ключ сертифицирован банком-эмитентом клиента;
- клиент точно знает, что торговая точка, в которой совершается SET-транзакция, является истинной, то есть обладает секретным ключом RSA, для которого открытый ключ сертифицирован обслуживающим банком торговой точки;
- обслуживающий банк точно знает, что владелец карты и торговая точка являются подлинными, то есть обладают сертифицированными ключами;
- информация о реквизитах карты не известна торговой точке;
- торговая точка и владелец карты имеют заверенные подписями соответственно владельца карты и торговой точки подтверждения факта совершения транзакции, что делает невозможным отказ от результатов операции ни одного из участников транзакции.
Сегодня не существует никакого другого (кроме SET) опубликованного устойчивого протокола. Другими словами, на рынке аппаратно-программных решений, реализующих устойчивый протокол для использования в электронной коммерции, не существует альтернативы продуктам, реализующим SET. VISA International предполагает в ближайшее время опубликовать спецификации нового глобального стандарта аутентификации; называемого 3D Secure. Однако неочевидно, что этот стандарт будет определять устойчивый протокол.
Протокол SET де-факто является отраслевым стандартом в области пластиковых карт.
Будучи признанным ведущими международными платежными системами (VISA, MasterCard, Europay, AmEx, Diners Club) в качестве стандарта в электронной коммерции, SET де-факто является отраслевым стандартом.
Таким образом, протокол SET является на сегодняшний день единственным открытым и устойчивым протоколом в электронной коммерции.
4. ПРОГРАММНАЯ РЕАЛИЗАЦИЯ СИСТЕМЫ УДАЛЕННЫХ БАНКОВСКИХ ТРАНЗАКЦИЙ
В дипломном проекте разработано учебное электронное пособие, демонстрирующее алгоритм проведения удаленной транзакции с использованием сервера авторизации. Учебное пособие состоит из двух частей. В пособии предлагается изучить теоретический материал по данной теме, а затем перейти к построению алгоритма, демонстрационному материалу и вопросам. На рисунке 4.1 изображен экран входа в учебное пособие.
Рисунок 4.1 – Вход в электронное учебное пособие
4.1 Теоретический материал учебного пособия
Все необходимые теоретические сведения по теме «защита удаленных банковских транзакций» пользователь может получить, нажав кнопку «теория». Кнопка доступна только на первой странице, после того как пользователь приступил к выполнению заданий, он не сможет подсмотреть в теорию. Что позволит проверить, насколько четко был усвоен предложенный материал.
Теоретический материал содержит следующие разделы:
- Электронные платежные системы;
- Проблемы безопасности удаленных банковских транзакций;
- Защита удаленных банковских транзакций.
На рисунке 4.2 изображен раздел электронного учебного пособия содержащий теоретический материал.
Рисунок 4.2 – Теоретический раздел электронного учебного пособия
4.2 Практическое задание
К выполнению практического задания можно приступить на первой странице учебного пособия. Рабочая область логически разделена на две части. В левой части находятся:
- меню выбора;
- индикатор правильности ответов;
- комментарии произведенных действий;
- счетчик ошибок.
В правой части находится демонстрационное поле. Это поле используется для демонстрации построения алгоритма удаленных транзакций и механизмов защиты. До начала выполнения работы в демонстрационном поле отображается задание и принцип его выполнения. Рисунок 4.3 отображает вид электронного учебного пособия после демонстрации первого демо-ролика.
Рисунок 4.3 – Второй шаг выполнения задания
Выполнение работы начинается с составления схемы алгоритма проведения удаленных банковских транзакций с использованием сервера авторизации. В схеме участвуют следующие элементы:
- магазин;
- сервер авторизации;
- покупатель;
- банк-эмитент;
- банк-эквайр;
- закрытые банковские сети.
Для пошагового составления схемы используется меню выбора, которое находится в левой части экрана. Меню выбора содержит два одинаковых столбца, в первом необходимо указывать элемент, от которого исходит сообщение, а во втором – к которому оно направленно. После того как оба элемента выбраны, необходимо нажать кнопку «Проверить». В случае если элементы были выбраны верно, в демонстрационном поле будет проигран ролик, слева появится комментарий произведенного действия. Верные варианты приведены в таблице 4.1.
Таблица 4.1 – Верные варианты ответов
| Шаг | Элемент первой колонки | Элемент второй колонки |
| 1 | Покупатель | Магазин |
| 2 | Магазин | Сервер авторизации |
| 3 | Покупатель | Сервер авторизации |
| 4 | Сервер авторизации | Банк-эмитент |
| 5 | Банк-эмитент | Закрытые банковские сети |
| 6 | Закрытые банковские сети | Банк-эквайр |
| 7 | Банк-эквайр | Закрытые банковские сети |
| 8 | Закрытые банковские сети | Банк-эмитент |
| 9 | Банк-эмитент | Сервер авторизации |
| 10 | Сервер авторизации | Покупатель |
| 11 | Сервер авторизации | Магазин |
| 12 | Банк-эмитент | Магазин |
| 13 | Магазин | Покупатель |
Если же один или оба элемента выбраны неверно, после нажатия кнопки «Проверить» индикатор правильности ответов сообщит об ошибке, счетчик ошибок зафиксирует ошибку, как показано на рисунке 4.4.