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

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

Использование протокола SET, обеспечивающего высокую степень защиты транзакций ЭК, в мире весьма ограничено (около ста тысяч карт и несколько сотен торговых предприятий). Тому имеется множество причин, решающей среди которых является высокая стоимость внедрения системы ЭК на базе протокола SET (стоимость SET-решения колеблется между $600 и 1500 тыс.).

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

Как известно, любое SET-решение состоит из четырех программных компонентов — электронного кошелька покупателя, POS-сервера продавца, платежного шлюза обслуживающего банка продавца и центра сертификации (ЦС). При этом наиболее дорогостоящими компонентами решения являются платежный шлюз (от $350 до 500 тыс.) и ЦС (около $200-300 тыс.).

Идея описываемого далее протокола ЭК состоит в исключении из употребления наиболее дорогостоящего компонента решения SET — платежного шлюза и замене его так называемым Интернет-агентом. Основные функции такого Интернет-агента аналогичны функциям платежного шлюза. Однако взаимодействие между Интернет-магазином и шлюзом определяется обслуживающим банком, как это делается при подключении банком к своему центральному компьютеру электронных POS-терминалов. Конечно, на это взаимодействие в значительной степени накладывает отпечаток протокол работы клиента и ТП, о чем еще будет сказано.

Суть идеи заключается в том, чтобы оставить интерфейс между покупателем и продавцом полностью соответствующим стандарту SET, но при этом изменить протокол взаимодействия между торговым предприятием и его обслуживающим банком (такой протокол будет в дальнейшем называться SSET — Simplified SET). Следует отметить, что протокол работы продавца и его банка всегда являлся предметом соглашения продавца и банка и платежными системами фактически не регламентировался (имелись общие требования, реализация которых оставалась предметом договоренности между продавцом и банком). Функции платежной системы всегда состояли в определении интерфейса между банком и платежной сетью.

В случае SET в силу трехстороннего характера этого протокола платежные системы впервые за всю историю своего существования вторглись в область, которую никогда прежде не регламентировали. И в этом состояла одна из главных ошибок. В действительности, было бы достаточно определить формат отдельных элементов сообщений, используемых для обмена информацией между продавцом и обслуживающим банком, для того чтобы остальную часть протокола оставить на усмотрение продавца и его банка. Новые инициативы системы VISA, связанные с провозглашением концепции 3D (трех доменов), является фактически попыткой исправить сделанную ошибку.

Технически протокол SSET выглядит следующим образом. Покупатель передает продавцу сообщение Payment Order и получает в ответ сообщение Payment Response, подтверждающее принятие заказа от покупателя. Весь этот обмен происходит в полном соответствии с протоколом SET и потому на этом этапе производится взаимная аутентификация покупателя и продавца. Позже покупатель может воспользоваться другой SET-транзакцией Purchase Inquiry для того, чтобы узнать статус исполнения сделанного им заказа.

После принятия заказа продавец, вообще говоря, в отложенном режиме (off-line) генерирует сообщение Payment Authorization для отправки его банку-эмитенту (через платежный шлюз и платежную систему) с тем, чтобы получить авторизацию эмитента на проведение безналичной операции продажи товара или услуги покупателю. При этом форматы и алгоритм обмена сообщениями между продавцом и обслуживающим его банком остаются предметом соглашения между продавцом и банком. К информационному обмену между продавцом и его банком предъявляются лишь следующие общие требования:

  • сообщение Payment Authorization должно содержать в неизмененном виде поля (эти поля без изменения переносятся из сообщения Payment Order), относящиеся к Payment Instructions (эти поля содержат реквизиты карты), и значение dual message signature;
  • строго рекомендуется, чтобы сообщение Payment Authorization было подписано продавцом и содержало сертификат открытого ключа продавца;
  • ответ на сообщение Payment Authorization должен быть подписан Интернет-шлюзом и содержать сертификат открытого ключа Интернет-шлюза;
  • в сообщении от платежного шлюза к ТП должны содержаться список CRL-листов вместе с соответствующими списками отозванных сертификатов.

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

