Электронная коммерция

Современные сервисы Интернета позволяют решать практически все задачи по взаимодействию про­давца и покупателя: поиск товара или покупателя, коммуникация между продавцом и покупателем, электронные платежи и т. д. Торговые Web-серверы

Существует несколько протоколов для серверов, используемых для элек­тронной коммерции в Интернете.

Приложения для совершения покупок

Нскоторе время назад электронная коммерция выглядела довольно про­сто. Web-торговцы создавали HTML-версии ферм для заказа, покупате­ли их заполняли, распечатывали и присылали по обычной почте. Ката­логи продавцов были интерактивными, но сам процесс заказа таковым не являлся.

Затем появились формы заказа, которые покупатели могли пересылать по Интернету. Для этого требовались клиентские HTML-формы, взаи­модействующие с заказчиками, а также серверные интерфейс CGI и специальные приложения, принимающие и обрабатывающие данные. От пользователей требовалось занести данные в одну или несколько HTML-форм. Часто внешний HTML-интерфейс генерировался динами­чески, в зависимости от базы данных товаров.

Позднее были разработаны более сложные приложения: теперь пользо­ватели могли просматривать интерактивные каталоги и заносить пред­меты с нескольких страниц в виртуальные списки покупок (virtual shopping cart). Система, установленная на сервере, запоминала все выбранные предметы и объединяла их в общий список по окончании

посещения виртуального магазина. Такие приложения известны как приложения для совершения покупок (shopping cart application).

Чтобы сохранить список выбранных предметов, приложения для совер­шения покупок используют специальные маркеры (cookies) и HTTP-за­головки. HTTP — протокол без памяти, то есть каждая HTTP-команда выполняется независимо от предшествую­щий. По этой причине обычно используют некоторый маркер, позволя­ющий логически объединить последовательности действий и НТТР-транзакции. Этот маркер должен быть доступен серверу, для чего его ука­зывают как параметр в последующих URL динамических HTML-стра­ниц или включают в другой НТТР-заголопок.

Открытый HTTP

Web-транзякции могут выполняться с применением обычных Web-про­токолов и кредитных карт. Пользователь может посылать продавцу информацию о платеже посредством HTML-страниц и HTML-форм. Однако, поскольку сообщения протокола HTTP никак не защищены (вся информация передается в открытом виде как ASCII-текст), вероятен анализ перехваченных открытых данных и извлечение платежной ин­формации, например номеров кредитных карт.

S-HTTP

Защищенный протокол S-HTTP (Secure HTTP), разработанный компа­нией Enterprise Integration Technology (EJT), является расширением протокола HTTP. On позволяет браузерам и серверам подписывать, идентифицировать и шифровать сетевые HTTP-пакеты. Данный про­токол, так же как и обычный HTTP, использует MIME (Multipurpose Internet Mail Extensions) для добавления заголовков, указывающих на необходимость специальной обработки, и для хранения информации о сертификатах и ключах. Процесс установления связи между браузером, поддерживающим протокол S-HTTP, и сервером несколько сложнее аутентификации в обычном HTTP. В настоящее время протокол S-HTTP используется редко, потому что его в значительной степени потеснил SSL (Secure Sockets Layer).

HTTP и SSL

SSL (Secure Sockets Layer) — это метод шифрования, разработанный компанией Netscape Communications для сокетов TCP/IP. Как и S-HTTP, SSL обеспечивает защиту сетевых HTTP-пакетов. Отличие же в том, что S-HTTP работает только на уровне протокола HTTP, a SSL — на уровне сокетов, обеспечивая безопасность ряда других протоколов Интернета, использующих сокеты. Процесс согласования между клиентом, поддер­живающим SSL, и сервером подобен процессу согласования обычных сокетов, но в случае с SSL клиент и сервер дополнительно передают сообщения для выбора алгоритма шифрования и обмена ин­формацией о сертификатах и ключах.

При применении SSL с протоколом HTTP, Web-браузер использует URL-схемы вида «https://» вместо «http://», как для открытого HTTP. Мно­гие Web-браузеры сообщают пользователю (с помощью диалоговых окон), что транзакции на основе HTTPS более безопасны, чем обычные HTTP-транзакции .

Сейчас SSL используется повсеместно для обеспечения безопасности Web-транзакций общего назначения и практически заменил S-HTTP. Развитием SSL (и протоколов транспортного уровня) занимается рабо­чая группа Transport Level Security (TLS) в составе IETF.

Системы торговых серверов

В настоящее время в Web-коммерции используются в основном тради­ционные Web-протоколы, а для передачи конфиденциальной информа­ции о платежах — HTTP, зашифрованный средствами SSL. Существует много приложений для совершения покупок, которые обеспечивают по­добные функциональные возможности. Специализированные сервер­ные системы заменяются коммерческими продуктами для торговых сер­веров. Эти программы обычно содержат инструментальные средства для помещения информации о товарах из базы данных в Web посредством сценариев и HTML-страниц. Они также включают модульные подсис­темы для обработки оплаты, поставки и объединения с другими компь­ютерными системами.

Более сложные системы выполнят проверку правильности платежа в реальном времени, что требует взаимодействия с банком, обслуживаю­щим счета продавца. Менее сложные системы откладывают проверку правильности платежа до тех пор, пока запрошенная транзакция не будет перенесена в обычную расчетную систему продавца.

Протокол set

SET (Secure Electronic Transaction) — это протокол электронных плате­жей на основе банковских карт, разработанный консорциумом компа­ний но главе с MasterCard и Visa. Он превращает финансовые операции в виртуальные, чем-то напоминающие манипуляции с кредитной кар­точкой.

