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

Широкое распространение протокола SSL объясняется в первую очередь тем, что он является составной частью всех известных Интернетбраузеров и Web-серверов. Это означает, что фактически любой владелец карты, пользуясь стандартными средствами доступа к Интернету, получает возможность провести транзакцию с использованием SSL.

Другие достоинства SSL — простота протокола для понимания всех участников ЭК и хорошие операционные показатели (скорость реализации транзакции). Последнее достоинство связано с тем, что протокол в процессе передачи данных использует только симметричные протоколы шифрования, которые на 2-4 порядка быстрее асимметричных при том же уровне криптостойкости.

В то же время, протокол SSL в приложении к ЭК обладает рядом существенных недостатков.

Протоколы ЭК, основанные на использовании SSL, не поддерживают аутентификации клиента Интернет-магазином, поскольку сертификаты клиента в таких протоколах почти не используются. Использование «классических» сертификатов клиентами в схемах SSL является делом практически бесполезным. Такой «классический» сертификат, полученный клиентом в одном из известных центров сертификации, содержит только имя клиента и, что крайне редко, его сетевой адрес (большинство клиентов не имеет выделенного IP-адреса). В таком виде сертификат мало чем полезен ТП при проведении транзакции ЭК, поскольку может быть без большого труда получен и мошенником. Для того чтобы сертификат клиента что-нибудь значил для ТП, необходимо, чтобы он устанавливал связь между номером карты клиента и его банком-эмитентом. Причем любой Интернет-магазин, в который обращается за покупкой владелец карты с сертификатом, должен иметь возможность проверить эту связь (возможно, с помощью своего обслуживающего банка).

Другими словами, такой сертификат должен быть получен клиентом в своем банке-эмитенте. Формат сертификата, специальные процедуры маскировки номера карты в сертификате (очевидно, номер карты не должен присутствовать в сертификате в открытом виде), процедуры распространения и отзыва сертификатов, а также многое другое в этом случае должно быть оговорено между всеми участниками транзакции ЭК. Иначе говоря, требуется создание иерархической инфраструктуры центров сертификации (по аналогии с тем, как это делается в протоколе SET, о чем будет рассказано далее). Без создания такой инфраструктуры все разговоры об обеспечении взаимной аутентификации участников транзакции ЭК — непонимание сути вопроса.

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

При использовании протокола SSL ТП аутентифицируется только по своему адресу в Интернете (URL). Это значит, что клиент, совершающий транзакцию ЭК, не аутентифицирует ТП в том смысле, о котором говорилось ранее (не получает доказательств существования договорных отношений между ТП и его обслуживающим банком-участником платежной системы). Аутентификация ТП только по URL облегчает мошенническим ТП доступ к различным системам ЭК. В частности, торговые предприятия, занимающиеся сбором информации о картах клиентов, могут получить сертификат в каком-либо известном центре сертификации общего пользования (например, Verisign, GTE, Thawte и т. п.) на основании только своих учредительных документов, после чего дорога к мошенничествам для них становится открытой.

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

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

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

При использовании SSL не обеспечивается конфиденциальность данных о реквизитах карты для ТП (как это, впрочем, происходит и в транзакциях «покупка» в обычных неэлектронных ТП).

Большинство браузеров, используемых сегодня в России, в силу ранее существовавших экспортных ограничений использует криптоалгоритмы с ключами ограниченной длины. Ограничение на длину ключа симметричного алгоритма составляло 40 битов, на длину RSA-ключа — 512 битов. Такие ограничения, как показано в главе «Введение в криптографию», существенно снижают криптостойкость используемых алгоритмов. Снятие ограничений Государственным Департаментом США на размер секретных ключей (решение было принято 17 декабря 1999 г.) не позволяет надеяться на быстрое распространение криптографически «усиленных» браузеров, и еще в течение 3-4 лет значительное количество браузеров, используемых в России, будут все еще иметь ключи ограниченного размера.

Нужно отметить, что положение с ограниченным размером ключа браузера можно поправить, если клиент обладает необходимой квалификацией. Для начала клиент должен проверить длину симметричного ключа, поддерживаемого его браузером. Такую проверку легко выполнить, подключившись к Web-серверу www.fortify.neL В нижней правой части окна браузера имеется пункт SSL Check. Если его выбрать, то будет организована SSL-сессия между браузером клиента и сервером. Сервер выберет максимально криптостойкий алгоритм шифрования, доступный на браузере клиента, и сообщит об этом клиенту: в окне браузера появится список симметричных алгоритмов шифрования с указанием длины ключа, а алгоритм, поддерживаемый браузером, в этом списке будет выделен специальным образом.

Если в результате проверки выяснится, что размер ключа меньше 64 битов, очень рекомендуется увеличить его до 128 битов. Для этого необходимо загрузить версию браузера без экспортных ограничений. Если клиент поддерживает одну из версий Netscape Navigator, то это можно сделать сразу после проверки длины ключа в том же окне браузера, выбрав внизу параметр Download.

Если клиент работает на Internet Explorer 4.0, то соответствующую версию браузера можно скачать с ftp-сервера по адресу ftp://ftp.tuniv.szczecin.pl/dskl/ftp.replay.com/pub/browsers/128bit/MS-lexplorer-v40/ ie401w95nt_128upgrade.exe. На этом же сервере можно найти заплатки для других версий Internet Explorer.

По правилам международных платежных систем Europay/MasterCard при использовании протокола SSL транзакции по дебетовым картам запрещены (VISA летом прошлого года приняла решение разрешить транзакции ЭК по дебетовым картам VISA/Electron). Молодые люди составляют значительную часть аудитории пользователей Интернета, и в то же время в силу отсутствия кредитной истории они же являются обладателями дебетовых карт.

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

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

Как следует из сказанного ранее, протокол SSL не является устойчивым.