Защита удаленных банковских транзакций

- аутентификацию торговой точки другими участниками транзакции: владельцем карты, обслуживающим банком;

- аутентификацию обслуживающего банка торговой точкой;

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

- конфиденциальность информации о реквизитах карты для торговой точки;

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

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

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

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

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

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

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

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

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

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

При использовании SSL не обеспечивается конфиденциальность данных о реквизитах карты для торговой точки. Протокол SSL не является устойчивым.

Для операций с кредитными карточками используется протокол SET (Secure Electronic transactions). В отличие от SSL протокол SET узко специализирован. Целью SET является обеспечение необходимого уровня безопасности для платежного механизма, в котором участвует три или более субъектов. При этом предполагается, что транзакция реализуется через Интернет, т.е. удаленно.

Рассмотрим функции, которые осуществляет SET на различных уровнях [10]:

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

- конфиденциальность. Все операции производятся в зашифрованном виде;

- целостность сообщений. Информация не может быть подвергнута модификации по дороге в противном случае это будет сразу известно;

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

- безопасность. Протокол должен обеспечить максимально возможную безопасность операции, достижимую в имеющихся условиях;

- совместимость. Должна быть предусмотрена совместимость с любыми программными продуктами и с любыми сервис-провайдерами.

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

На более высоком уровне протокол SET поддерживает все возможности, предоставляемые современными кредитными карточками:

- регистрацию держателя карточки;

- регистрацию продавца;

- запрос покупки;

- авторизацию платежа;

- перевод денег;

- кредитные операции;

- возврат денег;

- отмену кредита;

- дебитные операции.

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

В протоколе SET центр сертификации имеет четырехуровневую архитектуру основанную на использовании протокола X.509.

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

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

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

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

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

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

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

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

Схема регистрации владельца карты в центре сертификации (СА) показана на рисунке 3.1 [10]. Процесс регистрации проходит через семь состояний, начиная с отправки начального запроса и завершая получением сертификата. Эффективность сертификата при идентификации владельца карты сильно зависит от методов, используемых платежной системой карты и эмитентом карты для аутентификации владельца перед выдачей ему сертификата. Это достаточно критический процесс, учитывая то, что на этом этапе еще не используется цифровая подпись.

Рисунок 3.1 - Регистрация владельца карты в центре сертификации

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

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

Когда сертификационный центр (СА) получает запрос владельца карты, он дешифрует цифровой конверт, получает симметричный ключ, информацию о счете и секретный код, генерируемый программой владельца карты. Собственно запрос сертификата дешифруется с помощью симметричного ключа. Затем СА использует общедоступный ключ, присланный в запросе, чтобы проверить подпись, сформированную с помощью секретного ключа владельца карты. Если с подписью все в порядке, процесс обработки запроса продолжается. Далее производится верификация самого запроса с привлечением информации о счете. На этом этапе СА взаимодействует с эмитентом карты. Это взаимодействие не регламентируется протоколом SET. В некоторых вариантах на данном этапе для верификации запроса привлекаются возможности платежной системы. Если верификация запроса прошла успешно, сертификат формируется и пересылается владельцу карты. При этом СА сначала генерирует случайное число, которое комбинируется с секретным кодом, присланным в запросе. Полученный код используется в сертификате для защиты информации о счете владельца карты. Номер счета, срок его действия и секретный код преобразуются с помощью однопроходного хэш-алгоритма. Полученный результат помещается в сертификат. Если номер счета, срок его действия и секретный код известны, сертификат можно верифицировать. После данной процедуры СА цифровым образом подписывает сертификат. Время действия сертификата определяется политикой СА, но часто оказывается равным сроку работы платежной карты (но может оказаться и короче). Сообщение-отклик содержит в себе сертификат, а также секретный код, сформированный СА и логотип платежной системы. Вся эта информация шифруется симметричным ключом, присланным в запросе. Многие из упомянутых процедур и структуры запросов/откликов будут рассмотрены подробно ниже.

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

Схема процедуры регистрации продавца показана на рисунке 3.2 и содержит в себе пять этапов [10].

Рисунок 3.2 - Регистрация продавца

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

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

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

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

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

Практика электронной торговли позволяет выделить семь этапов сделки приведенных в таблице 3.1.

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

Таблица 3.1

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

Каждая цифра номера умножается на его “вес”. Веса меняются 1,2,1,2. Для карт с четным числом цифр, последовательность весов начинается с 2, в противном случае с 1. Если взвешенное число больше 9, из него вычитается 9. Далее вычисляется сумма по модулю 10. Результат всегда должен получаться равным нулю (с учетом кода контрольной суммы).

Схема взаимодействия субъектов в протоколе SET показана на рисунке 3.3 (взаимодействия с центром сертификации не показаны).

Рисунок 3.3 - Схема взаимодействия субъектов протокола SET

Покупатель инициализирует покупку. При этом покупатель выбирает продавца, просматривает его WEB-сайт, принимает решение о покупке, заполняет бланк заказа. Все это делается до вступления в дело протокола SET. Реально взаимодействие участников сделки регламентируется протоколом IOTP. SET начинает свою работу, когда покупатель нажимает клавишу оплаты. При этом сервер посылает ЭВМ-покупателя сообщение, которое и запускает соответствующую программу. Процедура эта может быть реализована с помощью PHP- или CGI-скрипта, или JAVA-аплета [11].

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

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

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

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

