Подякувати Студентському архіву довільною сумою
Admin
26.02.2023 12:38
Дякуємо, що користуєтесь нашим архівом!
Безопасность транзакций в электронной коммерции (протокол Set).
Інформація про навчальний заклад
ВУЗ:
Інші
Інститут:
Не вказано
Факультет:
Не вказано
Кафедра:
Не вказано
Інформація про роботу
Рік:
2024
Тип роботи:
Лекція
Предмет:
Інші
Частина тексту файла (без зображень, графіків і формул):
Безопасность транзакций в электронной коммерции (протокол Set). Часть I
Введение
Одной из основополагающих концепций в электронной коммерции является понятие платежной системы. Платежная система представляет собой ассоциацию банков, называемых банками-участниками этой платежной системы. Когда банк присоединяется к ассоциации (вступает в нее), он тем самым подтверждает свою готовность и берет на себя обязательство следовать правилам этой ассоциации (платежной системы), определяющим технические, юридические и финансовые аспекты функционирования банка в системе. Такое признание банком правил платежной системы является основой для взаимного доверия между неизвестными друг другу банками при организации ими безналичных расчетов для своих клиентов.
В платежной системе банк может функционировать в двух направлениях: во-первых, в качестве банка-эмитента и, во-вторых, в качестве обслуживающего банка. Каждый банк может быть одновременно и эмитентом и обслуживающим банком.
В качестве эмитента банк выдает своему клиенту (физическому и/или юридическому лицу, имеющему в данному банке счет) специальное удостоверение (пластиковую карту), обеспечивающее удаленный доступ клиента к своему счету с целью получения различных услуг: безналичная покупка в торговой точке, получение наличных в банкомате или отделении банка и т. п. Таким образом пластиковая карта связанна со счетом (счетами) клиента в банке.
Обслуживающий банк обеспечивает поддержку инфраструктуры приема пластиковых карт, к которой в общем случае относятся банкоматы, пункты выдачи наличных и предприятия торговли и сервиса. Обслуживающий банк заключает договоры с торговыми точками на обслуживание в них пластиковых карт, гарантируя торговой точке возврат средств за операцию, совершенную в нем по карте любого банка-участника платежной системы.
Когда клиент банка А собирается совершить покупку в торговой точке обслуживающего банка В, то торговая точка в первую очередь должна убедиться в том, что в соответствии с договором с обслуживающим банком В операция по предъявляемой для оплаты карте будет возмещена. Другими словами ,торговая точка должна убедиться в том, что банк-эмитент А и обслуживающий банк В являются участниками одной платежной системы. Это устанавливается по логотипу платежной системы, нанесенному на пластиковой карте клиента.
Процесс оплаты услуги в общем случае состоит из двух этапов. Первый этап – авторизация транзакции: торговая точка «считывает» с предъявляемой клиентом для оплаты покупки пластиковой карты необходимую информацию, а также, возможно, получает некоторую идентифицирующую клиента информацию непосредственно от самого клиента (например, персональный идентификационный номер владельца карты). Полученная от клиента и считанная с карты информация, а также информация о покупке (сумма покупки, валюта транзакции и т. д.) и торговой точке (идентификаторы торговой точки и устройства приема карты) передается торговой точкой своему обслуживающему банку в форме авторизационного запроса. С помощью авторизационного запроса торговая точка спрашивает у обслуживающего банка, может ли оно предоставить данному клиенту запрашиваемую им услугу. В свою очередь обслуживающий банк обращается за разрешением на оказание услуги к банку-эмитенту А. При этом банки А и В обмениваются сообщениями в соответствии с правилами, установленными платежной системой. Поэтому синтаксис и семантика понятна обоим банкам.
Эмитент А, получив запрос от обслуживающего банка В, проверяет достоверность информации о карте и ее владельце: правильность реквизитов карты и идентификатор владельца карты. После этого банк А проверяет достаточность средств на счете клиента для совершения оплаты запрашиваемой ним услуги. Если все проверки завершились успешно, банк А отвечает на запрос банка В разрешением на совершение покупки, предварительно списав (или только «заморозив») со счета клиента стоимость покупки вместе с некоторыми установленными им комиссиями.
Получив разрешения от банка А, обслуживающий банк в свою очередь разрешает операцию покупки своей торговой точке, тем самым гарантируя последнему возмещение средств за совершаемую торговой точкой продажу товара/услуг. В большинстве случаев, если обслуживающий банк представил эмитенту правильную и достаточную информацию (в соответствии с правилами платежной системы) для авторизации информацию, ответственность за транзакцию в случае возникновения спора ложится на эмитента.
Вторая часть безналичной оплаты товаров/услуг заключается в расчетах между всеми участниками транзакции. Как уже отмечалось торговая точка получает возмещение за операцию покупки от своего обслуживающего банка. Обслуживающий банк в свою очередь получает возмещение от банка-эмитента. Гарантом расчетов между банками выступает платежная система. В этом состоит ее важнейшая функция. Расчеты, как правило, производятся безакцептно (т. е. без получения специального разрешения) через специальные счета, открываемые банками в расчетных банках платежной системы.
Наконец, банк-эмитент списывает средства со счета своего клиента. Таким образом, при участии и гарантии платежной системы реализуется передача средств со счета клиента на счет торговой точки.
В платежной системе время от времени по различным причинам могут возникать споры (диспуты) между банком-эмитентом и обслуживающим банком, связанные с некоторой транзакцией, имевшей место в платежной системе. Например, владелец карты может утверждать, что никогда не совершал транзакции, за которую с его счета были списаны деньги, или совершал транзакцию, но на другую сумму. Для разрешения возникающих споров платежные системы разрабатывают правила, предусматривающие использование специальных сообщений, которыми обмениваются банки-участники системы.
В частности, если банк-эмитент считает, что некоторая транзакция, выполненная по карте его клиента, является по каким-то причинам неверной (например, клиент не совершал данной транзакции, сумма транзакции является неправильной, транзакция является дубликатом транзакции, по которой безналичные расчеты уже были произведены и т. п.), он направляет обслуживающему банку специальное сообщение, называемое chargeback (отказ от платежа). На основании этого сообщения платежная сеть возвращает на счет банка-эмитента средства, связанные с транзакцией, на которую пришел chargeback. Возвращаемые средства списываются со счета обслуживающего банка. Далее банк-эмитент возвращает списанные средства на счет клиента.
Операции безналичных расчетов в платежных системах называют транзакциями. Платежные системы поддерживают транзакции различных видов: покупка, снятие наличных в отделении банка, снятие наличных в банкомате, получение информации об остатке на счете клиента и другие.
Транзакции различаются также по способу представления информации о карте в платежную систему. Существуют электронные транзакции (информация о карте считывается с магнитной полосы/чипа) и транзакции голосовой авторизации (paper based).
По определению CNP-транзакция (Cardholder Not Present) представляет собой операцию покупки по пластиковой карте, в момент совершения которой клиент не присутствует лично в торговой точке, а сообщает торговой точке реквизиты своей карты (обычно номер карты и ее срок годности), необходимые для проведения авторизации, заочно (письмом, по телефону, сети передачи данных и т. п.).
В данном материале, всякий раз когда речь идет о расчетах с помощью пластиковой карты, под транзакцией электронной коммерции понимается CNP-транзакция, при совершении которой обмен данными между владельцем пластиковой карты и торговой точкой о реквизитах карты происходит через Интернет.
Обычно процесс покупки выглядит следующим образом. Клиент с помощью персонального компьютера (или другого устройства), подключенного к сети Интернет, выбирает интересующие его товары в виртуальной витрине товаров сайта торговой точки. Подтвердив выбор товаров и согласие с их стоимостью, клиент сообщает торговой точке о желании заплатить за покупку с помощью пластиковой карты.
Далее происходит диалог между торговой точкой и владельцем карты, целью которого является получение реквизитов карты покупателя для их представления в сеть в виде стандартного авторизационного запроса. В течение этого диалога торговая точка и покупатель иногда имеют возможность аутентифицировать друг друга, что обеспечивает безопасность транзакции.
Полученные от клиента данные о реквизитах карты (кстати, торговая точка может и «не видеть» эти данные) торговая точка передает своему обслуживающему банку, который на основе этих данных формирует и представляет в сеть авторизационный запрос. Начиная с этого момента, транзакция обрабатывается по тем же правилам, что и обычная операция покупке по пластиковой карте. Авторизационный запрос обслуживающего банка в виде сообщения в формате, принятом в соответствующей платежной системе, передается банку-эмитенту клиента, который авторизует транзакцию и о результате авторизации сообщает обслуживающему банку. Обслуживающий банк передает торговой точке решение эмитента, которое сообщается владельцу карты. В случае успешного завершения транзакции клиент получает электронный чек, содержащий адрес торговой точки в Интернете, ее название, сумму покупки и т. п.
Способы решения проблемы безопасности транзакций в электронной коммерции
С самого начала внедрения электронной коммерции стало очевидно, что методы идентификации владельца карты, применяемых в обычных транзакциях, являются неудовлетворительными для транзакций электронной коммерции.
Действительно, при совершении операции покупки в физическом магазине продавец имеет право рассмотреть предъявляемую для расчета пластиковую карту на предмет ее соответствия требованиям платежным системам (в частности проверить наличие голограммы, специальных секретных символов, сверить подписи на панели и торговом чеке и т. п.). Кроме того, продавец может потребовать от покупателя документ, удостоверяющий его личность. Все это делает мошенничество по поддельной карте достаточно дорогим предприятием.
В случае транзакции в электронной коммерции все, что требуется от мошенника – знание реквизитов карты. Затраты, связанные с изготовлением поддельной физической карты, в этом случае не требуется.
В мире пластиковых карт с магнитной полосой самым надежным способом защиты транзакции от мошенничества является использование PIN-кода для идентификации владельца карты его банком-эмитентом. Секретной информацией, которой обладает владелец карты, является PIN-код. Он представляет собой последовательность, состоящую из 4-12 цифр, известную только владельцу карты и его банку-эмитенту. PIN-код применяется всегда при проведении транзакции повышенного риска, например при выдаче владельцу карты наличных в банкоматах. Выдача наличных в банкоматах происходит без присутствия представителя обслуживающего банка (ситуация похожа на транзакцию электронной коммерции). Поэтому обычных реквизитов карты для защиты операции «снятия наличных в банкомате» недостаточно и используется секретная дополнительная информация - PIN-код.
Более того, общая тенденция развития платежных систем – более активное использование PIN-кода для операций «покупки» по дебетовым картам. Казалось бы, использование подобного идентификатора могло бы помочь решить проблему безопасности , однако это не так. К сожалению, в приложении к электронной коммерции этот метод в классическом виде неприменим.
Использование PIN-кода должно производиться таким образом, чтобы этот секретный параметр на всех этапах обработки транзакций оставался зашифрованным (он должен быть известен только владельцу карты и банку-эмитенту). В реальном мире это требование реализуется за счет использования в устройствах ввода транзакции специальных физических устройств, называемых PIN-PAD и содержащих Hardware Security Module – аппаратно-программные устройства защиты, позволяющие хранить и преобразовывать поступающую информацию надежным образом. Эти устройства хранят специальным образом защищенный секретный коммуникационный ключ, сгенерированный обслуживающим банком данной торговой точки. Когда владелец карты вводит значение PIN-кода, оно немедленно шифруется коммуникационным ключом и отправляется внутри авторизационного запроса на хост обслуживающего банка. На хосте обслуживающего банка зашифрованный идентификационный код перекодируется внутри Hardware Security Module хоста (хост обслуживающего банка также имеет свой устройство шифрования) в блок, зашифрованный на коммуникационном ключе платежной системы, и передается в сеть для дальнейшего предъявления эмитенту. По дороге к эмитенту PIN-код будет преобразовываться еще несколько раз, но это не важно. Важно другое – для того, чтобы следовать классической схеме обработки PIN-кода, каждый владелец карты должен хранить криптограммы коммуникационных ключей всех обслуживающих банков, что на практике невозможно.
Классическую схему можно было бы реализовать с помощью применения асимметричных алгоритмов с шифрованием PIN-кода владельца карты открытым ключом торговой точки. Однако для представления PIN-кода в платежную сеть его необходимо зашифровать, как это принято во всех платежных системах, симметричным ключом.
Существует другое, неклассическое решение по использованию PIN-кода. Например, можно на компьютере владельца карты шифровать PIN-код плюс некоторые динамически меняющиеся от транзакции к транзакции данные на ключе, известном только эмитенту и владельцу карты. Такой подход потребует решения задачи распределения секретных ключей. Эта задача является весьма непростой (очевидно, что у каждого владельца карты должен быть свой индивидуальный ключ), и если уж она решается, то использовать ее решение имеет смысл для других, более эффективных по сравнению с проверкой PIN-кода методов аутентификации владельца карты.
В то же время идея проверки PIN-кода была реализована для повышения безопасности транзакций в электронной коммерции по картам, базы данных которых хранятся на хосте процессора STB CARD. В общих чертах STB CARD реализует следующую схему. Владельцы карт, эмитенты которых держат свою базу данных карточек на хосте STB CARD, могут получить дополнительный PIN-код, называемый PIN2. Этот код представляет собой последовательность из 16 шестнадцатеричных цифр, которая распечатывается в PIN-конверте, передаваемом владельцу карты, и вычисляется эмитентом с помощью симметричного алгоритма шифрования, примененного к номеру карты и использующего секретный ключ, известный только эмитенту карты.
Далее во время проведения транзакции на одной из торговых точек, обслуживаемом банком STB CARD, у владельца карты в процессе получения данных о клиенте запрашивается информация по PIN2. Клиент вводит это значение в заполняемую форму и возвращает ее торговой точке.
Здесь следует заметить, что владелец карты в действительности ведет диалог в защищенной SSL-сессии не с торговой точкой, а с виртуальный POS-сервером, через который работает торговая точка (система STB CARD в настоящее время использует сервер Assist – http://www.assist.ru).
Возвращаясь к схеме STB CARD, отметим, что, конечно же, в заполненной клиентом форме PIN2 не содержится, а в действительности все выглядит следующим образом: торговая точка (точнее, сервер Assist), определив, что имеет дело с картой банка STB CARD, передает владельцу карты форму, содержащую подписанный java-апплет, реализующий некоторый симметричный алгоритм шифрования. При этом PIN2 играет роль секретного ключа этого алгоритма шифрования, а шифруемые данные получаются в результате применения хэш-функции к номеру карты, сумме и дате транзакции, а также случайному числу Nn генерируемому торговой точкой. Таким образом, в заполненной владельцем карты форме присутствует только результат шифрования перечисленных выше данных о транзакции на ключе PIN2.
Далее торговая точка формирует авторизационное сообщение, передаваемое на хост обслуживающего банка, содержащее помимо “стандартных” данных транзакции еще результат шифрования и случайное число Nn.
Эмитент карты, получив сообщение торговой точки, по номеру карты вычисляет значение PIN2, и далее по номеру карты, сумме и дате транзакции, а также по случайному числу Nn, вычисляет результат шифрования этих данных на ключе PIN2. Если полученная величина совпадает с аналогичной величиной полученной из сообщения торговой точки, верификации PIN-коды считается выполненной успешно. В противном случае транзакция отвергается.
Таким образом, технология проверки PIN-кода, принятая в системе STB CARD, в действительности обеспечивает не только динамическую аутентификацию клиента, но еще и гарантирует «сквозную» целостность некоторых данных о транзакции (сумма транзакции, номер карты). Под «сквозной» целостностью здесь понимается защита от модификации данных на всем протяжении от их передачи от клиента до банка-эмитента.
Минусы данного подхода состоят в следующем:
- для реализации схемы проверки значения PIN-кода необходимо, чтобы торговая точка умела формировать соответствующую форму с java-апплетом, что сразу сужает область применения схемы в относительно небольшом множестве торговых точек;
- использование длинного (16 hex цифр) ключа делает его применение на практике крайне неудобным для владельца карты;
- защита от подставки (форма, запрашивающая PIN2, предоставляется клиенту не торговой точкой, а мошенником, с целю узнать PIN2) основана на надежности аутентификации клиентом сервера торговой точки, а также на подписывании апплета секретным ключом сервера торговой точки. Поскольку нарушение обоих защит приводит только к появлению на экране монитора владельца карты соответствующего предупреждения, сопровождаемого вопросом продолжить сессию или нет, то особенно доверять этим формам защиты не стоит;
- использование хэш-функции в алгоритмах шифрования, как известно данная функция обратима;
В результате проведенного анализа платежные системы сформировали основные требования к схемам проведения транзакции в электронной коммерции, обеспечивающим необходимый уровень ее безопасности.
Эти требования сводятся к следующему:
- Аутентификация участников покупки (покупателя, торговой точки и ее обслуживающего банка). Под аутентификацией покупателя (продавца) понимается процедура, доказывающая (на уровне надежности известных криптоалгоритмов) факт того, что данный владелец карты действительно является клиентом некоторого эмитента-участника (обслуживающего банка-участника) данной платежной системы. Аутентификация обслуживающего банка доказывает факт того, что банк является участником данной платежной системы.
- Реквизиты платежной карты (номер карты, срок ее действия, CVC2/CVV2 и т. п.), используемой при проведении транзакции, должны быть конфиденциальными для торговой точки.
- Невозможность отказа от транзакции для всех участников транзакции, то есть наличие у всех участников неоспоримого доказательства факта совершения покупки (заказа или оплаты).
- Гарантирование магазину платежа за электронную покупку – наличие у торговой точки доказательства того, что заказ был выполнен.
Продолжение см. : БЕЗОПАСНОСТЬ ТРАНЗАКЦИЙ В ЭЛЕКТРОННОЙ КОММЕРЦИИ (ПРОТОКОЛ SET). ЧАСТЬ II
Используемый материал:
1. И. Голдовский «Безопасность платежей в Интернете»
2. Дэвид Козье «Электронная коммерция»
3. К. Пэйтел, М. П. Мак-Картний «Секреты успеха в электронном бизнесе»
4. И. Успенский «Энциклопедия Интернет-бизнеса»
Статья опубликована в журнале "Экспресс-Электроника" №4, 2002, издательство FineStreet
Контекстная реклама
Бегун
WebMoney WMR WMZ Ввод Вывод!
WebMoney Ввод Вывод WMR WMZ E-gold выгодно! В Мос
ве и по всей России!
Автор: Fenix
Дата: 00:01:17 20.01.02
Безопасность транзакций в электронной коммерции (протокол Set). Часть II
http://www.server.md/articles/53/
Данный материал является второй частью статьи о безопасности транзакций в электронной коммерции (см. БЕЗОПАСНОСТЬ ТРАНЗАКЦИЙ В ЭЛЕКТРОННОЙ КОММЕРЦИИ (ВВЕДЕНИЕ). ЧАСТЬ I.). Нижележащий материал будет посвящен протоколам используемым в электронной коммерции, в частности протоколу SET.
Итак, далее под протоколом в электронной коммерции понимается алгоритм, определяющий порядок взаимодействия участников транзакции (владельца карты, торговой точки, обслуживающего банка, банка-эмитента, центра сертификации) и форматы сообщений, которыми участники транзакции электронной коммерции обмениваются друг с другом с целью обеспечения процессов авторизации и расчетов.
В данный момент наиболее распространенным протоколом, используемым при построении систем электронной коммерции (по некоторым оценкам не менее 99%) является протокол SSL, о котором достаточно много и подробно уже писалось в сети, поэтому здесь он рассматриваться не будет, мы проведем лишь короткий его обзор.
Широкое распространение протокола SSL объясняется в первую очередь тем, что на является составной частью всех известных браузеров и веб-северов. Это, означает, что фактически любой владелец карты, пользуется стандартными средствами доступа к Интернету, получает возможность провести транзакцию с использованием SSL.
Другие достоинства SSL – простота протокола для понимания всех участников транзакции и хорошие операционные показатели (скорость реализации транзакции). Последнее достоинство связанно с тем, что протокол в процессе передачи данных использует симметричные алгоритмы шифрования, которые на 2-4 порядка быстрее асимметричных при том же уровне криптостойкости.
В то же время, протокол SSL в приложении к электронной коммерции обладает рядом существенных недостатков.
Протоколы электронной коммерции, основанные на использовании SSL, не поддерживают аутентификацию клиента Интернет-магазином, поскольку сертификаты клиента в таких протоколах почти не используются. Использование «классических» сертификатов клиентами в схемах SSL является делом практически бесполезным. Такой «классический» сертификат, полученный клиентом в одном из известных центров сертификации, содержит только имя клиента и, что крайне редко, его сетевой адрес (большинство клиентов имеют динамический IP-адрес. В таком виде такой сертификат мало чем полезен торговой точке для проведения транзакции, поскольку может быть без большого труда получен мошенником. Для того, чтобы сертификат клиента что-то значил для торговой точки, необходимо, чтобы он устанавливал связь между номером карты клиента и его банком-эмитентом. Причем любой Интернет-магазин, в который обращается за покупкой владелец карты с сертификатом, должен иметь возможность проверить эту связь (возможно с помощью своего обслуживающего банка).
Другими словами, такой сертификат должен быть получен клиентом в своем банке-эмитенте. Формат сертификата, специальные процедуры маскировки номера карты в сертификате (очевидно, номер карты не должен присутствовать в сертификате в открытом виде), процедуры распространения и отзыва сертификатов, а также многое другое в этом случае должно быть оговорено между всеми участниками транзакции. Иначе говоря, требуется создание иерархической инфраструктуры центров сертификации (по аналогии с тем, как это делается в протоколе SET, о чем будет рассказано далее). Без создания такой инфраструктуры все разговоры об обеспечении взаимной аутентификации участников транзакции не имеют смысла.
Отсутствие аутентификации клиента в схемах SSL является самым серьезным недостатком протокола, который позволяет мошеннику успешно провести транзакцию, зная только реквизиты карты. Тем более, протокол SSL не позволяет аутентифицировать клиента обслуживающим банком (аутентификация клиента обслуживающим банком является важным элементом защиты последнего от недобросовестных действий торговой точки и обеспечивается протоколом SET).
При использовании протокола SSL торговая точка аутентифицируется только по своему адресу в Интернете т. е. по URL. Это значит, что клиент, совершающий транзакцию, не аутентифицирует торговую точку в том смысле, о котором говорилось ранее (не получает доказательств существования договорных отношений между торговой точкой и его обслуживающим банком-участником платежной системы). Аутентификация торговой точки только по URL облегчает мошенническим торговым точкам доступ к различным системам электронной коммерции. В частности, торговые точки, занимающиеся сбором информации о картах клиентов, могут получить сертификат в каком-либо известном центре сертификации общего пользования (например, Verisign, GTE, Thawte и т. п.) на основании только своих учредительных документов, после чего дорога к мошенничествам для них становится открытой.
Справедливости ради следует заметить, что проверка сертификата сервера торговой точки производится только по URL сервера из-за того, что так устроены все известные браузеры на рабочих местах клиентов. Протокол SSL позволяет передавать приложениям, работающим через браузер, информацию, которая может анализироваться этими приложениями (например, имя владельца сертификата, время и дату начала установления сессии и т. п.). На основе анализа полученных данных приложение может вмешиваться в процесс работы протокола (например, признать аутентификацию одного из участников SSL-сессии неуспешной и прервать сессию). Чтобы такой дополнительный анализ был возможен, требуется специальное приложение, использующее функциональность браузера. Такое приложение реализуется в рамках так называемого электронного бумажника (кошелька) – специального ПО, предназначенного для реализации клиентом электронной покупки.
Использование электронного кошелька помимо того, что подразумевает некоторые усилия со стороны клиента (кошелек нужно загрузить), а также наличие центра, распределяющего такие кошельки, само по себе не решает проблему. Для решения проблемы требуется все та же иерархическая инфраструктура центров сертификации, о которой говорилось выше. Легальность торговой точки должна устанавливаться только проверкой того факта, что сертификат открытого ключа торговой точки, соответствующий его закрытому ключу, выдан обслуживающим банком, имеющим всем известный сертификат платежной системы.
Протокол SSL не поддерживает цифровой подписи, что затрудняет процесс разрешения конфликтных ситуаций, возникающих в работе платежной системы (цифровая подпись используется в начале установления SSL-сессии при аутентификации участников сессии). Для доказательства проведения транзакции требуется либо хранить в электронном виде весь диалог клиента и торговой точки (включая процесс установления сессии), что дорого с точки зрения затрат ресурсов памяти и на практике не используется, либо хранить бумажные копии, подтверждающие получение клиентом товара.
При использовании SSL не обеспечивается конфиденциальность данных о реквизитах карты для торговой точки. Для рассмотрения протокола SET, введем следующее определение, под устойчивым протоколом подразумевается, то что, он обеспечивает на уровне криптостойкости алгоритмов цифровой подписи и шифрования:
- аутентификацию владельца карты другими участниками транзакции: торговой точкой, обслуживающим банком;
- аутентификацию торговой точки другими участниками транзакции: владельцем карты, обслуживающим банком;
- аутентификацию обслуживающего банка торговой точкой;
- конфиденциальность сообщений, которыми обмениваются участники транзакции через Интернет;
- конфиденциальность информации о реквизитах карты для торговой точки;
- целостность данных, которыми обмениваются участники транзакции;
- невозможность отказа от транзакции (non-repudiation) – наличие для каждого участника транзакции электронного практически неопровержимого доказательства факта совершения транзакции.
Как следует из сказанного ранее, протокол SSL не является устойчивым.
ОПИСАНИЕ ПРОТОКЛОА SET
Архитектура системы центров сертификации
Как уже отмечалось ранее, необходимым условием создания глобальной системы аутентификации, основанной на использовании асимметричных алгоритмов шифрования, является наличие иерархической однокорневой системы центров сертификации. Основные функции системы центра сертификации – генерация и распределение сертификатов открытых ключей, обновление сертификатов, а также генерация и распределение списков отозванных ключей (Certificate Revocation Lists, CRL).
В протоколе SET центр сертификации имеет 4-уровневую архитектуру основанную на использовании протокола 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, ВСА, ССД, РСА. Оператором ССА могут являться банк-эмитент карточек, для которых выпускаются сертификаты, платежная система или третья сторона, определяемая правилами конкретной платежной системы.
Центр сертификации уровня МСА отвечает за генерацию и доставку сертификатов открытых ключей торговых точек. Запросы на получение сертификатов поступают в МСА от торговых точек либо через Web-страницы, либо по электронной почте. Для генерации сертификата торговой точки МСА должен поддерживать специальную процедуру идентификации торговой точки, определенную обслуживающим банком данной торговой точки. МСА также отвечает за распространение в адрес торговой точки списков CRL, сгенерированных RCA, ВСА, GCA, РСА. Оператором МСА могут являться обслуживающий банк торговой точки, платежная система или третья сторона, определяемая правилами конкретной платежной системы.
Центр сертификации уровня РСА отвечает за генерацию и доставку сертификатов открытых ключей платежным шлюзам. РСА также отвечает за генерацию и распространение списка CRL, содержащего ранее эмитированные данным РСА сертификаты открытых ключей, для которых соответствующие им закрытые ключи оказались скомпрометированными на момент рассылки CRL.
РСА отвечает за распространение в адрес платежных шлюзов листов CRL, сгенерированных RCA, ВСА, GCA, РСА. Оператором РСА могут являться обслуживающий банк, платежная система или третья сторона, определяемая правилами рассматриваемой платежной системы.
В протоколе SET используются четыре типа пар асимметричных ключей, отличающихся друг от друга по своему назначению:
- ключ для подписи (Digital Signature Key, используется для идентификации владельца ключа);
- ключ для шифрования данных (Key Encipherment/Data Encipherment Key, или иначе KeyExchange 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. Этот корневой ключ подписи сертификатов генерируется в двух экземплярах — действующая пара ключей R1 и пара ключей R2, которая будет действовать после окончания срока действия пары R1. В сертификате открытого ключа пары R1 подписанном закрытым ключом этой же пары, содержится значение хэш-функции открытого ключа пары R2. Поэтому, п...
Ділись своїми роботами та отримуй миттєві бонуси!
0%
Оголошення від адміністратора