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

Такие нарушения также называются симуляцией или моделированием. Цель “маскарада” -- сокрытие каких-либо действий за именем другого пользователя или присвоение прав и привилегий другого пользователя для доступа к его наборам данных или для использования его привилегий.

“Маскарад” -- это способ активного нарушения защиты системы, он является опосредованным воздействием, то есть воздействием, совершенным с использованием возможностей других пользователей.

Примером “маскарада” может служить вход в систему под именем и паролем другого пользователя, при этом система защиты не сможет распознать нарушение. В этом случае “маскараду” обычно предшествует взлом системы или перехват пароля.

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

“Маскарадом” также называют передачу сообщений в сети от имени другого пользователя. Способы замены идентификатора могут быть разные, обычно они определяются ошибками и особенностями сетевых протоколов. Тем не менее на приемном узле такое сообщение будет воспринято как корректное, что может привести к серьезным нарушениям работы сети. Особенно это касается управляющих сообщений, изменяющих конфигурацию сети, или сообщений, ведущих к выполнению привилегированных операций. [8]

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

“Маскарад” является достаточно серьезным нарушением, которое может привести к тяжелым последствиям, таким как изменение конфигурации системы (сети), утечка информации, нарушения работы АСОИБ. Для предотвращения “маскарада” необходимо использовать надежные методы идентификации и аутентификации, блокировку попыток взлома системы, контроль входов в нее. Также необходимо фиксировать все события, которые могут свидетельствовать о “маскараде”, в системном журнале для его последующего анализа.

Еще один вид нарушений - “Сборка мусора”. После окончания работы обрабатываемая информация не всегда полностью удаляется из памяти. Часть данных может оставаться в оперативной памяти, на дисках и лентах, других носителях. Данные хранятся на носителе до перезаписи или уничтожения; при выполнении этих действий на освободившемся пространстве диска находятся их остатки. Хотя прочитать такие данные трудно, однако, используя специальные программы и оборудование, все же возможно. Такой процесс принято называть “сборкой мусора”. Он может привести к утечке важной информации.

“Сборка мусора” -- активное, непосредственное воздействие на объекты АСОИБ при их хранении с использованием доступа. Это воздействие может привести к нарушению конфиденциальности информации.

Для защиты от “сборки мусора” используются специальные механизмы, которые могут быть реализованы в операционной системе и/или аппаратуре компьютера или в дополнительных программных (аппаратных) средствах. Примерами таких механизмов являются стирающий образец и метка полноты:

- стирающий образец -- это некоторая последовательность битов, записываемая на место, освобождаемое файлом. Менеджер или администратор безопасности АСОИБ может автоматически активизировать запись этой последовательности при каждом освобождении участка памяти, при этом стираемые данные уничтожаются физически;

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

Под “взломом системы” понимают умышленное проникновение в систему с несанкционированными параметрами входа, то есть именем пользователя и его паролем (паролями).

“Взлом системы” -- умышленное, активное воздействие на систему в целом. “Взлом системы” обычно происходит в интерактивном режиме.

Поскольку имя пользователя не является секретом, объектом “охоты” обычно становится пароль. Способы вскрытия пароля могут быть различны: перебор возможных паролей, “маскарад” с использованием пароля другого пользователя, захват привилегий. Кроме того, “взлом системы” можно осуществить, используя ошибки программы входа.

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

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

“Люк” -- это скрытая, недокументированная точка входа в программный модуль. “Люк” вставляется в программу обычно на этапе отладки для облегчения работы: программный модуль можно вызывать в разных местах, что позволяет отлаживать отдельные его части независимо. Но в дальнейшем программист может забыть уничтожить “люк” или некорректно его заблокировать. Кроме того, “люк” может вставляться на этапе разработки для последующей связи данного модуля с другими модулями системы, но затем, в результате изменившихся условий данная точка входа оказывается ненужной.

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

“Люк” относится к категории угроз, возникающих вследствие ошибок реализации какого-либо проекта (АСОИБ в целом, комплекса программ и т.д.). Поскольку использование “люков” может быть самым разным и зависит от самой программы, классифицировать данную угрозу как-либо еще затруднительно.

“Люки” могут оказаться в программах по следующим причинам:

- их забыли убрать;

- для использования при дальнейшей отладке;

- для обеспечения поддержки готовой программы;

- для реализации тайного контроля доступа к данной программе после ее установки.

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

