2014-02-09
584
Вступ
Література.
Час – 4 год.
Навчальні питання
Лекція 9. Протокол SET
1.... Архітектура SET. 1
2.... Сервіси безпеки протоколу SET. 3
3.... Сертифікація. 7
4.... Транcакція покупки. 14
1. Деднев M. А., Дыльнов Д. В., Иванов М. А. Защита информации в банковском деле и электронном бизнесе. — М.: КУДИЦ-ОБРАЗ, 2004. - 512с. - (СКБ - специалисту по компьютерной безопасности).
В этой лекции рассмотрим протокол SET (Secure Electronic Transaction), используемый для защиты транзакций по банковским картам, проводимых через открытые сети типа Интернет. Спонсором протокола выступают Visa и Mastercard в сотрудничестве с основными игроками на рынке информационных технологий, такими, как IBM, GTE, Microsoft, SAIC (Science Aplication International Corporation), Terisa Systems и Verisign. Основная цель этой кооперации ‑ сделать возможными online-платежи по банковским картам и при этом избежать фрагментации рынка на множество несовместимых протоколов.
SET работает на уровне приложения независимо от транспортного слоя, чем отличается от SSL. Однако на практике SET обычно рассматривается именно как средство защиты данных, передаваемых по протоколу TCP. SET предназначен только для осуществления платежа и не применяется для поиска или выбора товара. По протоколу SET транзакция производится держателем карты без непосредственного считывания данных с карты, вместо этого он предоставляет сертификат, подписанный организацией, в ведении которой находится оформление, регистрация и выдача цифровых сертификатов. Сертификат хранится на жестком диске компьютера (или на дискете) и позволяет производить аутентификацию пользователя с использованием криптоалгоритмов с открытым ключом.
SET обеспечивает безопасность исключительно программными средствами; однако существует два проекта по развитию возможности использования SET вместе с микропроцессорными картами (смарт-картами) — C-SET (Chip-Secured Electronic Transation) и E-Comm.
Разработчики SET руководствовались основным принципом ‑ безопасные транзакции по банковским картам через Интернет должны осуществляться без модификации существующих банковских схем авторизации и удаленного сбора данных.
Процессинговые центры банков имеют серверы (см. лекцию 2), которые отфильтровывают мошеннические транзакции по ряду критериев, таких, как максимальная сумма транзакций за день или ненормальное количество транзакций за определенный временной период. Таким образом, для авторизации транзакции по банковской карте продавец должен опросить сервер авторизации. Позже, на этапе окончательного расчета, продавцу возмещается сумма проданных товаров или услуг. Некоторые платежные системы требуют, чтобы возмещение происходило только после поставки товаров. Возмещение происходит только после того, как продавец посылает в банк клиринговый запрос (для возмещения возникшей непогашенной задолженности платежной системы перед продавцом), который перенаправляется в банк-эмитент карты по защищенным банковским сетям. Отметим, что в некоторых платежных системах авторизация и возмещение совмещены в одну операцию для каждой транзакции. Другие платежные системы позволяют группировать транзакции таким образом, что несколько запросов на авторизацию и возмещение могут быть переданы в одно условленное время, например по окончании рабочего дня. Если продавец возвращает деньги покупателю (например, при возврате проданного товара), продавец дает указания своему банку кредитовать счет клиента на указанную сумму.
Чтобы позволить такой схеме работать во всем мире, SET определяет две новые сущности: центр сертификации (CA - certification authority) (для сертификации участников) и платежный шлюз, работающий на стыке Интернета и банковской сети.
Таким образом, имеем шесть участников информационного взаимодействия в рамках SET.
- Держатель карты, чья карта соответствует спецификации SET и выпускается эмитентом (обычно это банк, связанный с VISA или MasterCard).
- Сервер продавца.
- Платежный шлюз.
- Центр сертификации.
- Эмитент карты.
- Организация-эквайер (банк продавца).
На рис. 1 показана архитектура SET. Держатель карты, продавец, центр сертификации и платежный шлюз соединены посредством Интернета. Клиент не устанавливает прямое соединение с платежным шлюзом, он использует туннельные протоколы для соединения через сервер продавца. Каждый из участников информационного обмена должен предварительно получить от центра сертификат, соответствующий спецификации SET. Эти сертификаты включаются в каждое сообщение, передаваемое между держателем карты, продавцом и платежным шлюзом.
Рис.1. Участники SET-транзакции
Эмитент и эквайер соединены через закрытую банковскую сеть. Шлюз имеет два интерфейса: со стороны сети Интернет (соответствующий спецификации SET) и со стороны защищенной сети финансовых организаций.
SET защищает обмен данными как между покупателем и продавцом, так и между продавцом и платежным шлюзом. Платежный шлюз управляет платежами по поручению банка-эквайера и банка-эмитента. Как следствие, использование платежного шлюза должно быть одобрено банком или находиться под ответственностью финансовой организации.
На рис. 2 показано положение SET в стеке протоколов TCP/IP при осуществлении платежей в рамках электронной коммерции.
Рис. 2.Положение SET в стеке протоколов TCP/IP
SET - это транзакционно-ориентированный протокол, функционирующий в режиме запрос-ответ. Структура сообщений соответствует DER (Distinguished Encoding Rules) нотации ASN.1[1]' (Abstract Syntax Notation 1). Используемая версия ASN.1 датирована 1995 годом, как описано в стандартах ISO/IEC 8824-1, 8824-2, 8824-3 и 8824-4, где правила DER соответствуют ISO/IEC 8825-1. Сообщение инкапсулировано в MIME[2], как описано в РКС8#7 (RFC2315). В частности, SET использует следующие структуры PKCS#7:
· SignedData - для подписанных данных;
· EnvelopedData - для нешифрованных данных, помещенных в «цифровой конверт»;
· DigestedData - для хеш-образов (дайджестов);
· EncryptedData - для шифрованных данных.
