Глава 4. В мире Secure Electronic Transaction. Электронная коммерция на основе протокола SSL

Сегодня наиболее распространенным протоколом, используемым при построении систем ЭК (по различным оценкам не менее 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-серверу wwwfcrtiiyneL В нижней правой части окна браузера имеется пункт SSL Check. Если его выбрать, то будет организована SSL-сессия между браузером клиента и сервером. Сервер выберет максимально криптостойкий алгоритм шифрования, доступный на браузере клиента, и сообщит об этом клиенту: в окне браузера появится список симметричных алгоритмов шифрования с указанием длины ключа, а алгоритм, поддерживаемый браузером, в этом списке будет выделен специальным образом.

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

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

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

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

• аутентификацию владельца карты другими участниками ЭК: ТП и ОБ;

• аутентификацию ТП другими участниками ЭК: владельцем карты и ОБ;

• аутентификацию обслуживающего банка торговым предприятием;

• конфиденциальность сообщений, которыми обмениваются участники ЭК через Интернет;

• конфиденциальность информации о реквизитах карты для ТП;

• целостность данных, которыми обмениваются участники ЭК;

• невозможность отказа от транзакции (non-repudiation) — наличие для каждого участника транзакции электронного практически неопровержимого доказательства факта совершения транзакции.

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

Описание протокола SET Архитектура системы центров сертификации

Как уже отмечалось ранее, необходимым условием создания глобальной системы аутентификации, основанной на использовании асимметричной криптографии, является наличие иерархической однокорневой системы центров сертификации. Основные функции системы ЦС — генерация и распределение сертификатов открытых ключей, обновление сертификатов, а также генерация и распределение списков отозванных ключей (Certificate Revocation Lists, или сокращенно CRL).

В протоколе SET система ЦС имеет 4-уровневую архитектуру, показанную на рис. 4.1 и базирующуюся на использовании протокола Х.509.

Рис. 4.1. Архитектура системы центров сертификации в стандарте SET

На верхнем уровне располагается Корневой ЦС (Root Certificate Authority, или сокращенно RCA). Он отвечает за генерацию сертификатов для ЦС следующего нижележащего уровня Центров сертификации международных платежных систем (Brand Certificate Authority, или сокращенно ВСА), генерацию сертификатов для собственных открытых ключей, а также генерацию и распределение CRL для возможно скомпрометированных ключей ЦС уровня ВСА. Оператором RCA является компания SETCo, специально созданная для развития и распространения стандарта SET.

На втором уровне иерархии системы ЦС находятся ЦС платежных систем. В настоящее время такие ЦС созданы в платежных системах VISA, Europay/MasterCard, American Express и других. ЦС уровня ВСА отвечает за генерацию сертификатов для ЦС следующих уровней — GCA, CCA, MCA, PCA, а также за генерацию, поддержку и распространение CRL для сертификатов, ранее подписанных данным ВСА. Оператором ВСА является соответствующая платежная система.

На третьем уровне системы ЦС SET располагается Геополитический ЦС (Geo-Political Certificate Authority, или сокращенно GCA). Наличие ЦС уровня GCA позволяет платежной системе проводить более гибкую политику генерации и распределения сертификатов ключей для ЦС уровня CCA, MCA, PCA в отдельных геополитических зонах земного шара, а также повышать эффективность процедур генерации, поддержания и распространения CRL по сертификатам, эмитированным GCA. Оператор ЦС уровня GCA определяется правилами соответствующей платежной системы. Например, по правилам систем VISA и MasterCard оператором GCA может быть либо сама платежная система, либо Group Member — банк, имеющий статус Группового участника платежной системы.

Наконец, на четвертом, нижнем уровне системы ЦС SET располагаются три так называемых оконечных (End-Entity) типа ЦС: ЦС для владельцев платежных карт (Cardholder Certificate Authority, или сокращенно CCA), ЦС для ТП (Merchant Certificate Authority, или сокращенно MCA) и ЦС для платежных шлюзов (Payment Gateway Certificate Authority, или сокращенно РСА). Центры сертификации уровня End-Entity отвечают за генерацию сертификатов для основных участников транзакции ЭК — для владельца карты, ТП и платежного шлюза. В этом смысле все остальные ЦС играют вспомогательную роль, обеспечивая единую общую инфраструктуру центров доверия, позволяющую любым двум непосредственным участникам транзакции ЭК надежно аутентифицировать друг друга. Кратко остановимся на основных функциях ЦС уровня End-Entity.

ЦС уровня ССА отвечает за генерацию и доставку сертификатов открытых ключей владельцев карт. Запросы на получение сертификатов поступают в ССА от владельцев карт либо через Web-страницы, либо по электронной почте. Для генерации сертификата владельца карты ССА должен поддерживать специальную процедуру идентификации клиента, определенную эмитентом карты. ССА также отвечает за распространение среди владельцев карт списков CRL, сгенерированных RCA, ВС A, GCA, РСА. Оператором ССА могут являться банк-эмитент карточек, для которых выпускаются сертификаты, платежная система или третья сторона, определяемая правилами конкретной платежной системы.

ЦС уровня МСА отвечает за генерацию и доставку сертификатов открытых ключей ТП. Запросы на получение сертификатов поступают в МСА от ТП либо через Web-страницы, либо по электронной почте. Для генерации сертификата ТП МСА должен поддерживать специальную процедуру идентификации ТП, определенную обслуживающим банком данного ТП. МСА также отвечает за распространение в адрес ТП списков CRL, сгенерированных RCA, BCA, GCA, РСА. Оператором МСА могут являться обслуживающий банк ТП, платежная система или третья сторона, определяемая правилами конкретной платежной системы.

ЦС уровня РСА отвечает за генерацию и доставку сертификатов открытых ключей платежным шлюзам. РСА также отвечает за генерацию и распространение списка CRL, содержащего ранее эмитированные данным РСА сертификаты открытых ключей, для которых соответствующие им закрытые ключи оказались скомпрометированными на момент рассылки CRL.

РСА отвечает за распространение в адрес платежных шлюзов листов CRL, сгенерированных RCA, BCA, GCA, РСА. Оператором РСА могут являться обслуживающий банк, платежная система или третья сторона, определяемая правилами рассматриваемой платежной системы.

В протоколе SET используются четыре типа пар асимметричных ключей, отличающихся друг от друга по своему назначению:

• ключ для подписи (Digital Signature Key, используется для идентификации владельца ключа);

• ключ для шифрования данных (Key Encipherment/Data Encipherment Key, или иначе Key-Exchange Key, ключ, используемый для шифрования данных в процессе проведения транзакции ЭК);

• ключ для подписывания сертификатов (Certificate Signature Key);

• ключ для подписывания списков отозванных сертификатов CRL (CRL Signature Key).

В табл. 4.1 указаны типы ключей, используемых различными участниками транзакции ЭК.

Таблица 4.1 .Типы ключей
Участник	digital	key encipherment/	Cert	CRL
системы ЭК	signature	data encipherment	signature	signature
Владелец карты	X
ТП	X	X
Платежный шлюз	X	X
Cardholder Certificate Authority	X	X	X
Merchant Certificate Authority	X	X	X
Payment Certificate Authority	X	X	X	X

Таблица 4.L

Участник системы ЭК digital signature key encipherment/ data encipherment Cert signature CRL signature Geopolitical Certificate Authority X X Brand Certificate Authority X X Root Certificate Authority X X

Как видно из таблицы, владельцу карты достаточно иметь только один ключ типа Digital Signature Key, в то время как РСА для выполнения своих функций должен иметь ключи всех четырех типов. Далее на примерах процессов сертификации владельца карты в ССА и проведения операции покупки будет продемонстрировано использование различных типов асимметричных ключей.

Разнообразие типов ключей, кроме того, что повышает безопасность системы ЭК в целом, дает больше гибкости при проектировании платежной системы. Это достигается за счет того, что для реализации различных функций появляется возможность использовать ключи различной длины, что повышает производительность системы в целом. Например, ключ ТП Key Exchange Key может иметь более короткую длину по сравнению с ключом ТП Digital Signature Key — для того, чтобы при необходимом уровне криптостойкости уменьшить трудозатраты на выполнение криптографических операций на стороне владельца карты.

Размер асимметричных ключей, используемых в протоколе SET, не фиксирован и может со временем меняться. В настоящее время рекомендуются размеры ключей, приведенные в табл. 4.2.

Таблица 4.2. Рекомендуемые размеры асимметричных ключей

Entity Message Signature Key- Exchange Certificate Signing CRL Signing Владелец карты 1024 ТП 1024 1024 Платежный шлюз 1024 1024 Cardholder СА 1024 1024 1024 Merchant СА 1024 1024 1024 Payment Gateway СА 1024 1024 1024 1024 Brand Geo-political СА 1024 1024 Brand СА 1024 1024 Root СА 2048 2048

Формат сертификата открытого ключа в протоколе SET удовлетворяет стандарту Х.509 v.3. Сертификат содержит следующие данные:

• версию протокола Х.509 (всегда устанавливается значение, равное 3);

• Serial Number — серийный номер сертификата — уникальный целочисленный номер сертификата, присваиваемый ЦС, выдавшим сертификат;

• Algorithm Identifier — идентификатор алгоритма ЭЦП, используемого ЦС для подписывания сертификата;

• Issuer Name — имя ЦС, генерирующего сертификат;

• срок начала действия сертификата;

• срок окончания действия сертификата;

• Subject Name — имя владельца сертификата;

• идентификатор алгоритма, в котором будет использоваться сертифицируемый ключ;

• значение сертифицируемого открытого ключа;

• расширения (например, информация о ключе ЦС — эмитента данного сертификата; уровень владельца сертификата в протоколе SET, тип сертификата (например, сертификат владельца карты, сертификат ТП и т. п.) и другое);

• цифровую подпись сертификата, сделанную с использованием Certificate Signing Key ЦС.

Подлинность SET-сертификатов удостоверяется с помощью иерархической цепи проверок.

Любой ЦС, выдавший сертификат следующему за ним в иерархии звену, в свою очередь, должен иметь действительный сертификат от вышестоящей организации. Удостоверение происходит путем сравнения на предмет равенства содержимого некоторых полей сертификата нижнего уровня и сертификата более высокого уровня. Сравниваются следующие поля:

• поля Issuer Name в сертификате нижнего уровня и Subject Name в сертификате более высокого уровня;

• поля Certlssuer и CertSerialNumber из Х.509 Extensions сертификата нижнего уровня соответственно с полями Issuer Name и Serial Number в сертификате более высокого уровня.

При положительном результате сравнения в сертификате нижнего уровня проверяется:

• срок действия сертификата;

• срок действия ключа, указанного в сертификате;

• уровень владельца сертификата в иерархии системы ЦС;

• соответствие типа сертификата его содержимому;

• использование по назначению ключа, указанного в сертификате, и некоторые другие поля.

В сертификате более высокого уровня проверяется:

• срок действия сертификата;

• срок действия ключа, указанного в сертификате;

• уровень владельца сертификата в иерархии системы ЦС;

• соответствие типа сертификата его содержимому;

• использование по назначению ключа, указанного в сертификате, и некоторые другие поля.

Процедуры генерации, обновления и отзыва сертификатов

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

Чтобы получить сертификат своего открытого ключа, владелец карты направляет специальный запрос в адрес своего ССА В ответ ССА передает владельцу карты сертификат своего открытого ключа.

Владелец карты передает ССА номер своей карты, зашифрованный на открытом ключе ССА, и в ответ получает регистрационную форму, соответствующую данной карте.

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

ССА с помощью эмитента идентифицирует владельца карты и генерирует для него сертификат открытого ключа.

Более детальное описание процедуры генерации сертификата владельца карты будет приведено далее.

Процедура получения сертификата ключа ТП является более простой по сравнению с процедурой генерации сертификата владельца карты. На первом этапе ТП обращается в МСА со специальным запросом на получение сертификата своего открытого ключа.

В ответ ТП получает открытый ключ МСА и регистрационную форму.

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

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

В отличие от владельца карты ТП и платежный шлюз должны получить сертификаты открытых ключей типов Digital Signing Key и Key-Exchange Key.

ЦС уровня End-Entity получают сертификаты своих открытых ключей в цС уровня GCA или ВСА, GCA в ВСА, ВСА в RCA Процедуры получения этих сертификатов не формализованы стандартом SET. Запрос сертификата осуществляется с помощью сообщения формата PKCS# 10, а сертификат от вышестоящего ЦС поступает в формате PKSC#7. Открытый ключ подписи ЦС уровня RCA распространяется среди производителей прикладного программного обеспечения, работающего с протоколом SET. ПО включает сертификат корневого ключа. В отличие от сертификатов участников, этот сертификат подписывается с использованием закрытого корневого ключа подписи. Процедуры обновления сертификатов аналогичны процедурам их генерации. В спецификациях SET говорится о том, что на усмотрение эмитента и/или обслуживающего банка в процедурах обновления сертификатов в регистрационных формах может использоваться информация о старых сертификатах открытых ключей.

Специальная процедура смены ключа предусмотрена для Certificate Signing Key ЦС уровня RCA. Этот корневой ключ подписи сертификатов генерируется в двух экземплярах — действующая пара ключей R, и пара ключей R₂, которая будет действовать после окончания срока действия пары R В сертификате открытого ключа пары R,, подписанном закрытым ключом этой же пары, содержится значение хэш-функции открытого ключа пары R₂. Поэтому, получив новую пару ключей R₂, участник транзакции ЭК проверяет равенство значений хэш-функции нового открытого ключа со значением, содержащемся в старом сертификате. Таким образом подтверждается подлинность полученного нового сертификата открытого ключа подписи.

Рекомендуемые сроки обновления пар асимметричных ключей приведены в табл. 4.3.

Таблица 4.3. Примерные сроки обновления ключей

Участник транзакции ЭК Signature Key- Encipherment Certificate Signature CRL Signature Владелец карты 3 года Торговое предприятие Ігод 1 год Платежный шлюз 1 год Ігод Cardholder СА Ігод ІГОД Ігод Merchant СА 1 год 1 год 1 год Payment Gateway СА 1 год 1 год Ігод 1 год Geopolitical СА 1 год Ігод Brand СА 1 год Ігод Root СА 1 год Ігод

Соответствующие этому примеру сроки хранения сертификатов приведены в табл. 4.4.

Таблица 4.4. Пример периодов хранения сертифи катов

Участник транзакции ЭК Signature Key- Encipherment Certificate Signature CRL Signature Владелец карты 3 год Торговое предприятие ІГОД Ігод Платежный шлюз Ігод Ігод Cardholder СА Ігод Ігод 4 года Merchant СА 1 год 1 года 2 года Payment Gateway СА 1 год Ігод 2 года 2 года Geopolitical СА 5 лет 2 года Brand СА 6 лет 2 года Root СА 7 лет 2 года

Результаты, приведенные в последней таблице, получаются из предположения, что каждый вышестоящий ЦС выдает сертификат нижестоящему ЦС в последний день действия сертификата вышестоящего ЦС. Проиллюстрируем сказанное на примере расчета срока действия сертификата открытого ключа Certificate Signing Key ЦС уровня RCA. Поскольку в нашем примере среди всех участников транзакции ЭК наибольшим сроком действия обладает ключ владельца карточки (3 года), то рассмотрим следующую цепочку. Предположим, что владелец карты получил сертификат своего ключа в последний день действия Certificate Signing Key ЦС уровня CCA, который, в свою очередь, получил сертификат на этот ключ в последний день действия ключа Certificate Signing Key ЦС уровня GCA. ЦС уровня GCA получил свой сертификат для ключа Certificate Signing Key в последний день действия ключа Certificate Signing Key ЦС уровня ВСА, а последний, в свою очередь, получил сертификат на этот ключ в последний день действия сертификата ключа Certificate Signing Key ЦС уровня RCA. В результате для проверки сертификата владельца карты необходимо хранить сертификаты открытых ключей Certificate Signing Key ЦС уровней RCA, ВСА, GCA и CCA соответственно 7, б, 5 и 4 года.

Остановимся теперь на процедурах отзыва сертификатов. Сертификат может быть отозван по одной из следующих причин:

• соответствующий сертификату секретный ключ стал известен злоумышленнику;

• сертификат принадлежит субъекту системы ЦС SET, по каким-либо обстоятельствам прекратившему свое функционирование;

• изменились учетные данные сертификата.

Как уже отмечалось ранее, списки отозванных сертификатов CRL генерируют и поддерживают RCA, ВСА, GCA, PCA. При этом RCA CRL содержит отозванные сертификаты, принадлежащие RCА и ВСА, ВСА CRL содержит отозванные сертификаты GCA, CCA, MCA, PC A, GCA CRL — отозванные сертификаты CCA, MCA, PCA, обслуживаемых данным GCA, PCA CRL — отозванные сертификаты платежных шлюзов, обслуживаемых данным РСА. Список CRL всегда подписывается ЦС, сгенерировавшим данный CRL.

Список отозванных сертификатов CRL содержит следующие поля:

• номер версии CRL (значение равно 2);

• идентификатор алгоритма, с помощью которого подписывается CRL;

• имя ЦС, сгенерировавшего CRL;

• дату генерации CRL;

• дату окончания действия CRL;

• серийные номера отзываемых сертификатов;

• дату начала действия CRL;

• некоторые дополнительные данные (номер CRL, идентификационные данные ключа ЦС, сгенерировавшего CRL, включая имя эмитента ключа и его серийный номер).

Владелец карты должен быть гарантирован от того, чтобы в процессе совершения транзакции ЭК он не использовал отозванный сертифи-

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

• список CRL-C, объединяющий списки RCA CRL, BCA CRL, GCA CRL;

• списки РСА CRL.

Во время проведения транзакции ЭК при получении сертификата шлюза владелец карты проверяет по спискам РСА CRL, не является ли данный сертификат отозванным, а по списку CRL-C для владельцев карты — не является ли отозванным сертификат какого-нибудь ЦС, участвующего в цепочке получения сертификата платежного шлюза.

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

• при использовании протокола SET владелец карты не передает в открытом для ТП виде никакой конфиденциальной информации о реквизитах карты;

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

От владельца карты требуется только проверка по списку CRL-C всех сертификатов, используемых при определении подлинности сертификата ТП.

ТП, так же как и владелец карты, должно уметь определять отозванные сертификаты платежных шлюзов, поскольку именно ТП сообщает владельцу карты сертификаты шлюза в процессе совершения транзакции ЭК.

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

Наконец, платежный шлюз должен проверять по CRL-C отсутствие отозванных сертификатов в цепочке сертификатов ТП и владельца карты. За распространение и хранение списков CRL отвечают ЦС и платежные шлюзы. В процессе выдачи и обновления сертификатов ЦС сооб-9-2103 щают владельцам карт, ТП и платежным шлюзам актуальные на данный момент времени списки CRL. Актуальные списки сообщаются участникам транзакции ЭК и в процессе проведения SET-транзакции. При этом ТП актуализирует списки CRL, получая недостающие списки от платежного шлюза, владелец карты обновляет списки в диалоге с ТП. Кроме того, в рамках SET существует специальная пара сообщений между ТП и платежным шлюзом (Gateway Certificate Request/Response Messages), с помощью которой, в том числе, можно получить обновленные версии списков CRL.

Процедура обновления списков отозванных сертификатов использует каталог всех актуальных на данный момент времени списков CRL в данной платежной системе. Такой каталог называется Brand CRL Identifier (или, сокращенно, BCI). Он состоит из списка номеров всех актуальных на данный момент CRL и подписывается с помощью CRL Signing Key ЦС уровня ВСА. Владельцы карт и ТП получают актуальные значения BCI в процессе сертификации-обновления своих ключей от своих ЦС (соответственно — ССА и МСА), а также во время проведения транзакции ЭК в ответных сообщениях, получаемых, соответственно, от ТП и платежного шлюза. ЦС и платежные шлюзы, в свою очередь, получают BCI вместе со всеми ассоциированными с данным BCI списками CRL из ЦС уровня ВСА. В соответствии с протоколом SET ЦС и платежные шлюзы обязаны обновлять каталог BCI на ежедневной основе.

Каталог BCI используется для избирательного предоставления только недостающих списков CRL. Например, во время проведения транзакции ЭК владелец карты передает ТП данные о каталоге BCI, актуальном для владельца карты на данный момент времени. ТП возвращает в ответном сообщении актуальный каталог, имеющийся на стороне ТП, а также в общем случае не все списки BCI, ассоциированные с данным CRL, а только те списки, которых не хватает владельцу карты. Такая технология позволяет уменьшить объем сообщений, циркулирующих между участниками транзакции ЭК. Каждый ЦС, поддерживающий генерацию списков CRL, передает вновь сгенерированный список в соответствующий ЦС уровня ВСА. RCА также передает CRL, содержащий скомпрометированные корневые ключи, во все во все ЦС уровня ВСА.

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

1. Владелец карты генерирует запрос (в терминах SET — сообщение CardCInitReq), содержащий идентификатор пары сообщений (запроса-ответа на получение сертификата владельцем карты; в терминологии протокола SET — RRPID), идентификатор транзакции (в терминологии SET — LID-EE), генерируемый владельцем карты для учета запроса в системе владельца карты, идентификатор платежной системы (в терминологии SET — Brand ID), случайное число Chall-EE и в качестве параметров «отпечатки» всех сертификатов (включая Root certificate), списков CRL и BCI, хранящихся в системе владельца карты. Под «отпечатком» (по-английски — Thumbprint) здесь понимается значение хэш-функции от соответственно сертификата, CRL, BCI. Хэш-функция применяется для того, чтобы уменьшить объем передаваемой информации, в то же время с высокой вероятностью однозначно идентифицируя хэшируемую информацию.

2. ССА обрабатывает полученное от владельца карты сообщение CardCInitReq, производя следующие проверки:

• проверяет равенство значений RRPID в заголовке и содержимом полученного сообщения;

• запоминает «отпечатки» сертификатов, CRL, BCI из сообщения CardCInitReq, а также LID-EE и Chall-EE.

3. После этого ССА генерирует ответ (в терминологии SET — CInitCardRes), состоящий из подписываемых с помощью ССА Private Signature Key данных. Данные содержат «отпечатки» сертификатов, CRL, BCI из сообщения CardCInitReq, LID-EE, Chall-EE, параметрически идентификатор запроса LID-CA, генерируемый ССА, «отпечаток» сертификата ССА Key-Exchange ключа, сертификаты ССА Key-Exchange Key, CCA Signature Key, а также «отпечаток» BCI в случае, если в сообщении CardCinitreq «отпечаток» BCI отсутствовал. На этом заканчивается этап инициализации получения сертификата владельцем карты.

4. Владелец карты (точнее, конечно, его программное обеспечение), получив сообщение CardCInitRes, проверяет сертификаты ССА Key-Exchange Key и ССА Signature Key, а также цифровую подпись ССА. Поскольку цифровая подпись ССА относится к данным, включающим Chall-EE, ее проверка эквивалентна аутентификации ССА владельцем карты. Таким образом, проверив цифровую подпись, содержащуюся в полученном от ССА сообщении, владелец карты убеждается в том, что в процессе сертификации своего открытого ключа он имеет дело с подлинным центром сертификации.

5. Далее владелец карты передает в адрес ССА запрос на получение регистрационной формы (в терминологии SET — RegFormReq). При формировании этого запроса владелец карты создает данные RegFormReqData, содержащие:

• новый идентификатор RRPID сообщений на запрос/ответ регистрационной формы;

• идентификатор транзакции LID-EE из CardCInitReq;

• новое случайное число Chall-EE2;

• идентификатор транзакции LID-CA, если он присутствовал в сообщении Card СІ nit Res;

• язык, на котором должна быть написана запрашиваемая форма;

• некоторые другие данные, например, «отпечатки» сертификатов, CRL и BCI, содержащиеся в системе владельца карты.

После этого владелец карты по случайному закону генерирует симметричный ключ К_г с помощью которого шифруются данные RegFormReqData. Симметричный ключ К, вместе с номером карты, в свою очередь, закрываются CCA Public Key-Exchange Key и передаются ССА.

6. ССА, получив сообщение RegFormReq, с помощью своего Private Key-Exchange Key расшифровывает номер карты и значение ключа Kj и далее с помощью ключа К_у дешифрует RegFormReqData.

7. По номеру карты и языку владельца карты ССА определяет соответствующую регистрационную форму для владельца карты, подписывает эту форму вместе с другими данными (включая Chall-EE2) своим ключом Private Signature Key и отправляет ее владельцу карлы.

8. Владелец карты вновь проверяет сертификат ключа Private Signature Key и цифровую подпись ССА и производит следующие действия:

• заполняет полученную регистрационную форму, включая в нее свое имя, срок действия карты, адрес (account billing address) и любую другую информацию, которая, по мнению эмитента карты, является необходимой для идентификации владельца карты (например, разовый пароль для идентификации владельца карты);

• генерирует случайное число S,, включаемое в регистрационную форму;

• генерирует по случайному закону пару симметричных ключей

• объединяет заполненную регистрационную форму, Cardholder Public Key и ключ К₂, подписывает эти данные с помощью Private Signature Key и далее шифрует все получившиеся в результате описанных в этом пункте операций данные с помощью ключа К₃;

• ключ К, вместе с номером карты шифруются ключом CCA Public Key-Exchange Key и передаются ССА (это сообщение в терминологии SET называется CertReq).

9. ССА, получив сообщение CertReq, с помощью ССА Private Signature Key расшифровывает значение К₃, далее расшифровывает регистрационную форму и ключ К₂, проверяет цифровую подпись владельца карты. Далее ССА идентифицирует владельца карты (например, по соответствию номера карты разовому паролю, предоставленному ранее эмитентом карты центру сертификации).

ССА генерирует случайное число S₂, которое комбинируется вместе с числом S, для формирования секрета карты S. Значение S хэшируется вместе с номером карты и сроком ее действия в значение, которое используется в сертификате владельца карты (это делается для того, чтобы номер карты не мог стать известным ТП в результате получения сертификата открытого ключа владельца карты). При этом из полученного значения идентификатора сертификата владельца карты невозможно установить номер карты, даже если известен секрет S и срок действия карты. Наоборот, если известен секрет карты, номер карты и срок ее действия, значение идентификатора сертификата вычисляется легко.

После этого ССА создает сертификат открытого ключа владельца карты, подписывая его своим Private Signature Key, и формирует ответ CertRes, содержащий значение S₂, сертификат владельца карты и другую информацию (например, логотип платежной системы и/или банка-эмитента). Сформированное сообщение подписывается ключом К₂ и отправляется владельцу карты.

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

Таким образом, процедура получения сертификата открытого ключа

состоит из трех этапов.

1. Первый этап характеризуется получением владельцем карты недостающих списков CRL и аутентификацией ССА (используется стандартная процедура «рукопожатия», когда владелец карты сообщает ССА некоторое случайное число, а ССА возвращает подписанные им данные, содержащие это случайное число).

2. На втором этапе в защищенной с помощью полученного открытого ключа ССА сессии владелец карты запрашивает в ССА регистрационную форму, сообщая ССА номер своей карты. ССА в зависимости от номера карты предоставляет владельцу карты регистрационную форму.

3. Наконец, на третьем этапе клиент заполняет регистрационную форму, включая в нее свой открытый ключ, и направляет ее владельцу карты. Взамен клиент получает от ССА сертификат открытого ключа и некоторый секрет, используемый для маскирования номера карты в сертификате, а также для дальнейшей аутентификации владельца карты его банком-эмитентом.

Реализация транзакций в протоколе SET

Опишем теперь типы транзакций, используемых в протоколе SET.

В протоколе SET сообщения, с помощью которых реализуются различные транзакции, имеют парный характер (запрос-ответ).

• Payment Initialization Request/Response Messages. Эта пара сообщений используется для взаимной аутентификации владельца карты и ТП, для передачи владельцу карты от ТП необходимых сертификатов и списков CRL, а также предоставления информации ТП о том, карта какой платежной системы будет использоваться при проведении покупки ЭК.

• Purchase Order Request/Response Messages. Эта пара сообщений служит для передачи в защищенной сессии от владельца карты к ТП информации о заказе (сумма покупки, валюта, номер ТП и т. п.) и реквизитах карты владельца карты.

• Authorization Request/Response Messages. Запрос Authorization Request инициируется ТП и передается платежному шлюзу для передачи ему данных по транзакции и реквизитам карты. В дальнейшем эти данные будут использованы для формирования сообщения, передаваемого эмитенту карты через платежную сеть.

• Gateway Certificate Request/Response Messages. Эта пара сообщений позволяет ТП запросить у платежного шлюза его сертификат Key-Exchange Key.

• Batch Administration Request/Response Messages. Эта пара сообщений используется для администрирования наборов (batch) транзакций для того, чтобы ТП и обслуживающий банк могли провести сверку данных каждой стороны (reconciliation). Запрос позволяет открывать новые наборы транзакций, очищать и закрывать существующие наборы транзакций, а также выяснять их статус.

• Inquiry Request/Response Messages. С помощью этой пары сообщений владелец карты может выяснить статус выполнения электронной покупки (получена позитивная авторизация, сделан заказ, в процессе доставки, товар доставлен и т. п.). Inquiry Request может быть отправлен владельцем карты в любое время и любое количество раз.

• Authorization Reversal Request/Response Messages. Пара сообщений используется для того, чтобы отменить ранее проведенную авторизацию. Эта пара сообщений может также использоваться для того, чтобы скорректировать размер транзакции в ранее выполненной авторизации.

• Capture Request/Response Messages. Сообщение Capture Request передается от ТП к платежному шлюзу и запрашивает у обслуживающего банка платеж за сделанную покупку. Размер запрашиваемого платежа должен быть ранее авторизован банком-эмитентом владельца карты с помощью сообщений Authorization Request/Response. Обычно ТП инициирует запрос Capture Request после выполнения заказа, связанного с электронной покупкой.

• Credit Request/Response Messages. Эта пара используется для того, чтобы вернуть ранее сделанный платеж обслуживающего банка в адрес ТП.

• Credit Reversal/Response Messages. Эта пара сообщений позволяет ТП отменить кредит в пользу обслуживающего банка.

Рассмотрим теперь подробнее, каким образом реализуется операция электронной покупки с использованием протокола SET.

Владелец карты инициирует покупку с помощью сообщения PinitReq. В этом сообщении владелец карты передает ТП сформированный им идентификатор пары сообщений PinitReq/PinitRes, идентификатор транзакции LID-C, сгенерированный владельцем карты для учета в системе владельца карты, идентификатор платежной системы Brand ID, карточкой которой владелец карты собирается совершить электронную покупку, BIN карточки (первые 6 цифр номера карты), язык, используемый владельцем карты для совершения операции, параметрически «отпечатки» сертификатов, списков CRL и каталога BCI, хранящихся в системе владельца карты, случайное число Chall-C, сгенерированное владельцем карты, параметрически идентификатор транзакции в системе ТП, использовавшийся в сообщении, инициировавшем систему владельца карты на совершение транзакции.

В ответном сообщении PinitRes ТП формирует следующие данные:

• копирует из запроса владельца карты данные LID-C и язык;

• генерирует глобальный идентификатор транзакции XID;

• копирует из запроса PinitReq «отпечатки» сертификатов, списки отозванных сертификатов, каталоги BCI, Chall-C;

• генерирует случайное число Chall-M;

• на основании Brand ID, BIN и сертификата владельца карты выбирает соответствующий платежный шлюз и вставляет в сообщение сертификат Key-Exchange Key этого платежного шлюза;

• вставляет в сообщение текущий каталог BCI, если в запросе клиента «отпечаток» каталога BCI отсутствовал либо присутствовал «отпечаток» уже неактуального каталога (напомним, что в соответствии с принятыми в протоколе SET соглашениями наряду с BCI в поле CRL данных SignedData передаются также ассоциированные с данным BCI списки CRL);

• некоторые другие данные.

ТП подписывает данные своим закрытым ключом Signing Key и направляет сформированное таким образом сообщение владельцу карты. Остальные этапы реализации электронной покупки будут описаны менее детально.

Владелец карты проверяет полученные сертификаты открытого ключа подписи ТП и открытого ключа Key-Exchange Key платежного шлюза, после чего проверяется цифровая подпись ТП в полученном сообщении. Таким образом, владелец карты аутентифицирует ТП.

После этого владелец карты начинает формирование сообщения PReq. Это сообщение состоит из двух частей: инструкции по заказу (Order Instruction, или сокращенно — OI) и платежной инструкции (Payment Instruction, или сокращенно PI).

OI предназначено для ТП и включает в себя значение Chall-M из сообщения PinitRes, идентификатор транзакции XID, размер транзакции и валюту транзакции, идентификатор ТП, идентификатор batch, к которому должна быть отнесена покупка, номер заказа в системе магазина, хэш-функцию от PI (Н₂) и некоторую другую информацию. PI предназначено для платежного шлюза и включает в себя идентификатор

транзакции XID, величину TranStain, представляющую собой хэш-функцию от секрета карты S и XID, хэш-функцию OI (Н,), параметрически значение CVC2/CVC2,2^ дорожку магнитной полосы карты и другую информацию.

Далее владелец карты вычисляет хэш-функцию от последовательности, состоящей из значений хэш-функции от PI и 01 (Н), и подписывает полученное значение своим секретным ключом.

Владелец карты генерирует случайным образом симметричный ключ К,, с помощью которого он шифрует PL Значение ключа К, вместе с данными по карте (номер карты, срок ее действия и секрет карты), в свою очередь, закрываются с помощью открытого ключа Key-Exchange Key платежного шлюза. Сообщение Preq состоит из OI, зашифрованной инструкции PI, зашифрованных данных о реквизитах карты и ключе К,, цифровой подписи владельца карты.

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

Далее ТП подготавливает сообщение AuthReq. В это сообщение без изменений из сообщения PReq включены зашифрованная платежная инструкция PI, зашифрованный симметричный ключ К, и данные о реквизитах карты, а также цифровая подпись владельца карты. Кроме этих данных ТП формирует авторизационный запрос, содержащий информацию о размере транзакции, идентификаторе ТП, идентификатор транзакции XID, случайное число Chall-P и другую. Эта информация подписывается ключом Signing Key ТП, закрывается симметричным ключом К₂, сгенерированным ТП по случайному закону, который в свою очередь закрывается открытым ключом Key-Exchange Key платежного шлюза.

Платежный шлюз, получив AuthReq, дешифрует с помощью закрытого ключа Key-Exchange Key оба симметричных ключа К, и К₂, а также данные о реквизитах карты, дешифрует данные о транзакции и PI, проверяет подпись владельца карты (по аналогии с тем, как это делает ТП, для этого используется значение Н,, содержащееся в PI), проверяет на 10-2103 равенство значения XID из информации о транзакции и из PL Таким образом, платежный шлюз аутентифицирует как ТП, так и владельца карты. На основании полученных данных платежный шлюз готовит стандартное сообщение (например, в формате ISO 8583) для передачи его в платежную систему на авторизацию эмитента карты.

Получив из платежной системы ответ, платежный шлюз генерирует и подписывает своим закрытым Signing Key сообщение AuthR.es (в сообщении содержится случайная величина Chall-P, также данные Capture Token, в которых платежный шлюз запрашивает у ТП ожидаемые им данные от ТП в сообщении Capture Request). Сообщение зашифровывается с помощью сгенерированного для этого симметричного ключа, который в свою очередь закрывается с помощью открытого ключа ТП.

ТП дешифрует симметричный ключ, проверяет цифровую подпись платежного шлюза и формирует сообщение PRes, содержащее Chall-C, подписывая его своим закрытым Signing Key.

Владелец карты, получив сообщение PRes, проверяет цифровую подпись ТП. На этом процесс электронной покупки может быть закончен. Расчеты между ТП и обслуживающим банком осуществляются либо на основании приведенной ранее схемы электронной покупки, либо на основании дополнительного запроса Capture Request от ТП.

Относительно протокола SET имеют место следующие утверждения. Теорема 1. Протокол SET является устойчивым протоколом ЭК. Доказательство этой теоремы следует из приведенного описания протокола.

Таким образом, SET обладает следующими свойствами:

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

• ТП при выполнении SET-транзакции точно знает, что владелец карты, совершающий транзакцию, является подлинным, то есть обладает секретным ключом RSA, для которого открытый ключ сертифицирован банком-эмитентом клиента.

• Клиент точно знает, что ТП, в котором совершается SET-транзакция, является истинным, то есть обладает секретным ключом RSA, для которого открытый ключ сертифицирован обслуживающим банком ТП.

• ОБ точно знает, что владелец карты и ТП являются подлинными, то есть обладают сертифицированными ключами.

• Информация о реквизитах карты не известна ТП.

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

Теорема 2. Протокол SET является единственным открытым (известным) устойчивым протоколом ЭК.

Сегодня не существует никакого другого (кроме SET) опубликованного устойчивого протокола ЭК. Другими словами, на рынке аппаратно-программных решений, реализующих устойчивый протокол ЭК, не существует альтернативы продуктам, реализующим SET. VISA International предполагает в ближайшее время опубликовать спецификации нового глобального стандарта аутентификации, называемого 3D Secure. Однако неочевидно, что этот стандарт будет определять устойчивый протокол ЭК. Теорема 3. Протокол SETде-факто является отраслевым стандартом в области пластиковых карт.

Будучи признанным ведущими международными платежными системами (VISA, MasterCard, Europay, AmEx, Diners Club) в качестве стандарта ЭК, SET де-факто является отраслевым стандартом.

Таким образом, протокол SET является на сегодняшний день единственным открытым и устойчивым протоколом ЭК.

Расширения стандарта SET

Версия 1.0 стандарта SET была принята в 1997 г. С тех пор протокол получил дальнейшее развитие в виде ряда расширений (сегодня их насчитывается 8).

Наиболее существенными расширениями являются:

• Common Chip Extension (использование микропроцессорных карт, удовлетворяющих стандарту EMV, для проведения электронных покупок на базе протокола SET);

• CVV2/CVC2 Extension (передача данных, используемых для верификации карт, в сообщениях Purchase Request протокола SET);

• Track 2 Data Extension (передача некоторых данных 2-й дорожки магнитной полосы эмитенту);

• On-line PIN Extension (возможность передачи PIN-кода от владельца карты к банку-эмитенту в сообщении Purchase Request протокола SET).

Коротко остановимся на каждом из перечисленных расширений.

Описание Common Chip Extension v.l появилось 29 сентября 1999 г. и носит революционный характер для ЭК (до этого существовало несколько попыток создания стандарта, позволяющего совместить микропроцессорные карты с ЭК). Цель этого расширения — позволить осуществлять SET-транзакции с использованием EMV-карт. Предполагается, что к компьютеру покупателя подключено специальное устройство — карт-ридер, предназначенное для считывания информации с микропроцессорной карты.

Суть расширения состоит в следующем. Приложение клиента на его персональном компьютере (оно называется электронным кошельком, или по-английски wallet) эмулирует функцию POS-терминала в обычных транзакциях покупки по микропроцессорным картам. Оно инициирует EMV-транзакцию, направляя карте команду Select, в которой представляет карте в качестве поддерживаемого приложения приложение, находящееся на карте. Далее приложение клиента передает карте команду Get Processing Options, получая в ответ от карты Application Interface Profile (указания приложению, какие проверки поддерживаются картой) и Application File Locator (указания приложению адресов записей, необходимых ему для процессинга транзакции).

После этого, как в обычном EMV-сценарии, приложение клиента на основании данных Application File Locator с помощью команды Read Record считывает нужные данные и генерирует команду Generate AC, требуя от карлы провести транзакцию в режиме on-line. Карта генерирует криптограмму ARQC (Application Request Cryptogram), используя случайное число Unpredictable Number, переданное ей в качестве параметра команды Generate AC, а также другую информацию, связанную с транзакцией (сумма транзакции, тип транзакции, дата транзакции), терминалом (в нашем случае приложением покупателя — код страны, результаты проверки терминала (Terminal Verification Result)) и картой (счетчик транзакции, результаты проверки карты (Card Verification Result), Application Interface Profile и т. п.). Криптограмма ARQC представляет собой перечисленные выше данные вместе с подписью этих данных, сделанной с помощью алгоритма Triple DES, и симметричным ключом, известным только карте и ее эмитенту.

ARQC помещается в раздел PI и далее шифруются в соответствии со стандартом SET. Эти данные передаются банку-эмитенту для аутентификации карты. Банк-эмитент в соответствии со стандартом EMV проверяет ARQC и подготавливает в ответ сообщение ARPC (Application Response Cryptogram), содержащее код авторизации и подпись банка-эмитента.

Таким образом, применение EMV-карты позволяет обеспечить в операциях ЭК взаимную аутентификацию карты и банка-эмитента. При этом приложение клиента сертификат карты не проверяет. С точки зрения безопасности операции ЭК с использованием EMV-карты приравниваются к SET-транзакциям с сертификатами.

On-line PIN Extension содержит два расширения: расширение для случая, когда PIN-код вводится покупателем через Security Device (PIN-Pad), и расширение, когда PIN-код вводится с клавиатуры PC.

Расширения определяют:

• способы идентификации транзакций ЭК, содержащих PIN-код, а также способ идентификации Internet Payment Gateway, который способен транслировать полученный PIN-код в платежную сеть;

• способ передачи PIN-кода в данных PI сообщения PReq;

• способ передачи некоторых дополнительных Discretionary Data, которые могут использоваться эмитентом при вычислении PIN-кода.

Расширение On-line PIN Extension определяет требования к процедуре расшифровывания PIN-block в Hardware Security Module. Расширение CVV2/CVC2 Extension определяет возможность передачи значений CVC2 (Europay/MasterCard), CVV2 (VISA), FDBC (Four Digit Batch Code — American Express), используемых для верификации карт. Дополнительные данные передаются в специально предназначенном для этого поле раздела PI сообщения PReq протокола SET. Расширение Track 2 Data Extension позволяет ОБ передавать банку-эмитенту три поля со второй дорожки магнитной полосы: Courtly Code, Service-Code и Discretionary-Data (содержимое данных Discretionary-Data полностью определяется эмитентом), что является очень важным фактором, поскольку некоторые сети и банки используют эту информацию для маршрутизации транзакций, а также их авторизации. Данные Discretionary-Data передаются в специально предназначенном для этого поле раздела PI сообщения Purchase Request протокола SET.

Другие расширения протокола SET уже не носят столь общего характера (например, одно из расширений связано с использованием протокола в некоторых японских магазинах, другое — позволяет ТП использовать SET для работы с ОБ, независимо от того, в каком виде был подготовлен запрос на покупку клиентом и т. п.).

Сравнение протоколов SSL и SET

В табл. 4.5 приведены результаты сравнения протоколов SET и SSL по отношению к наиболее вероятным типам мошенничества в ЭК, перечисленным ранее.

Таблица 4.5. Результаты сравнения протоколов SET и SSL

Тип (мошенничества SET решает проблему? SSL решает проблему? Мошеннические транзакции по -правильным* картам Да Нет Злоупотребления магазинов Да Нет Фиктивные магазины Нет Нет Фиктивные банки Да Нет Компрометация данных Да Да

Как видно из табл. 4.5, протокол SSL решает только проблему защиты данных о реквизитах карты.

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

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

Далее перечислены операции, выполняемые на компьютере покупателя и использующие алгоритм RSA

1. Проверка подлинности сертификата ключа Key-Exchange Key платежного шлюза. Сертификат владелец карты получает от ТП в сообщении PinitR.es.

2. Проверка подлинности сертификата ключа Certificate Signature Key PCA платежного шлюза. Сертификат владелец карты получает от ТП в сообщении PinitRes.

3. Проверка подлинности сертификата ключа Certificate Signature Key GCA, подписавшего сертификат ключа Certificate Signature Key PCA платежного шлюза. Сертификат владелец карты получает от ТП в сообщении PinitRes.

4. Проверка подлинности сертификата ключа Message Signing Key ТП. Сертификат владелец карты получает от ТП в сообщении PinitRes.

5. Проверка подлинности сертификата ключа Certificate Signature Key MCA. Сертификат владелец карты получает от ТП в сообщении PinitRes.

6. Проверка подлинности сертификата ключа Certificate Signature Key GCA, подписавшего сертификат ключа Certificate Signature Key MCA. Сертификат владелец карты получает от ТП в сообщении PinitRes.

7. Проверка цифровой подписи ТП. Подпись ТП владелец карты получает от ТП в сообщении PinitRes.

8. Проверка цифровой подписи BCI, полученной владельцем карты от ТП в сообщении PinitRes.

9. Создание подписи (dual message signature) владельцем карты. Подпись вставляется в сообщение Preq, направляемое владельцем карты ТП.

10. Шифрование некоторых данных открытым ключом Key-Exchange Key платежного шлюза. Зашифрованные данные вставляются в сообщение Preq, направляемое владельцем карты ТП.

11. Проверка цифровой подписи ТП, полученной владельцем карты от ТП в сообщении PRes.

12. Проверка цифровой подписи BCI, полученной владельцем карты от ТП в сообщении PRes.

Из перечисленных здесь операций восемь являются обязательными

(номера 1,2,4,5,7,9,10,11), а остальные опционными. Например, one-

рации 3 и 6 используются в том случае, когда соответственно РСА и МСА получают сертификаты своих ключей от Geopolitical Level С А. Кроме того, проверка подписей BCI требуется только в том случае, когда список всех CRL данной платежной системы изменился по отношению к списку, хранящемуся на компьютере покупателя.

Далее отметим, что из 12 перечисленных операций только операция 9 имеет дело с шифрованием закрытым ключом. Все остальные операции представляют собой шифрование открытым ключом. Как мы отмечали в главе «Введение в криптографию», операции на открытом ключе существенно (на порядок) быстрее операции на закрытом ключе. Например, типичное время выполнения операций шифрования с помощью RSA на закрытом ключе с модулем 1024 бита на «рядовом» компьютере с тактовой частотой процессора 200 МГц составляет 0,04 с (25 операций в секунду). Аналогичное время в тех же условиях для операции шифрования на открытом ключе равно 0,002 с, то есть в 20 раз меньше.

Таким образом, время, затрачиваемое персональным компьютером покупателя на криптографические операции при реализации протокола SET, составляет примерно 1,51, где t — время, необходимое компьютеру на выполнение шифрования на закрытом ключе.

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

Аналогичный анализ можно провести для сервера ТП и платежного шлюза. Такой анализ был выполнен в работе Gartner Group «SET Comparative Performance Analysis». Анализ основан на более грубой модели по сравнению с рассмотренной здесь. В частности, модель не учитывает разницу в вычислительных затратах между шифрованием на открытом и закрытом ключах. Кроме того, предполагается, что в протоколе SSL при совершении покупки используются только авторизационные запросы. Считается, что финансовые сообщения, требующие возмещения средств за выполненный заказ, при использовании SSL не применяются, хотя никакой связи между технологией совершения покупки (Single Message Mode и Dual Message Mode) и применяемым при этом протоколом не существует. В то же время в целом анализ дает представление о том, что разница в стоимости серверов ЭК в зависимости от того, какой протокол используется, начинает возникать только при больших объемах ЭК (более 200 транзакций в секунду на сервер). При нагрузке, равной 200-400 транзакций в секунду, разница в стоимости сервера составляет всего 5 %!

В то же время проблема обеспечения производительности серверов при больших нагрузках является актуальной. В этом направлении значительных успехов добились компании Compaq Atalla и Rainbow Technologies.

Остановимся на криптографических устройствах первой компании. Продукты Atalla используются в крупнейших процессинговых центрах мира, обеспечивая защиту финансовых транзакций. Криптографические модули выпускаются в двух видах: PCI-карты и отдельного устройства. Независимо от внешнего вида модули обязательно удовлетворяют стандарту физической безопасности FIPS 140-1 Level 3. Модули защищены специальным корпусом, взлом которого приведет к самоуничтожению всей памяти. Внутри корпуса расположены датчики удара, температуры и напряжения.

Среди различных моделей криптографических устройств для приложений, связанных с Интернетом, наиболее распространены AXL200 и PayMaster. PCI-карта Atalla AXL200 представляет собой математический ускоритель, содержащий 8 отдельных математических сопроцессоров и позволяющий на несколько порядков повысить производительность Web-сервера, использующего SSL. Производительность карты составляет 240 SSL-подключений в секунду. Модуль AXL200 не хранит ключи и потому не является криптографическим модулем (не поддерживает стандарт FIPS 140-1 Level 3).

Устройство PayMaster обеспечивает ускорение и дополнительную защиту решений, использующих протокол SET. Устройство выпускается в виде либо PCI-карты, либо отдельного модуля, подключенного к компьютеру через Ethernet. Модуль работает в операционных средах Windows NT, Windows 2000, Compaq True64 Unix, Sun Solaris. Устройство позволяет осуществлять 43 операции шифрования RSА с ключом 1024 бита в секунду.

Переходные модели от SSL к SET. Концепция Server Based Wallet

Для платежных систем разработана модель плавного постепенного перехода от наиболее популярного сегодня протокола ЭК — SSL к стандарту SET.

Модель SSL End-to-End Payment

Данная модель соответствует наиболее массовой на сегодняшний день технологии проведения транзакций ЭК, основанной на использовании протокола SSL (рис. 4.2).

Торговое предприятие

Web-сервер

Владелец карты

SSL

Web-браузер

SSL

Payment

Gateway

Эмитент

Обслуживающий банк

Платежная сеть

Рис. 4.2. Модель SSL End-to-End Payment

В основе данной модели лежат следующие принципы:

• взаимодействие ТП и покупателя в процессе ЭК осуществляется с помощью протокола SSL;

• взаимодействие ТП и ОБ также происходит с помощью протокола SSL.

Недостатки данной модели с точки зрения безопасности транзакции ЭК подробно обсуждались при описании протокола SSL. Модель рассматривается в качестве отправной точки процесса миграции от SSL к SET.

Модель MOSET (SET 2KP)

Данная модель представляет собой промежуточный этап развития ЭК от SSL к SET (рис. 4.3).

MOSET (Merchant Originated SET)

Владелец карты'

SSL

Торговое предприятие

(4nternet^)

Web-сервер

Web-браузер

MOSET

Internet

SET Payment Gateway

Эмитент

Обслуживающим банк

Платежная сеть

Рис. 4.3. Модель MOSET

В ее основе лежат следующие принципы:

• взаимодействие ТП и покупателя в процессе ЭК по-прежнему осуществляется с помощью протокола SSL;

• взаимодействие ТП и ОБ происходит с помощью протокола SET. При этом ТП и ОБ, представленный в системе ЭК платежным шлюзом, в соответствии с протоколом SET, имеют цифровые сертификаты ключей.

Таким образом, в соответствии с моделью MOSET ТП предает платежному шлюзу сообщения в формате протокола SET (отсюда название модели Merchant Originated SET или 2 Certificate Keepers Model). Очевидно, внедрять модель MOSET проще, чем «полный» SET, поскольку не требуется решать достаточно сложную задачу распределения клиентского ПО и удаленной сертификации клиентов (для продавцов эта задача не является столь трудной из-за того, что количество их клиентов существенно меньше).

Рассматриваемая модель имеет те же недостатки, что и модель SSL End-to-End Payments. В частности, при ее использовании по-прежнему не гарантирован возврат средств ТП за проведенную в нем операцию электронной покупки.

Модель Full SET Payment (или ЗКР)

Данная модель представляет собой конечный этап развития ЭК от SSL к SET (рис. 4.4).

Full Set (ЗКР SET)

Владелец карты

SET ЗКР

Interne!

Торговое предприятие

Internet

SETЗКР

PGW

SET Payment

Gateway

Эмитент

Обслуживающий банк

Платежная сетъ

Рис. 4.4. Модель Full SET Payment

В ее основе лежат следующие принципы:

• взаимодействие ТП и покупателя в процессе ЭК осуществляется с помощью протокола SET;

• взаимодействие ТП и ОБ происходит с помощью протокола SET. При этом все субъекты ЭК — покупатель, ТП и ОБ (IPG) имеют цифровые сертификаты ключей (отсюда альтернативное название модели ЗКР — Certificate Keepers Model).

Модель ЗКР обладает всеми перечисленными ранее преимуществами протокола SET. В частности, в этом случае торговому предприятию гарантируется возврат средств за оказанную им услугу ЭК.

Одна из проблем внедрения протокола SET заключается в сложности задачи распределения клиентского ПО и организации удаленной сертификации клиентов.

Для решения этих задач международные платежные системы рекомендуют банкам-эмитентам использовать в качестве решения для электронного бумажника (Wallet) вместо стандартной модели PC Based Wallet (модель подразумевает установку специализированного ПО на рабочем месте клиента) модель Server Based Wallet.

В соответствии с этой моделью функции SET от лица клиента поддерживаются на отдельном сервере его банка-эмитента (Server Based Wallet). Защищенная связь между банком-эмитентом и клиентом осуществляется с помощью протокола SSL (для надежной идентификации клиента может использоваться любой алгоритм, выбранный банком-эмитентом, например идентификация клиента по User ID+Password). При этом клиент должен иметь ПО Thin Wallet, основные функции которого заключаются в реализации взаимной аутентификации клиента и его банка-эмитента, а также в «переадресации» на сервер эмитента так называемых сообщений wake-up message от ТП. Модель Server Based Wallet показана на рис. 4.5.

Торговое предприятие	POS
4	1	L 11
Payment Yateway
5 1		10
Обслуживающий банк	9 4 J П 6 V.

Владелец карты

Thin > Wallet

Браузер

Server Wallet

Эмитект

Рис. 4.5. Модель Server Based Wallet

Подход Server Based Wallet имеет ряд важных преимуществ:

• облегчает поставку ПО Wallet клиентам через Интернет; размер бумажника сегодня составляет 2,8-4,5 Мбайт. Это приводит к тому,

что время загрузки ПО довольно велико — 20 минут и более; в то же время ПО Thin Wallet имеет объем до 70 Кбайт со временем загрузки 20 секунд;

• облегчает инсталляцию и использование ПО бумажника (из-за сложности ПО PC Based Wallet по опыту служб поддержки на одну инсталляцию приходится от 2 до 5 звонков клиента);

• повышает безопасность хранения ключевой информации клиента, поскольку решение Server Based Solution использует для хранения закрытых данных специализированные Tamper-Resistant Hardware Security Module;

• упрощает задачу модернизации ПО электронного бумажника (замену текущей версии новой);

• способствует решению задачи совместимости компонентов протокола SET;

• улучшает операционные показатели обработки транзакции ЭК;

• позволяет клиенту использовать различные средства доступа к Интернету (в частности, мобильные телефоны, Set-Top-Box, PDA и т. п.).

Сегодня концепция Server Based Wallet является основной при построении платежных систем ЭК. В частности, эта концепция лежит в основе протокола 3D SET (см. далее), признанного на сегодняшний день основной формой внедрения стандарта SET.

Иногда между моделями 2КР и ЗКР рассматривается вариант использования покупателем протокола SET без сертификатов. Этот вариант по своей природе относится к классу 2КР (в данном случае с точки безопасности совершенно все равно, какой протокол использует клиент — SSL или SET).

Модель SET+Common Chip Extension

Эта модель предполагает внедрение расширения Common Chip Extension, описанного ранее. Данное расширение обеспечивает тот же уровень безопасности ЭК, что и Full SET, но помимо того естественным способом решает проблему сертификации открытого ключа покупателя, а также снижает требования к вычислительным характеристикам устройства, поддерживающего электронный бумажник.

Концепция Server Based Wallet, дополненная применением смарт-карт в качестве средства платежа покупателя, является по признанию международных платежных систем наиболее перспективной технологией развития ЭК. Смарт-карта является универсальным защищенным средством оплаты товара и может использоваться при проведении транзакции ЭК через все известные на сегодня каналы генерации транзакции, включая PC, STB-устройства, GSM-телефоны.

Важным фактором для распространения использования смарт-карт в ЭК является наличие на рынке дешевых карт-ридеров (считывателей смарт-карт). Сегодня цена такого устройства составляет более $20—30. В рамках международного проекта FINREAD, поддерживаемого банковскими структурами, решается задача разработки относительно дешевого считывателя смарт-карт, стоимость которого не должна превышать $10-15.

Другой важный вопрос — стандартизация интерфейса между смарт-картой и приложением компьютера, использующим смарт-карту. В 1997 г. международной группой компаний (Bull CP8, Gemplus, Hewlett Packard, IBM, Microsoft, Schlumberger, Siemens Nixdorf, Sun Microsystems, Toshiba и VeriFone) были разработаны спецификации PC/SC (Personal Computer/Smart Card). Спецификации определяют среду для использования смарт-карт в персональных компьютерах общего назначения. Они платформонезависимы и могут реализовываться на таких платформах, как Unix, Windows, Mac/OS и т. п.

Модель SSET

Модель SSET будет описана далее и в силу изложенных в том же параграфе причин является наиболее интересной моделью перехода к протоколу SET.

Технологические компоненты электронной коммерции и предлагаемые на рынке решения

Сразу после появления спецификаций протокола SET многие разработчики приступили к созданию реализующего его программного обеспечения. Сегодня на рынке присутствует около 50 программных продуктов, реализующих SET от более чем 20 производителей. Среди лидеров в этом направлении следует назвать компании Globeset (в конце 2000 г. компания была приобретена Trintech), IBM, Hewlett-Packard/ VeriFone, Trintech и Brokat.

Все известные сегодня программные продукты ЭК состоят из четырех компонентов: программного обеспечения покупателя — электронного бумажника (Wallet), ТП (POS), платежного шлюза (Payment Gateway) и центра сертификации (Certificate Authority).

Основные функции перечисленных компонентов состоят в следующем:

• Центр сертификации производит регистрацию и сертификацию открытых ключей ТП, владельцев карты и платежных шлюзов. Процедуры удаленной сертификации всех участников транзакции ЭК определены в протоколе SET.

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

Существуют две основные разновидности электронного бумажника — PC-based Wallet и Thin Wallet (клиентская часть в концепции Server Based Wallet). Как уже отмечалось, концепция «тонкого» бумажника сегодня является доминирующей.

Наиболее распространенными платформами для реализации ПО электронного бумажника покупателя являются Windows '95/98/2000, Windows NT 4.0. В табл. 4.6 приведены минимальные и рекомендуемые параметры PC покупателя, необходимые для выполнения электронной покупки.

Таблица 4.6. Минимальные и рекомендуемые параметры компьютера покупателя

Минимальные параметры Рекомендуемые параметры * 486 PC Pentium * 16 MB RAM * 32 MB RAM ¦ 540 MB Hard Disk * 1GB Hard Disk * 14,4 Kb/s Modem ¦ 28,8 Kb/s Modem * Colour Monitor * Colour Monitor

Программное обеспечение ТП обеспечивает оплату товаров по кредитным картам. С одной стороны, это ПО поддерживает связь с электронным бумажником покупателя, а с другой — с платежным шлюзом. Наиболее часто используемые операционные системы для сервера продавца — Windows NT, Unix, OS/2.

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

Далее будут рассмотрены решения для системы ЭК таких известных компаний, как IBM, GlobeSet, Hewlett-Packard и ACL

Решение компании ACI

Компания ACI предлагает для организации ЭК использовать программное решение е-24 Commerce Solutions, являющееся объединением решений компании Globeset (в части протокола SET) и ACI (в части протокола SSL).

Решение е-24 Commerce Solutions основано на использовании классической архитектуры системы ЭК. В состав системы входят:

• e24-merchant link, программный компонент, реализующий SET-co-вместимый интерфейс между электронным бумажником клиента и ТП; компонент инициирует электронный бумажник клиента на проведение оплаты по протоколу SET и обеспечивает проведение оплаты;

• e24-gateway, программная компонента, реализующая интерфейс между платежным сервером (Payment Server) и Acquirer Host; данный компонент осуществляет конвертацию SET-транзакций в формат стандартного межхостового интерфейса ISO 8583;

• e24-wallet, программный компонент, реализующий функции Server Based Wallet;

• e24-registration authority, программный компонент, обеспечивающий генерацию и распределение сертификатов открытых ключей ТП и клиентов банка-эмитента.

Перечисленные выше компоненты дополняются также следующими программными модулями:

• e24-portal, программный компонент, обеспечивающий параллельную обработку транзакций, поступающих от многочисленных ТП, а также доступ ТП к серверам системы ЭК с помощью SSL browserbased-интерфейсов для получения различной информации (например, информации об истории транзакций данного клиента);

• e24-risk, программный компонент, позволяющий обнаруживать мошеннические транзакции ЭК; система является rules-based системой (решение о подозрительности транзакции на мошенничество принимается на основе проверки предварительно определенного набора критериев), использует несколько критериев анализа транзакции на мошенничество, включая Luhn Check parity-проверку (проверка необходимого условия правильности номера карты), алгоритм VISA Address Verification System, соответствие номера карты имени ее владельца, частотный анализ использования карты, частотный анализ использования отдельных BIN; компонент e24-risk обеспечивает мониторинг транзакций в режиме реального времени, а также предоставляет различные batch-отчеты по результатам мониторинга; ОБ имеют возможность конструировать форму отчетов по своему усмотрению.

Компоненты e24-portal, e24-merchant, e24-risk могут быть реализованы на отдельном сервере, называемом Payment Server. Программный компонент е24-gateway реализуется на другом сервере, называемом Payment Gateway. Наконец, компонент e24-certificate authority реализуется на третьем сервере (также возможно распределение отдельных функций Certificate Authority между серверами электронного бумажника и шлюза).

Решение компании IBM

Компания IBM предлагает для организации системы ЭК использовать аппаратно-программное решение IBM Payment Suite.

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

• IBM Consumer Wallet;

• IBM Payment Server;

• IBM Payment Gateway;

• IBM Payment Registry.

IBM Payment Server, версия 1.2 (5765-E43) обеспечивает проведение платежей между бумажником покупателя (IBM Consumer Wallet) и ТП через Интернет. Разработанный как составной компонент IBM Payment Suite, сервер платежей IBM Payment Server в то же время работает с различными продуктами в области платежных приложений от других поставщиков, что позволяет создать комплексную систему обработки платежей в Интернете.

Сервер платежей IBM Payment Server управляет записями со сведениями о транзакциях, хранит информацию о платежах и взаимодейству-

ет с финансовыми учреждениями для авторизации платежей, возврате денежных средств, помещении денег на депозиты и прочих финансовых транзакциях.

Сервер IBM Payment Server написан на языке программирования Java и использует модульную архитектуру, что обеспечивает его интеграцию с различными имеющимися у продавцов серверными продуктами и средами деловой обработки данных.

Сервер IBM Payment Server поддерживается на нескольких аппаратных платформах, включая системы IBM AIX, IBM OS/400, IBM OS/390, Microsoft Windows NT и Sun Solaris. Выполненный на базе открытой, основанной на использовании стандартов технологии, сервер IBM Payment Server поддерживает несколько протоколов платежей, включая:

• SET;

• Merchant originated SET (MO SET);

• SSL.

Шлюз IBM Payment Gateway (5648-D20 PN И К6384 WebSphere Payment Manager) выполняет функцию посредника между торговыми Web-серверами и финансовыми учреждениями. Payment Gateway поддерживает протоколы SET и Secure Sockets Layer (SSL). Шлюз включает в себя утилиты для преобразования сообщений, поступающих от Интернет-магазинов, в формат ISO 8583. Кроме того, Payment Gateway реализует маршрутизацию сообщений в различные финансовые учреждения.

В основе Payment Gateway лежит комплексное программное обеспечение маршрутизации транзакций, которое использовалось для обработки сообщений в самых различных средах на протяжении более чем десяти лет.

В качестве электронного бумажника покупателя предлагается продукт IBM Consumer Wallet (5639-115 PN 11K5996 IBM Consumer Wallet). Бумажник представляет собой приложение, реализующее протоколы SSL и SET, и поддерживает язык ECML, что существенно упрощает для клиента процедуру оформления заказа.

Электронный бумажник позволяет распространять торговую марку любого учреждения с помощью специального настраиваемого процесса работы с торговыми марками.

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

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

Электронный бумажник распространяется на CD-ROM или дискетах. IBM Payment Registry (5697-C83 IBM Payment Registry 1.2) выполняет функции центра сертификации, поддерживая уровни Geopolitical Certificate Authority, Cardholder Certificate Authority, Merchant Certificate Authority и Payment Gateway Certificate Authority. Решение IBM Payment Registry реализуется на аппаратной платформе RS/6000.

Помимо компонентов, обеспечивающих электронные расчеты, IBM предоставляет решения для Storefront ТП, описанные далее.

IBM Net.Commerce — набор интегрированных между собой программных компонентов, которые представляют собой решение для организации продаж товаров или услуг через Интернет-магазин. Система поставляется с готовыми шаблонами электронных каталогов, мастерами по установке и дополнительными инструментами поддержки каталога, что позволяет создать сайт электронного магазина. Продукт Net.Commerce предоставляет также средства для создания приложений, ориентированных на организацию взаимодействия между компаниями. Семейство IBM Net.Commerce дает возможность:

• управлять процессом регистрации и электронной адресной книгой;

• проверять и обновлять списки товаров;

• контролировать обработку заказов;

• рассчитывать стоимость, налоги и определять конечную цену товара;

• предлагать скидки определенным категориям пользователей;

• отслеживать доставку товара, проверять экспортные ограничения и рассчитывать стоимость грузоперевозок;

• применять различные методы расчета налогов с продаж или стоимость грузоперевозок для различных регионов и международных заказов;

• проверять достоверность платежной информации;

• использовать информацию из локальных баз данных;

• создавать несколько коммерческих серверов на одной физической машине.

Продукт IBM Net.Commerce PRO является решением для построения Web-сайта крупного электронного магазина. Пакет включает в себя функции IBM Net.Commerce плюс:

• Расширенные инструменты поддержки каталога (Advanced Catalog Tools) позволяют существенно расширить навигацию по каталогу и предоставляют возможность настройки функций просмотра и поиска для отдельных категорий пользователей. Продавец может создать интеллектуальные средства поиска, которые помогут покупателям находить соответствующие разделы каталога.

• Расширенный поиск (Intelligent searching) — позволяет искать с помощью выбора наиболее важных параметров продукта, что очень существенно сужает результаты поиска и сразу отбрасывает все, что не удовлетворяет потребностям покупателя. Покупатель имеет возможность указывать в критерии поиска такие условия, как «равно», «не равно», «диапазон», «больше чем», «меньше чем».

• Средства интеграции — они существенно облегчают процесс интеграции Net.Commerce с такими системами, как Electronic Data Interchange (EDI), IBM CICS, MQSeries, IMS, SAP.

Продукт IBM Catalog Architect позволяет управлять каталогом товаров с высокой степенью детализации по сравнению с традиционными способами. Продукт специально спроектирован для поддержки электронной коммерции, основанной на использовании серверного программного обеспечения IBM Net.Commerce. Пакет Catalog Architect может использоваться совместно с IBM Net.Commerce v3.1.2 START или PRO. Все компоненты решения IBM сертифицированы в SETCo.

Решение компании Hewlett-Packard

Решение компании Hewlett-Packard (HP) Integrated Payment System (IPS) Solution основано на использовании следующих программных компонентов:

• IPS Payment Gateway (функционирует под HP/UX 11.0);

• vPOS (функционирует под Windows NT 4.0);

• vWallet (функционирует под Windows 95, Windows NT 4.0).

Все перечисленные компоненты прошли сертификацию в SETCo и поддерживают специальный Mark Up язык PTML (Payment Transaction Markup Language), созданный на основе языка XML. Язык PTML позволяет строить эффективное взаимодействие между отдельными компонентами системы, а также обеспечивает развитие системы. Система IPS полностью соответствует классической модели ЭК, и потому функции ее отдельных компонентов следуют из их названий. В частности, IPS Payment Gateway представляет собой платежный шлюз, vPOS является платежным сервером ТП, a vWallet — PC-based электронным бумажником покупателя.

IPS Payment Gateway для обработки транзакций поддерживает протоколы SET и SSL, выполняет функцию конвертации сообщений из SET/SSL в формат сообщений платежных систем (поддерживаются VISA BASE I, MasterCard ISO 8583, в качестве коммуникационных протоколов используются Х.25, TCP/IP), а также функцию маршрутизации транзакций в различные финансовые институты. IPS Payment Gateway способен одновременно обрабатывать до 16 транзакций, что позволяет обеспечить производительность около 300—500 тыс. транзакций в день.

Решение vPOS является полнофункциональным, поддерживая протоколы SSL и SET. Оно легко интегрируется в такие распространенные решения для Storefront, как Microsoft Site Server Commerce Edition, Oracle Merchant Server, iCat и Intershop.

Компания HP не имеет собственного решения для центра сертификации и предлагает решение своего партнера — компании CyberTrust. Данное решение является одним из наиболее полнофункциональных решений для центра сертификации. Центр сертификации CyberTrust поддерживает не только процедуры получения сертификатов, описанные в стандарте SET, но и решает задачи выдачи разнообразных сертификатов для схем SSL, а также для проектов по смарт-картам и т. д.

Компания HP не имеет собственного решения для Server Based Wallet и в качестве такового предлагает решение компании GlobeSet, являющееся по мнению многих экспертов лучшим решением Server Based Wallet в мире.

Решение компании Globeset (Trintech)

Решение компании Globeset основано на использовании следующих программных компонентов:

• центра сертификации Certificate Authority (CA);

• платежного шлюза Payment Gateway;

• платежного сервера ServerPOS;

• сервера эмитента ServerWallet.

Все перечисленные компоненты прошли сертификацию в SETCo. Центр сертификации Certificate Authority представляет собой SET-приложение для управления сертификатами (генерация, обновления и отзыв сертификатов) торговых предприятий, платежных шлюзов и владельцев карт. Функции GCA (Geopolitical Level в иерархии SET) ЦС не поддерживаются.

Центр сертификации имеет административный интерфейс, позволяющий администраторам получать доступ и конфигурировать С A Databases (поддерживаются БД Oracle, Microsoft SQL Server и Sybase).

Компания Globeset предоставляет пользователям программные модули Software Development Kit (SDK), позволяющие адаптировать центр сертификации под индивидуальные требования банка.

Решение Globeset предлагает пользователям использовать вместе с центром сертификации приложение СА Administration Manager. С A Ad m i nistration Manager представляет собой Java-приложение, позволяющее:

• стартовать, останавливать и рестартовать сервер центра сертификации;

• конфигурировать лог-файлы сервера, его адреса, порты и БД;

• просматривать лог-файлы сервера;

• добавлять и удалять банки;

• добавлять и удалять карточные продукты.

Центр сертификации поддерживает работу с HSM, использует длины RSA-ключей, равные 1024 и 2048 битов. Центр поддерживает процедуры генерации, обновления и отзыва сертификатов в соответствии с требованиями стандарта SET.

Центр сертификации может функционировать на платформах Windows NT 4.0 и Sun Solaris 2.6.

Платежный шлюз Payment Gateway представляет собой шлюз между платежным сервером и платежной сетью. Шлюз поддерживает протокол SET 1.0 для работы с ServerPOS и несколько различных подключений к хостам обслуживающих банков (допускается, по крайней мере, три соединения по протоколу ISO 8583).

Шлюз Payment Gateway не поддерживает функций мониторинга и контроля безопасности транзакций ЭК. Однако Payment Gateway обеспечивает подключение и адаптацию к службам обнаружения мошенничеств (fraud detection services), поддерживаемых другими приложениями.

Шлюз Payment Gateway поддерживает работу с различными криптографическими ускорителями (cryptographic accelerator) и/или Hardware Security Modules (HSM).

Решение предлагается на платформах NT и Solaris. Имеется поддержка СУБД Oracle, Microsoft SQL Server и Sybase.

Шлюз Payment Gateway поддерживает административный интерфейс, используемый для его конфигурирования, а также для удаленного доступа к функциям Administration Manager. Это позволяет осуществлять запуск, остановку и рестарт сервера, анализировать лог-файлы, конфигурировать порты, БД и т. п.

Компания Globeset предоставляет пользователям программное обеспечение Software Development Kit (SDK), позволяющее адаптировать шлюз под индивидуальные требования банка.

Платежный сервер ServerPOS поддерживает SET 1.0 транзакции. Сервер может функционировать в режиме MOSET, когда в качестве протокола между покупателем и ТП используется SSL.

Сегодня ServerPOS не поддерживает функции мониторинга и контроля безопасности транзакций ЭК (transaction risk detection).

Сервер ServerPOS может функционировать вместе с криптографическими ускорителями и/или Hardware Security Module (HSM).

Сервер ServerPOS поддерживает административный интерфейс, используемый для конфигурирования платежного сервера, а также для удаленного доступа к функциям Administration Manager.

Компания Globeset предоставляет пользователям средства SDK, позволяющие адаптировать платежный сервер под индивидуальные требования банка.

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

Сервер поддерживает программный интерфейс eLink, позволяющий осуществлять простую интеграцию между merchant storefront и ServerPOS thin-client.

ServerPOS 1.4 поддерживает стандартный набор интерфейсов к системам ТП (merchant adapter):

• Microsoft Site Server Commerce Edition 3.0;

• Vision Factory Cat@log 2.5;

• INTERSHOP4;

• Generic CGI.

Наряду с решением ServerPOS компания Globeset поддерживает решение MPOS, предназначенное для выполнения транзакций ЭК по протоколу SET. Решение предназначено для организации расчетов по транзакциям отдельного электронного ТП.

Компания Globeset предлагает решение Server Based Wallet. ServerWallet может поддерживать и хранить информацию о практически неограниченном количестве карт, а также обрабатывать связанные с этими картами транзакции. Решение допускает распределение входящей нагрузки транзакций ЭК между несколькими серверами.

ServerWallet поддерживает модули HSM и криптографические ускорители для повышения безопасности и производительности операций ЭК. Все криптографические операции выполняются внутри модулей HSM.

С помощью ServerWallet банк-эмитент имеет возможность легко производить модификацию версии тонкого бумажника (thin client), установленного на компьютере владельца карты. Когда клиент для совершения транзакции электронной покупки обращается к ServerWallet, сервер определяет, что поддерживаемая клиентом версия электронного бумажника не соответствует последней, и направляет клиента на специальный сайт за получением новой версии thin wallet.

Сервер ServerWallet использует протокол SSL для защиты коммуникаций между бумажником владельца карты и сервером. Протокол SSL на сервере ServerWallet реализуется с помощью стандартной функции Netscape Enterprise Server или IIS.

Анализ представленных решений

С точки зрения функциональности все рассмотренные решения являются полнофункциональными (поддерживают все компоненты системы ЭК). Но каждое из предложенных решений обладает своими особенностями. Только компания Globeset обладает собственным (и, как нам известно из других источников, лучшим на рынке) решением Server Based Wallet.

11-2103

В решениях HP и ACI в качестве Server Based Wallet используется решение Globeset.

Лучшее и наиболее функциональное решение для центра сертификации предлагает CyberTrust. Как уже отмечалось, это решение может использоваться для решения практически всех известных задач, связанных с PKI.

Что касается платежного сервера, то здесь следует выделить решение Globeset. Концепция «тонкого» клиента, лежащая в основе сервера ServerPOS, обладает теми же преимуществами, что и технология ServerWallet. TTT устанавливает на своем сервере небольшой по размеру программный модуль, обеспечивающий взаимодействие «витрины» магазина с ServerPOS. Вся нагрузка, связанная с реализацией протокола SET, ложится на ServerPOS. В результате ослабляются требования к аппаратным средствам, на которых реализована витрина ТП. Это, а также отсутствие необходимости покупки ПО ТП, реализующего протокол SET, ведет к уменьшению затрат ТП на внедрение SET. Необходимо также отметить, что концепция «тонкого» клиента для платежного сервера является эталонной в интерпретации компании VISA модели 3D SET, хотя сама по себе концепция трех доменов не требует использования ServerPOS.

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

Следует отметить, что среди рассмотренных решений «решения под ключ» (поставка ПО и вычислительных систем) предлагают только HP и IBM. При построении крупномасштабной системы это преимущество может иметь большое значение.

Очевидно, что «лучшее» решение зависит от целей и масштабов проекта. Вполне возможно, что такое решение окажется комбинированным. Например, для крупномасштабного проекта, ориентированного на массового покупателя, решение может быть таким: центр сертификации строится на основе решения CyberTrust, кошелек покупателя — на основе решения Globeset, а остальные компоненты решения и вычислительные средства — на основе решения IBM.

Анализ затрат на создание системы электронной коммерции, окупаемости системы и сроков реализации проекта

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

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

• в процессинге транзакций, сгенерированных в Интернет-магазинах (захват транзакции и ее доставка соответствующему обслуживающему банку для проведения авторизации);

• в организации подключения Интернет-магазинов к системе ЭК;

• в сопровождении сайтов магазинов (функция Application Service Provider и аутсорсинга на сопровождение электронных магазинов);

• в установке Server-based Wallet для банков-участников системы ЭК;

• в работе с банками по их привлечению в систему ЭК;

• в поддержке аппаратно-программных комплексов ЭК;

• в дистрибуции решений ЭК для торговых предприятий и банков-эмитентов (электронные бумажники, платежные серверы и т. д.).

Примерная структура Процессинговой компании:

• Руководство компании — 1

• Финансовые специалисты — 2

• Юрисконсульт — 1

• Кадры — 1

• Отдел сопровождения прикладного программного обеспечения (ППО) и системных средств — 10

• Отдел по работе с торговыми предприятиями — 15

• Отдел информационной безопасности — 2

• Отдел банковского маркетинга — 4

• Охрана —6 Итого: 42 человека.

Приведем примерный бюджет Процессинговой компании. Капитальные затраты:

• построение машинного зала, создание структурированной кабельной сети, приобретение средств связи и телекоммуникаций (LAN/ WAN) - $250 000;

• приобретение и инсталляция аппаратно-программных платформ для Internet Payment Gateway, 100 магазинов на 10 Web-сайтах и 5 Server Based Wallet&Certificate Authority - $1 100 000;

• оснащение офисных помещений на 40 человек мебелью, организационной и вычислительной техникой - $80 000;

• PR-акции - $70 000.

Итого: $1 500 000;

Текущие ежемесячныерасходы:

• ФЗП (40 чел. х 900$) - $36 000;

• Налог на ФЗП и подоходный налог - $25 200;

• Плата за поддержку аппаратных средств и программных средств -$10 000;

• Аренда помещений - $10 000;

• Телекоммуникационные услуги - (стоимость канала ежемесячно + трафик) - $3 000;

• Электроэнергия - $500;

• Коммунальные услуги - $200;

• Факсимильная/телефонная связь - $200;

• Канцелярские расходы - $150;

• Реклама, связи с общественностью - $300;

• Накладные расходы (10%) - $6 000;

Итого: - $92 000

Далее рассматривается следующая модель окупаемости системы.

В таблице 4.7 по годам приведены объемы транзакций ЭК, обрабатываемых в системе, а также доходы, получаемые за процессинг (предполагается, что компания оставляет себе 1% от размера транзакции; средний размер транзакций в 2001 и 2002 гг. предполагался равным $ 25, а та же величина, начиная с 2003 г., в связи с появлением более безопасной инфраструктуры SET, станет равна $50).

Таблица 4.7. Объемы транзакций ЭК

Год Число тр-й/день Доход в день,$ Доход за месяц,$ 2001 1000 250 7 500 2002 3000 750 22 500 2003 10000 5 000 150 000 2004 15000 7500 225 000 2005 30000 15 000 450 000

Таблица 4.8. Расходы и доходы компании по годам

Год Расходы за год. $ Доходы за год, $ 2000 (начальные) 1 500 000 - 2001 1100 000 90 000 2002 1100 000 270 000 2003 1100 000 1800 000 2004 1100 000 2 700 000 2005 1100 000 5 400 000 Итого 7 000 000 10 260 000

Как видно из таблицы 4.8, система ЭК окупится в начале 2005 г., а к концу 2005 г. она уже принесет доход в размере $3 млн.

Основные функции Центра сертификации таковы:

• сертификация ключей банков-участников российских платежных систем для проектов ЭК;

• сертификация ключей банков-участников международных платежных систем (от лица этих систем) в проектах ЭК, внедрения чиповых карт, телекоммуникационных проектов;

• сертификация ключей клиентов банка от лица его Центра сертификации.

Примерная структура Центра сертификации компании:

• Руководство компании — 1

• Финансовые специалисты — 1

• Юрисконсульт - 2

• Кадры — 1

• Отдел сопровождения прикладного программного обеспечения (ППО) и системных средств — 3

• Охрана — 6 Итого: 14

Примерный бюджет компании оценивается следующим образом. Капитальные затраты:

• построение машинного зала, создание структурированной кабельной сети, приобретение средств связи и телекоммуникаций (LAN/WAN) -$100 000;

• приобретение и инсталляция аппаратно-программных средств ЦС -$850 000;

• оснащение офисных помещений на 14 человек мебелью и вычислительной техникой - $30 000;

• PR-акции - $120 000.

Итого: 1 100 000$

Текущие ежемесячные расходы:

• ФЗП (14 чел. х 1000$)-$ 14 000

• Налог на ФЗП и подоходный налог - $9 800

• Плата за поддержку аппаратных средств (с учетом амортизации) и программных средств - $10 000;

• Аренда помещений - $5 000

• Телекоммуникационные услуги — (стоимость канала ежемесячно + трафик)-$1000

• Электроэнергия - $300

• Коммунальные услуги - $200

• Факсимильная/телефонная связь - $100

• Офисные расходы - $100

• Реклама, связи с общественностью - $100

• Накладные расходы (10 %) -$2 400 Итого: - $43,000

В табл. 4.9 приведено количество сертификатов, выданных компанией за год, с учетом динамики развертывания системы ЭК и внедрения смарт-карт. В качестве клиентов ЦС рассматриваются только банки-участники платежных систем.

Таблица 4.9. Количество сертификатов, выданных компанией за год

Год Кол-во сертификатов за год 2001 20 2002 100 2003 200 2004 300 2005 500 2006 700

Таблица 4.1 0. Расходы и доходы компании по годам

Год Расходы за год, $ Доходы за год. $ 2000 (начальные) 1100 000 - 2001 520 000 60 000 2002 520 000 300 000 2003 520 000 600 000 2004 520 000 900 000 2005 520 000 1500 000 2006 520 000 2 100 000 Итого 4 420 000 5 460 000

Как видно из таблицы 4.10, компания, реализующая функции центра сертификации, окупится в середине 2006 г.

Проблемы внедрения SET

Несмотря на технологическое совершенство протокола SET, его внедрение происходит гораздо медленнее, чем предсказывалось экспертами и разработчиками стандарта. Более того, сейчас ведутся настойчивые разговоры по поводу того, что протокол SET уже является вчерашним днем и его шансы на выживание ничтожны.

Такие разговоры начались летом 2000 г., когда VISA International сделала заявление, в соответствии с которым протокол 3D SET (разновидность SET, о которой подробно будет рассказано далее) становится стандартом для стран Евросоюза, Латинской Америки и некоторых других европейских стран, включая Россию. В то же время на самом крупном американском рынке в качестве стандарта был провозглашен протокол 3D SSL (другое название протокола — 3D Payer).

Несмотря на то что ни Europay, ни MasterCard, никакая другая международная платежная система громогласно от SET не отказывались, заявление руководства системы VISA говорит о многом. Понятно, что решение крупнейшей международной платежной системы отказаться от стандарта SET на самом большом рынке ЭК не может не отразиться на решениях других платежных систем.

Очень коротко остановимся на истории SET. Первая транзакция ЭК на базе протокола SET была совершена в декабре 1996 г. через датский межбанковский процессинговый центр PBS. На сегодняшний день в мире насчитывается около 100 000 SET-совместимых карт платежных систем Europay, MasterCard и VISA, а также несколько сотен SET-совместимых ТП. По данным платежной системы VISA проекты по внедрению решения ЭК на базе протокола SET реализованы в 39 странах мира. По данным Europay International на конец 1999 г. в программе по продвижению SET участвовало 55 банков из 17 стран. Общее количество выданных сертификатов составляло 25. SET-платежи принимали 194 торговые точки.

В SET-программе системы MasterCard участвовали 104 банка из 56 стран. В Европе насчитывается около 50 внедрений протокола SET. Банки и межбанковские организации, включая Euro Kartensysteme (Германия), SSB (Италия), PBS (Дания), Deutche Bank, Dresdner Bank, Credit Agricole и SE Banken потратили приблизительно 50 миллионов евро на имплементацию этого протокола.

Внедрение SET с самого начала сопровождалось возникновением различных проблем. В первые 2-3 года распространения стандарта по миру главной проблемой являлось отсутствие взаимной совместимости (interoperability) продуктов различных поставщиков программных средств, поддерживающих протокол SET. Проблема успешно была решена (и эффективно решается сегодня для новых разработчиков ПО) усилиями компании SETCo и разработчиков ПО. Сегодня на рынке продается около 50 различных решений ЭК, в основе которых лежит протокол SET, более чем от 20 поставщиков программного обеспечения. Компания SETCo организует для поставщиков программных продуктов специальные тесты SET Compliance Testing на совместимость со стандартом SET. Продукты, прошедшие подобное тестирование, получают специальную лицензию SET Mark, свидетельствующую об их совместимости со стандартом. В то же время, совместимость со стандартом не гарантирует совместимости между продуктами, получившими лицензию SET Mark. Список продуктов, успешно прошедших тестирование SET Compliance Testing, можно найти на сайте по ссылке Derived Products. На том же сайте по ссылке Vendor Status Matrix можно получить информацию о продуктах, находящихся на этапе тестирования SET Compliance Testing.

Проблеме совместимости и сегодня уделяется большое внимание. В ее решении заинтересованы в первую очередь поставщики программного обеспечения, принимающие активное участие в организации тестов на совместимость под эгидой SETCo Technology Advisor Group. Результаты тестирования на совместимость продуктов различных производителей можно также найти на сайте по ссылке Interoperability Database. Тестирование на совместимость продуктов различных производителей проводится на так называемых фестивалях, организуемых SETCo. Во время таких фестивалей, организуемых дважды в год, проводятся попарные тесты на совместимость, результаты которых и заносятся в БД Interoperability Database.

Существуют объективные причины медленного продвижения SET. К ним, в первую очередь, следует отнести высокую стоимость решений, реализующих протокол SET; принимая во внимание наличие уже развитой базы электронных магазинов, применяющих протокол SSL, a также пока приемлемый для торговли уровень мошенничества, магазины не спешат инвестироваться в новое решение. Это хорошо видно на примере Дании, являющейся одним из лидеров по внедрению протокола SET. Уже упоминавшаяся компания PBS при заключении договоров на обслуживание предлагает Интернет-магазинам обе технологии — SSL и SET. На конец 2000 г. PBS заключила 1971 договор на работу по технологии SSL и только 208 договоров на обслуживание по стандарту SET.

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

В свою очередь, отсутствие инфраструктуры Интернет-магазинов, использующих стандарт SET, сдерживает банки-эмитенты от инвестиций в SET. Кроме того, банки-эмитенты полностью защищены от мошенничеств сегодняшними правилами международных платежных систем (вся ответственность по транзакциям, проведенным не по протоколу SET, лежит на обслуживающем банке). Это также является одной из принципиальных ошибок, допущенных международными платежными системами при внедрении нового стандарта. Только марте 2001 г. до банков дошло решение VISA International, действительное с 1 января 12-2103 2003 года для стран с базовым протоколом ЭК 3D SET, в соответствии с которым ответственность за мошенничество, совершенное не по SET -карте, в ТП, поддерживающем SET, ложится на банк-эмитент. Такое решение должно серьезным образом стимулировать эмитентов на переход к использованию SET.

Другая ошибка международных платежных систем состояла в том, что для SET-транзакций не были введены специальные значения комиссионных Interchange Fee, выплачиваемых обслуживающим банком в пользу банка-эмитента. Долгое время тарифы оставались такими же, как для неэлектронной операции «покупка» — около 2,5 % от размера транзакции. Только общее уменьшение комиссионных плат в международных платежных системах привело к снижению размера Interchange Fee для электронных покупок (примерно 1,45-1,69 % в зависимости от платежной системы и карточного продукта).

Модели трех доменов

Летом 2000 г. компания VISA объявила о своей поддержке концепции (модели) «трех доменов» (Three Domain Model), суть которой состоит в следующем.

Весь процесс аутентификации, обеспечивающий безопасность транзакций ЭК, разбивается на три домена (области): Issuer Domain, Acquirer Domain и Interoperability Domain (рис. 4.6).

Рис. 4.6. Модель трех доменов (3D)

Назначение Issuer Domain состоит в аутентификации банком-эмитен-том своего клиента на основе правил и методов, установленных самим эмитентом.

Назначение Acquirer Domain заключается в том, что обслуживающий банк производит аутентификацию своего ТП на основе правил и методов, установленных самим обслуживающим банком.

Наконец, задача Interoperability Domain состоит в том, чтобы определить правила и процедуры обмена информацией между доменами Issuer Domain и Acquirer Domain, гарантирующие этим доменам взаимную аутентификацию друг друга.

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

Следует подчеркнуть, что процедуры аутентификации внутри Issuer Domain и Acquirer Domain определяются соответственно банком-эми-тентом и обслуживающим банком. Платежная система определяет лишь правила работы в области Interoperability Domain. Таким образом, модель трех доменов ясно определяет ответственность всех участников транзакции ЭК в процессе их аутентификации.

Очевидное преимущество модели трех доменов состоит в том, что эмитент получает возможность производить аутентификацию своего клиента любым удобным ему способом. Например, для этого могут использоваться методы, уже применяемые банком в электронном бэнкинге, или PKI-приложения на смарт-картах.

Недавно компания Еигорау предложила новую оригинальную технологию аутентификации владельца карты, внедрив приложение Wireless Public Key Infrastructure (WPKI) в SIM-карте мобильного телефона. Суть идеи состоит в том, что после того как клиент обратился к серверу своего эмитента для инициализации SET-транзакции, последний организует передачу на мобильный телефон владельца карты SMS-сообщения, содержащего описание товаров, заказанных клиентом. Если клиент согласен с содержимым перечня товаров, он его подтверждает. В результате полученное SMS-сообщение подписывается ключом владельца карты и возвращается на сервер эмитента.

Далее будут рассмотрены два частных случая модели трех доменов: 3D SET и 3D SSL.

Суть модели 3D SET состоит в том, что взаимодействие между доменами эмитента и обслуживающего банка осуществляется по протоколу SET. На практике это означает, что в Issuer Domain реализуется концепция «тонкого кошелька» с использованием Issuer Server Wallet, который осуществляет аутентификацию клиента по некоторому своему алгоритму и далее направляет в Acquirer Domain сообщения, подтверждающие аутентификацию клиента в формате сообщений протокола SET. В этом случае нет необходимости передачи сертификатов ключей клиентов самим клиентам.

С точки зрения ТП модель 3D SET позволяет ТП выполнить транзакцию ЭК с использованием независимого платежного сервера.

Модель 3D SSL отличается от модели 3D SET тем, что в области Interoperability Domain вместо протокола SET используется протокол SSL. На практике это выражается в том, что после завершения банком-эми-тентом процедуры аутентификации своего клиента банк-эмитент подписывает запрос клиента своим секретным ключом и передает его в Acquirer Domain. Тем самым эмитент подтверждает результат аутентификации клиента.

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

Преимущества модели 3D SSL очевидны. Клиенту достаточно использовать обычный браузер для реализации транзакции ЭК. При этом на сервере эмитента Issuer Server не требуется хранение (и тем более распространение) сертификатов ключей клиентов банка. В связи с этим внедрение подобной модели является чрезвычайно простым в сравнении с процедурой внедрения модели 3D SET. В то же время, модель 3D SSL имеет и очевидные недостатки — не обеспечивается конфиденциальность данных о реквизитах карты клиента по отношению к ТП.

Модель 3D Secure

В мае 2001 г. были опубликованы спецификации на стандарт 3D Secure, претендующий на роль глобального стандарта аутентификации в платежной системе VISA. Поскольку рукопись этой книги была передана в издательство примерно в то же время, ниже приводится самое общее описание этого стандарта.

Протокол 3D Secure базируется на концепции трех доменов. Общая схема протокола представлена на рис 4.7.

Торговое предприятие

Владелец карты

Directory

Merchant Plug-In

ACS

Рис. 4.7. Модель 3D Secure

После того, как владелец карты подтвердил торговому предприятию свою готовность произвести покупку и в защищенной SSL-сессии передал ТП реквизиты карты, приложение ТП инициирует специальное программное обеспечение, устанавливаемое на сервере ТП и называемое Merchant Plug-In.

Программа Merchant Plug-In обращается к серверу платежной системы (Directory) с запросом на проверку поддержки владельцем карты протокола 3D Secure. Данный запрос содержит номер карты, идентификатор торговой точки и ее пароль (опционно). Сервер Directory по идентификатору торговой точки проверяет наличие данного ТП в БД интернет-магазинов, поддерживающих протокол 3D Secure. Кроме того, в случае использования пароля ТП проводится идентификация ТП. После этого сервер Directory по номеру карты покупателя определяет ее принадлежность к диапазону карт, поддерживающих протокол 3D Secure, а также URL сервера эмитента карты, называемого Access Control Server (ACS), и передает по этому URL запрос на поддержку данной конкретной картой протокола 3D Secure. Сервер ACS проверяет поддержку владельцем карты протокола 3D Secure и результат проверки через Directory сообщает программе Merchant Plug-In.

Следует отметить, что диалоги Merchant Plug-In - Directory и Directory -ACS происходят по защищенным SSL-сессиям с использованием SSL-сертификатов, выданных Root Certificate Authority, что обеспечивает не только конфиденциальность передаваемых данных, но и что крайне важно- взаимную аутентификацию участников диалогов.

Если в результате проверки на ACS карта покупателя поддерживает протокол 3D Secure, то Merchant Plug-In формирует запрос на аутентификацию владельца карты. Данный запрос содержит информацию о сумме покупки, торговом предприятии, специальный идентификатор владельца карлы (Account ID), поддерживаемый на сервере ACS, URL ТП и передается на сервер ACS, через браузер покупателя с одновременной переадресацией владельца карты на сервер ACS.

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

После успешного завершения аутентификации клиента, сервер ACS подготавливает ответ, подписанный на ключе эмитента. Подпись эмитента используется для решения проблемы потенциального отказа владельца карты от результатов транзакции. Ответ передается на сервер обслуживающего банка с одновременным переключением клиента на этот же сервер. Результат аутентификации передается ACS также на сервер Directory, который выступает в роли третейского судьи в случае возникновения диспута по транзакции. Merchant Plug-In проверяет подпись эмитента и формирует стандартный авторизационный запрос для передачи его в платежную сеть.

Таким образом, протокол 3D Secure удовлетворяет основным требованиям безопасности, предъявляемым к ЭК. В частности, решается проблема аутентификации участников транзакции, отказа от транзакции и т. п. И в то же время говорить о протоколе 3D Secure как об устойчивом протоколе невозможно, поскольку он определяет только часть процесса обработки транзакции (Interoperability Domain), оставляя протоколы в зонах Issuer Domain и Acquirer Domain на выбор соответственно эмитента и обслуживающего банка. У протокола 3D Secure имеются следующие очевидные достоинства. Во-первых, в общем случае для совершения транзакции ЭК клиент помимо браузера не должен содержать специального ПО на своем компьютере. Хотя в некоторых случаях наличие электронного бумажника целесообразно. Например, когда эмитент использует более сложные по сравнению с паролями схемы аутентификации владельца карты (например, с помощью смарт-карты и т. п.). Здесь важно, что электронный бумажник предоставляется владельцу карты его эмитентом. Его функционирование никак не регламентируется платежными системами.

Во-вторых, резко упрощается процедура сертификации. В протоколе 3D Secure используется одноуровневая система центров сертификации.

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

Наконец, ПО, устанавливаемое на стороне обслуживающего банка и банка-эмитента, гораздо проще по своей функциональности и потому должно быть существенно дешевле ПО, реализующего SET.

Модель SSET

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

Использование протокола 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.

Содержание раздела

---