Отметим, что программная ошибка “люком” не является. “Люк” -- это достаточно широко используемый механизм отладки, корректировки и поддержки программ, который создается преднамеренно, хотя чаще всего и без злого умысла. Люк становится опасным, если он не замечен, оставлен и не предпринималось никаких мер по контролю за ним.

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

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

Ниже рассмотрим некоторые (самые распространенные) виды подобных программ: “троянский конь”, вирус, “червь”, “жадная” программа, “захватчик паролей”.

“Троянский конь” -- программа, выполняющая в дополнение к основным (проектным и документированным) не описанные в документации действия. Аналогия с древнегреческим “троянским конем” таким образом вполне оправдана -- в не вызывающей подозрений оболочке таится угроза. Программы такого типа являются серьезной угрозой безопасности АСОИБ.

По характеру угрозы “троянский конь” относится к активным угрозам, реализуемым программными средствами, работающими в пакетном режиме. Он может угрожать любому объекту АСОИБ. Наиболее опасным является опосредованное воздействие, при котором “троянский конь” действует в рамках полномочий одного пользователя, но в интересах другого пользователя, установить личность которого порой невозможно.

Опасность “троянского коня” заключается в дополнительном блоке команд, тем или иным образом вставленном в исходную безвредную программу, которая затем предлагается (дарится, продается, подменяется) пользователям АСОИБ. Этот блок команд может срабатывать при наступлении некоторого условия (даты, времени и т.д., либо по команде извне). Запустивший такую программу подвергает опасности как себя и свой файлы, так и всю АСОИБ в целом.

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

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

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

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

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

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

Проблема защиты от вирусов может рассматриваться с двух сторон: как самостоятельная проблема и как одна из сторон проблемы общей защиты АСОИБ. И тот, и другой подходы имеют свои отличительные особенности и, соответственно, свои собственные методы решения проблемы.

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

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

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

Наиболее известный представитель этого класса - вирус Морриса (или, вернее, “червь Морриса”), поразивший сеть Internet в 1988 г. Наиболее подходящей средой распространения “червя” является сеть, все пользователи которой считаются дружественными и доверяют друг другу. Отсутствие защитных механизмов как нельзя лучше способствует уязвимости сети.

Самый лучший способ защиты от “червя” -- принять меры предосторожности против несанкционированного доступа к сети.

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

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

Кроме описанных выше, существуют и другие возможности компрометации пароля. Не следует записывать команды, содержащие пароль, в командные процедуры, надо избегать явного объявления пароля при запросе доступа по сети: эти ситуации можно отследить и захватить пароль. Не стоит использовать один и тот же пароль для доступа к разным узлам.

Соблюдение правил использования паролей -- необходимое условие надежной защиты.

2.3 Безопасность удаленных электронных платежей

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

Обмен электронными данными (ОЭД) -- это межкомпьютерный обмен деловыми, коммерческими, финансовыми электронными документами. Например, заказами, платежными инструкциями, контрактными предложениями, накладными, квитанциями.

ОЭД обеспечивает оперативное взаимодействие торговых партнеров (клиентов, поставщиков, торговых посредников и др.) на всех этапах подготовки торговой сделки, заключения контракта и реализации поставки. На этапе оплаты контракта и перевода денежных средств ОЭД может приводить к электронному обмену финансовыми документами. При этом создается эффективная среда для торгово-платежных операций [8]:

- возможно ознакомление торговых партнеров с предложениями товаров и услуг, выбор необходимого товара/услуги, уточнение коммерческих условий (стоимости и сроков поставки, торговых скидок, гарантийных и сервисных обязательств) в реальном масштабе времени;

- заказ товара/услуг или запрос контрактного предложения в реальном масштабе времени;

- оперативный контроль поставки товара, получение по электронной почте сопроводительных документов (накладных, фактур, комплектующих ведомостей и т.д.);

- подтверждение завершения поставки товара/услуги, выставление и оплата счетов;

- выполнение банковских кредитных и платежных операций.

К достоинствам ОЭД следует отнести:

- уменьшение стоимости операций за счет перехода на безбумажную технологию. Эксперты оценивают стоимость обработки и ведения бумажной документации в 3-8 % от общей стоимости коммерческих операций и доставки товаров. Выигрыш от применения ОЭД оценивается, например, в автомобильной промышленности США более чем в 200 условных единиц на один изготовленный автомобиль [8];

- повышение скорости расчета и оборота денег;

- повышение удобства расчетов.

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

Пересылка денег с помощью системы электронных платежей включает следующие этапы (в зависимости от конкретных условий и самой системы порядок может меняться):

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

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

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

- с корреспондентского счета первого банка во втором списывается требуемая сумма;

