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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

На верхнем уровне располагается Корневой ЦС (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).

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

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

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

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

Формат сертификата открытого ключа в протоколе 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, и пара ключей R2, которая будет действовать после окончания срока действия пары R В сертификате открытого ключа пары R,, подписанном закрытым ключом этой же пары, содержится значение хэш-функции открытого ключа пары R2. Поэтому, получив новую пару ключей R2, участник транзакции ЭК проверяет равенство значений хэш-функции нового открытого ключа со значением, содержащемся в старом сертификате. Таким образом подтверждается подлинность полученного нового сертификата открытого ключа подписи.

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

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

Результаты, приведенные в последней таблице, получаются из предположения, что каждый вышестоящий ЦС выдает сертификат нижестоящему ЦС в последний день действия сертификата вышестоящего ЦС. Проиллюстрируем сказанное на примере расчета срока действия сертификата открытого ключа 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 отвечают ЦС и платежные шлюзы. В процессе выдачи и обновления сертификатов ЦС сообщают владельцам карт, ТП и платежным шлюзам актуальные на данный момент времени списки 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 СI nit Res;
• язык, на котором должна быть написана запрашиваемая форма;
• некоторые другие данные, например, «отпечатки» сертификатов, CRL и BCI, содержащиеся в системе владельца карты.

После этого владелец карты по случайному закону генерирует симметричный ключ Кг с помощью которого шифруются данные Reg-FormReqData. Симметричный ключ К, вместе с номером карты, в свою очередь, закрываются 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 и ключ К2, подписывает эти данные с помощью Private Signature Key и далее шифрует все получившиеся в результате описанных в этом пункте операций данные с помощью ключа К3;
• ключ К3 вместе с номером карты шифруются ключом CCA Public Key-Exchange Key и передаются ССА (это сообщение в терминологии SET называется CertReq).

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

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

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

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

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

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

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

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

Опишем теперь типы транзакций, используемых в протоколе 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 (Н2) и некоторую другую информацию. PI предназначено для платежного шлюза и включает в себя идентификатор транзакции XID, величину TranStain, представляющую собой хэшфункцию от секрета карты S и XID, хэш-функцию OI (Н,), параметрически значение CVC2/CVC2,2-ю дорожку магнитной полосы карты и другую информацию.

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

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

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

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

Платежный шлюз, получив AuthReq, дешифрует с помощью закрытого ключа Key-Exchange Key оба симметричных ключа К, и К2, а также данные о реквизитах карты, дешифрует данные о транзакции и PI, проверяет подпись владельца карты (по аналогии с тем, как это делает ТП, для этого используется значение Н,, содержащееся в PI), проверяет на равенство значения 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 является на сегодняшний день единственным открытым и устойчивым протоколом ЭК.

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

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

• (использование микропроцессорных карт, удовлетворяющих стандарту 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 позволяет ОБ передавать банкуэмитенту три поля со второй дорожки магнитной полосы: Country Code, Service-Code и Discretionary-Data (содержимое данных Discretionary-Data полностью определяется эмитентом), что является очень важным фактором, поскольку некоторые сети и банки используют эту информацию для маршрутизации транзакций, а также их авторизации. Данные Discretionary-Data передаются в специально предназначенном для этого поле раздела PI сообщения Purchase Request протокола SET.

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

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

Как видно из таблицы, протокол 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), а остальные опционными. Например, oпeрации 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.

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

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

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

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

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

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

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

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

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

Таким образом, в соответствии с моделью MOSET ТП предает платежному шлюзу сообщения в формате протокола SET (отсюда название модели Merchant Originated SET или 2 Certificate Keepers Model).

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

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

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

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

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

• взаимодействие ТП и покупателя в процессе ЭК осуществляется с помощью протокола 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 показана на рисунке.

Подход 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 и т. п.

Сразу после появления спецификаций протокола 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. В таблице приведены минимальные и рекомендуемые параметры PC покупателя, необходимые для выполнения электронной покупки.

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

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

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

Компания 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 browser-based-интерфейсов для получения различной информации (например, информации об истории транзакций данного клиента);
• 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 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.