Банк продавца авторизует данную операцию, и посылает подтверждение, подписанное электронным образом, WEB-серверу продавца.

WEB-сервер продавца завершает операцию, выдавая клиенту подтверждение на экран, и заносит результат операции в соответствующую базу данных.

Продавец осуществляет подтверждение выполнения операции своему банку, Деньги покупателя переводятся на счет продавца.

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

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

Протокол SET может использоваться не только в рамках Интернет, но и при заказах по почте или телефону MOTO (Mail Order/Telephone Order). Для понимания основополагающих принципов вышеизложенного могло бы быть достаточно. Более того, квалифицированный программист мог бы написать программы, которые эти принципы реализовали для некоторой замкнутой системы покупатель-банки-продавец. Но функция SET шире, этот протокол рассчитан на международную ничем не ограниченную систему платежей. По этой причине ниже будут приведены некоторые, наиболее важные детали работы протокола, регламентирующие его функционирование.

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

Протокол SET защищает только финансовую информацию, непосредственно сопряженную с платежной транзакцией. Защита информации, содержащейся в заказе, SET не регламентирует.

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

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

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

Важной функцией расчетных центров помимо реализации платежей является поддержка списков аннулированных сертификатов CRL (Certificate Revocation List). Это крайне важно для вовлеченных финансовых организаций и фирм предоставляющих платежные средства (например, таких как VISA или MasterCard).

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

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

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

Протокол SET определяет иерархию сертификационных центров, во главе которой находится RCA (Root Certificate Authority). Далее следуют BCA (Brand-specific CA) и GCA (Geo-political CA). Некоторые платежные системы имеют свои сети, например, VisaNet или BankNet. Эти сети осуществляют авторизацию платежей от эмитента к получателю и имеют свою систему защищенной передачи сообщений.

Цифровая подпись устанавливает соответствие между подписанными данными и уникальным секретным ключом подписанта (покупателя, продавца, банкира или центра сертификации). Секретный ключ математически связан с общедоступным ключом, и таким образом, связывает данные и общедоступный ключ. Фундаментальной целью сертификата является установление соответствия между общедоступным ключом и уникальным идентификатором объекта (или субъекта), гарантируя отсутствие подмены. Следует помнить, что общедоступные ключи пересылаются по незащищенным каналам Интернет. В случае держателя карты сертификат подписи устанавливает соответствие между его общедоступным ключом и индивидуальным кодом PAN (Primary Account Number). Цифровая подпись в сочетании с хэшированием сообщения (вычислением его цифрового дайджеста) гарантирует, кроме того, целостность данного сообщения, блокируя возможность его модификации в процессе пересылки. Сообщения SET следуют рекомендациям ISO/IEC и ITU-T ASN.1 (Abstract Syntax Notation) и кодируется с использованием правил DER (Distinguished Encoding Rules). Механизм пересылки сообщений между объектами SET не регламентируется. Предполагается, что приложения SET могут работать в одном из двух режимов.

Интерактивном, когда объекты взаимодействуют в реальном масштабе времени с малыми задержками между запросами и откликами (например, в рамках технологии WWW).

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

В операциях с общедоступными ключами и сертификатами в SET используется алгоритм RSA. Обычно длина ключа составляет 1024 бита и только для Root CA (базового центра сертификации) применяются ключи длиной 2048 бит. Для симметричного шифрования обычно применяется алгоритм DES. Помимо него используется также алгоритм CDMF (Commercial Data Masking Facility), он служит для защиты сообщений между получателем и держателем карты. DES работает с блоками данных 64 бита и предполагает использование для операций шифрования и дешифрования одного и того же 56-битного ключа (каждый байт содержит бит четности). Правила заполнения SET для DES-CBC требуют, чтобы строка заполнителя всегда добавлялась к открытому тексту, подлежащему шифрованию. Заполнитель делает длину блока данных кратной 8 октетам. Алгоритм CDMF осуществляет скремблинг данных, который базируется на DES в несколько облегченной модификации, когда эффективная длина ключа равна 40 бит вместо 56 - для DES.

SET использует усовершенствованный Матиасом и Джонсоном метод хэширования, улучшающий технику OAEP [10].

Базовыми процедурами протокола SET является посылка и прием сообщений. Процесс отправки сообщения представлен в таблице 3.2

Таблица 3.2

Верификация цепочки сертификатов требует, чтобы последовательно проверялся каждый сертификат, и контролировалось его соответствие выпустившему его центру. Например, держатель карты должен проверить сертификаты продавца, центра сертификации продавца, центра сертификации платежной системы (Brand CA), и корневого центра Root CA. Процесс верификации включает в себя следующие компоненты:

- контроль сертификатов X.509;

- контроль сертификатов SET;

- обработку CRL (Certificate Revocation List);

-обработку BrandCRLIdentifier (BCI).

Процедура обработки входящего сообщения рассмотрена в таблице 3.3.

Таблица 3.3

На практике предполагается, что процесс верификации будет остановлен на уровне, который был успешно пройден ранее. Все приложения SET помимо самих сертификатов контролируют их дату пригодности. Процедура верификации представлена в таблице 3.4

Таблица 3.4

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

Страницы: 1, 2, 3, 4, 5