Транзакция Payment Capture, используемая продавцом для того, чтобы потребовать от обслуживающего банка расчета по транзакции электронной покупки, может быть реализована с помощью механизма предавторизации. В соответствии с этим механизмом транзакция Payment Authorization перед отправкой в платежную сеть преобразуется в сообщение 0100 (authorization request), которое позволяет «заморозить» сумму, соответствующую покупке, на счете клиента. После выполнения заказа продавец генерирует сообщение 0200 (completion), дебетующее со счета покупателя сумму покупки.

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

Протокол SSET очевидным образом позволяет поддержать все известные «расширения» протокола SET 1.0, включая расширение, связанное со смарт-картами (Common Chip Extension).

С точки зрения международных платежных систем транзакция SSET может рассматриваться как транзакция с Electronic Commerce Indicator соответствующим Encrypted Channel, что предполагает, в частности, тот факт, что ответственность за транзакцию в случае возникновения диспута лежит на обслуживающем банке. Однако можно быть уверенным в том, что обслуживающие банки в целях экономии средств на первом этапе будут готовы пойти на использование протокола SSET, понимая, что вероятность мошенничества при его использовании так же мала, как и при использовании SET.

Несколько слов по поводу процедуры управления сертификатами. В первую очередь, необходимо отметить, что для клиентов и ТП эта процедура не меняется никак. Другими словами, как и в случае «чистого» SET эти участники электронной коммерции получают свои сертификаты в режиме реального времени от центров сертификации ССА и МСА, соответственно.

Что касается платежного шлюза, то здесь можно действовать разными способами. Первый способ — оставить все в том же виде, что и в протоколе SET. Второй способ, позволяющий уменьшить программную сложность Интернет-агента (а значит, и его стоимость), — проводить процедуру получения сертификата в режиме off-line. В этом случае платежный шлюз должен получить возможность получения. Второй способ, позволяющий уменьшить программную сложность сертификатов своих ключей в PC А с помощью запросов PKCS#10/PKCS#7. При этом можно получить сертификаты для «запасных» ключей, которые могут быть оперативно использованы в случае компрометации основной пары ключей. Функция получения списка BCI и соответствующих ему списков CRL остается без изменений. Эта функция реализуется в режиме off-line и потому не является обременительной с точки зрения сложности программной реализации.

Нужно ли сертифицировать Интернет-агента в компании SETCo на соответствие спецификациям протокола SET. Ответ — нет, если правильно распределить ответственность между участниками транзакции. В частности, если считать, что ответственность за потерю реквизитов карты из-за скомпрометированного ключа платежного шлюза лежит на обслуживающем банке, то сертификации платежного шлюза проводить не нужно.

Что необходимо сделать для того, чтобы протокол SSET можно было использовать? Обслуживающему банку при применении SSET необходимо получить разрешение международных платежных систем на получение сертификата своих ключей на ключах соответствующих систем, а также на выдачу сертификатов ключей продавца и Интернетшлюза (для Интернет-агента) на своем ключе. Кроме того, платежные системы должны дать разрешение на прием SET-карт в SSET-магазинах. Поскольку ни одно из перечисленных ранее решений платежных систем никоим образом не приводит к какой-либо компрометации конфиденциальных данных участников транзакции ЭК, выдача подобных разрешений является лишь вопросом доброй воли платежных систем.

Каковы преимущества протокола SSET для банков?

  • Существенно уменьшаются начальные затраты обслуживающих банков на реализацию протокола SET. За счет этого должна существенно расшириться инфраструктура продавцов, принимающих к оплате SET-карты.
  • Расширяется инфраструктура электронных магазинов, обслуживающих SET-карты, что делает интересным для банков-эмитентов эмиссию таких карт.

Предлагаемый протокол является первой ступенькой к реализации протокола SET в полном объеме. С ростом объемов операций обслуживающие банки станут постепенно переходить на SET.

SSET эффективнее альтернативных вариантов, предлагаемых некоторыми платежными системами (например, 3D SSL), поскольку обеспечивает более высокий уровень защиты при разумных затратах на реализацию и допускает в дальнейшем переход на полный SET.