Покупая товары с помощью обычных кредитных карт, покупатели вза­имодействует с продавцами. Последние для проверки сделки обраща­ются к банкам, принимающим карточки к оплате, а банки-эммитенты взаимодействуют с держателями карт для получения денег за покупку. Применив эту схему к электронным транзакциям, ком­пании MasterCard, Visa и другие разработали протокол SET, Он исполь­зует тот же самый базовый процесс, но заменяет реальную кредитную карточку интерактивным протоколом, Протокол SET сохраняет иерар­хию доверительных отношений, что существует между продавцом и Банком, принимающим платеж, а также владельцем карты и банком-эммитентом. В электронном варианте эта иерархия доверия формали­зована посредством цифровых сертификатов и иерархии сертификаци­онных служб (аналог финансовой системы экономики).

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

Протокол SET не привязан к HTTP. Его можно использовать с самыми разными протоколами. SET не простой прото­кол: его сообщения и структуры данных описаны в формате ASN.1 (Abstract Syntax Notation One). В отличие от SSL, SET шифрует сами сообщения, а не канал связи. В результате возможны более сложные шифры, нежели многоцелевые (как в SSL).

Структура SET -запроса разбивается на две части — информация о за­казе (Order Information, ОI) и информация о платеже (Payment Information,PI). Последняя нужна банку; но не продавцу. (Продавцу доста­точно получить от банка подтверждение платежа.) Все данные, относя­щиеся к одной транзакции, скрепляются методом двойной подписи (dual signature).

Этот метод использует два различных сообщения, одно из которых ад­ресовано продавцу, а другое — банку. Эти сообщения взаимосвязаны, поэтому банк может сопоставить платеж с заказом, не зная всех дета­лей последнего. Продавец получает гарантии лишь относительно опла­ты заказа и размера платежа, но не владеет никакой другой информа­цией (например, не знает номер счета — эквивалент шестнадцатизнач­ного номера кредитной карточки — заказчика).

Каждое сообщение обрабатывается алгоритмом дайджеста сообщений, который вырабатывает 160-битный дайджест. Затем два дайжджеста соединяются, и результат обрабатывается этим же алгоритмом. Конеч­ный вариант покупатель подписывает с помощью своего личного клю­ча. Это и есть двойная подпись. Затем покупатель отправляет два сооб­щения. Одно — продавцу, в нем описаны детали заказа и содержится дайджест сообщения, посланного банку. Другое сообщение — в банк; в нем указана стоимость транзакции и содержится дайджест сообщения, посланного продавцу.

И банк, и продавец могут проверить подлинность полученного сообще­ния. Для этого необходимо вычислить дайджест принятого сообщения и объединить его с дайджестом другого сообщения. Вычисленный общий дайджест должен совпадать с расшифрованной (при помощи открытого ключа покупателя) двойной подписью. Обратите внимание на то, что этот метод позволяет покупателю торговаться при покупке. Продавец посылает банку сообщение только в том случае, если принимает пред­ложение покупателя. Дайджест сообщения связывает транзакцию меж­ду продавцом и покупателем с сообщением межу банком и покупате­лем, подтверждающим платеж.

SET явно использует два вида шифрования: симметричное и асиммет­ричное, а также сертификаты для сопоставления открытого и личного ключей. Многие компании, производящие программное обеспечение, выпускают API для работы с протоколом SET. Большинство приложе­ний, использующих SET, например системы торговых серверов и ана­логичные им объекты клиентской стороны (своего рода виртуальные кошельки), применяют эти программные библиотеки.

Электронные деньги

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

Для большинства видов электронных денег разработаны специальные протоколы обмена финансовыми заявками между клиентом, продавцом и эммитентом денег (банком). Эти протоколы реализованы как для сер­верного ПО, так и для клиентского — электронного бумажника.

Микроплатежи

Электронные деньги имеют значительное преимущество перед реаль­ными: они позволяют осуществлять микроплатежи — платежи, размер которых меньше, чем существующие денежные единицы. Система кредитных карт этого не допускает. Микроплатежи часто связаны с «нематериальными товарами», такими, как доступ к Web-страницам. Существующие системы для обычных платежей не всегда корректно работают со столь малыми суммами.

Электронные бумажники

Многие виды электронных денег требуют наличия у клиента так назы­ваемого электронного бумажника — программного обеспечения, кото­рое посылает информации о финансовой сделке на сервер, используя специальный протокол. Некоторые разработчики программного обес­печения создают API, чтобы для различных электронных денег, чтобы использовать один и тот же «бумажник» — так же как в реальный бумажник, в который можно положить кредитные карты различных пла­тежных систем.

Другие компании применяют электронные бумажники для иных целей. Некоторые Web-узлы имеют гостевые книги, в которые пользователей просят сообщить информацию о себе и о своих предпочтениях для ди­намического формирования содержания узла. Часть этой информации хранят в «бумажниках». Когда такие сведения помещены в одно место, где четко определены процедуры их запроса и обработки, удобнее ис­пользовать электронный бумажник (небольшую клиентскую базу дан­ных, содержащую, например, номер кредитной карточки, информацию о цифровой подписи и сведения для идентификации и аутентифика­ции) для нефинансовой информации. Кстати, в обычном бумажнике часто мы тоже храним массу нужных нам вещей, не имеющих отношения к деньгам: листочки с телефонами, записочки, фотографии и др.