- определенный счет во втором банке увеличивается на требуемую сумму;

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

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

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

Для определения общих проблем защиты удаленных транзакций, можно выделить три основных этапа:

- подготовка документа к отправке;

- передача документа по каналу связи;

- прием документа и его обратное преобразование.

С точки зрения защиты в системах удаленных платежей существуют следующие уязвимые места [9]:

- пересылка платежных и других сообщений между банками или между банком и клиентом

- обработка информации внутри организаций отправителя и получателя;

- доступ клиента к средствам, аккумулированным на счете.

При пересылке платежных и других сообщений возникают следующие проблемы:

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

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

- в общем случае отправитель и получатель документа принадлежат к различным организациям и друг от друга независимы. Этот факт порождает проблему недоверия - будут ли предприняты необходимые меры по данному документу (обеспечение исполнения документа).

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

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

- перехват и подмена трафика (подделка платежных поручений, атака типа "человек посередине");

- IР-спуфинг (подмена сетевых адресов);

- отказ в обслуживании;

- атака на уровне приложений;

- сканирование сетей или сетевая разведка;

- использование отношений доверия в сети.

Причины, приводящие к появлению подобных уязвимостей:

- отсутствие гарантии конфиденциальности и целостности передаваемых данных;

- недостаточный уровень проверки участников соединения;

- недостаточная реализация или некорректная разработка политики безопасности;

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

- существующие уязвимости используемых операционных систем (ОС), ПО, СУБД, веб-систем и сетевых протоколов;

- непрофессиональное и слабое администрирование систем;

- проблемы при построении межсетевых фильтров;

- сбои в работе компонентов системы или их низкая производительность;

- уязвимости при управлении ключами.

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

Основные виды атак на финансовые сообщения и финансовые транзакции:

- раскрытие содержимого;

- представление документа от имени другого участника;

- несанкционированная модификация;

- повтор переданной информации.

Существует четыре основные формы удаленного банковского обслуживания клиентов [5]:

- домашнее (телефонное) обслуживание;

- расчет с автоматическим кассовым аппаратом (банкоматом);

- расчет в точке продажи;

- финансовый сервис с использованием всемирной сети Интернет.

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

Достоинства этого вида обслуживания:

- для клиента - большая доступность данных и управление своими финансовыми делами;

- для банка - уменьшение стоимости обслуживания.

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

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

- проверка состояния счета клиента;

- изменение параметров счета клиента;

- осуществление различных платежей;

- предоставление информации о:

а) страховом полисе клиента;

б) котировках ценных бумаг на фондовом рынке;

в) покупке и продаже акций;

г) обменных курсах валют и т.д.

Системы, обеспечивающие расчеты продавца и покупателя в точке продажи, (point-of-sale, POS). В основном, все терминалы, подключенные к этим системам, размещены на предприятиях торговли. Большинство таких терминалов установлены в супермаркетах, так как там совершается большое количество покупок в течении дня, а также в других магазинах и на автозаправочных станциях.

Системы POS обеспечивают следующие услуги:

- проверку и подтверждение чеков;

- проверку и обслуживание дебетовых и кредитных карточек;

- использование системы электронных расчетов.

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

Существует два типа систем POS. Основной из них предполагает, что продавец и покупатель имеют счета в одном и том же банке. Данные, необходимые для платежа, передаются через терминалы системы POS банковскому компьютеру, производится платеж, и деньги переводятся со счета покупателя на счет продавца. В более сложной системе участвуют два или более банков. При платеже сначала вызывается банк покупателя, производится платеж и записывается на магнитную ленту для передачи в расчетную палату. Расчетная палата в свою очередь пересылает данные о платеже в банк продавца, который кредитует платеж.

2.4 Проблемы идентификации при удаленном обслуживании

Персональный номер (идентификатор) (Personal Identification Number, PIN) - это последовательность цифр, используемая для идентификации клиента. Для ввода PIN как в АКА, так и в терминалах систем POS предусмотрена цифровая клавиатура, аналогичная телефонной. По способу назначения можно выделить следующие типы PIN [3]:

- назначаемые выведенные PIN;

- назначаемые случайные PIN;

- PIN, выбираемые пользователем.

Клиент различает только два типа PIN: PIN, который назначен ему банком, выдавшим карточку, и PIN, который пользователь может выбирать себе самостоятельно.

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

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

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

Всего существуют два основных способа проверки PIN: алгоритмический и неалгоритмический.

Алгоритмический способ проверки заключается в том, что у пользователя запрашивается PIN, который преобразуется по определенному алгоритму с использованием секретного ключа и затем сравнивается со значением PIN, хранившемся на карточке. Достоинством этого метода проверки является:

- отсутствие копии PIN на главном компьютере, что исключает его раскрытие персоналом банка;

- отсутствие передачи PIN между АКА и главным компьютером банка, что исключает его перехват злоумышленником или навязывание результатов сравнения;

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

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

Идентификация клиента с использованием PIN работает только в следующих случаях:

- отсутствует перехват карточки и/или PIN при передаче от банка клиенту;

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

- PIN невозможно узнать при доступе к системе другим пользователем;

- PIN иным образом не может быть скомпрометирован;

- в электронной системе банка отсутствуют сбои и ошибки;

- в самом банке нет мошенников.

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

3. ВЫБОР И ОБОСНОВАНИЕ МЕТОДОВ ЗАЩИТЫ УДАЛЕННЫХ БАНКОВСКИХ ТРАНЗАКЦИЙ

3.1 Основные требования обеспечения безопасности удаленных транзакций

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

- обеспечить защиту от случайных и умышленных ошибок

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

- поддерживать различные типы аппаратного и программного обеспечения, поставляемого различными производителями

- осуществлять управление и поддержку сети для обеспечения непрерывности работы и быстрой диагностики нарушений

- реализовывать полный спектр прикладных задач ОЭД, включая электронную почту

- реализовывать максимально возможное число требований партнеров

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

В системах обмена электронными документами должны быть реализованы следующие механизмы, обеспечивающие реализацию функций защиты на отдельных узлах системы и на уровне протоколов высокого уровня [4]:

- равноправная аутентификацию абонентов;

- невозможность отказа от авторства сообщения/приема сообщения;

- контроль целостности сообщения;

- обеспечение конфиденциальности сообщения;

- управление доступом на оконечных системах;

- гарантии доставки сообщения;

- невозможность отказа от принятия мер по сообщению;

- регистрация последовательности сообщений;

- контроль целостности последовательности сообщений;

- обеспечение конфиденциальности потока сообщений.

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

- скрыть содержание документа от посторонних лиц (обеспечение конфиденциальности документа) путем шифрования его содержимого;

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

- своевременно обнаружить искажение, подделку документа (обеспечение целостности документа) путем введения криптографического контрольного признака;

- удостовериться в том, что абонент, с которым происходит взаимодействие в сети, является именно тем, за кого он себя выдает (аутентификация абонента/источника данных).

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

В общедоступных сетях распространены нападения хакеров. Это высококвалифицированные специалисты, которые направленным воздействием могут выводить из строя на длительное время серверы АБС (DоS-атака) или проникать в их системы безопасности. Практически все упомянутые угрозы способен реализовать хакер-одиночка или объединенная группа. Хакер может выступать как в роли внешнего источника угрозы, так и в роли внутреннего (сотрудник организации).

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

- шифрование содержимого документа;

- контроль авторства документа;

- контроль целостности документа;

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

- ведение сессий на уровне защиты информации;

- динамическая аутентификация;

- обеспечение сохранности секретных ключей;

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

- использование электронного сертификата клиента;

- создание защищенного соединения клиента с сервером.

Также необходимо применять комплекс технических средств защиты интернет-сервисов:

- брандмауэр (межсетевой экран) - программная и/или аппаратная реализация

- системы обнаружения атак па сетевом уровне;

- антивирусные средства;

- защищенные ОС, обеспечивающие уровень В2 но классификации защиты компьютерных систем и дополнительные средства контроля целостности программ и данных;

- защита на уровне приложений: протоколы безопасности, шифрования, ЭЦП, цифровые сертификаты, системы контроля целостности;

- защита средствами системы управления БД;

- защита передаваемых но сети компонентов программного обеспечения;

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

- обманные системы;

- корректное управление политикой безопасности.

Для проведения безопасных банковских транзакций должны выполняться:

- аутентификация документа при его создании;

- защита документа при его передаче;

- аутентификация документа при обработке, хранении и исполнении;

- защита документа при доступе к нему из внешней среды.

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

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

Под устойчивым протоколом подразумевается, то что, он обеспечивает на уровне криптостойкости алгоритмов цифровой подписи и шифрования [3]:

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

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

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

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

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

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

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

В данный момент наиболее распространенным протоколом, используемым при построении систем электронной коммерции является протокол 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. Эти сети осуществляют авторизацию платежей от эмитента к получателю и имеют свою систему защищенной передачи сообщений.

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