Защита удаленных транзакций при дистанционном банковском обслуживании (на примере ОАО «Сбербанк России)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

 

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

 

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

 

2.4 Протоколы SSL и SET.

Самый известный протокол Интернета- SSL (Secure Socket Layer). Этот протокол

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

браузеров и Web-серверов (сегодня используется версия 3.0 протокола SSL). Протокол реализуется между транспортным и сеансовым уровнями эталонной модели взаимодействия

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

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

Последняя версия протокола SSL поддерживает три режима аутентификации:

— взаимную аутентификацию сторон;

— одностороннюю аутентификацию сервера (без аутентификации клиента);

Очевидно, что последний вариант представляет собой экзотический случай, так как

взаимодействующие стороны оказываются незащищенными от возможных атак, связанных с

подменой участников, хотя при этом и обеспечивается защита от несанкционированного

доступа самого установленного соединения.

В упрощенном виде процедура установления защищенного режима взаимодействия

между клиентом и Web-сервером в соответствии с протоколом SSL выглядит следующим

образом (рассматривается вариант односторонней аутентификации сервера со стороны клиента.

 

Для защиты трафика в Интернете помимо протокола SSL используется протокол SHTTP

(Secure HTTP). Этот протокол обеспечивает  целостность и защиту документов, передаваемых по протоколу HTTP. В  отличие от протокола SSL, расположенного  между транспортным уровнем (TCP) и  протоколами сеансового уровня, протокол S-HTTP находится на

прикладном уровне ЭМВОС, что позволяет с его помощью защищать не транспортное соединение, а данные, передаваемые по соединению. Это повышает производительность протокола защиты информации, но ценой ограничения применимости механизма защиты только приложением HTTP.

Достоинства протокола:

1. Широкое распространение протокола SSL, которое объясняется в первую  очередь

тем, что он является составной частью всех известных Интернет-браузеров и Web-серверов.

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

доступа к Интернету, получает возможность провести транзакцию с использованием SSL;

2. Простота протокола для понимания  всех участников ЭК;

3. Хорошие операционные показатели (скорость реализации транзакции). Последнее

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

симметричные протоколы шифрования, которые на 2-4 порядка быстрее асимметричных при

том же уровне криптостойкости.

Недостатками протокола SSL в приложении к ЭК являются:

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

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

2. Протокол SSL не позволяет аутентифицировать  клиента обслуживающим банком

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

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

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

весь диалог клиента и ТП (включая процесс установления сессии), что дорого с точки зрения

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

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

неэлектронных ТП).

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

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

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

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

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

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

Интернет;

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

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

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

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

 

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

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

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

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

ТП необходимых сертификатов и списков CRL, а также предоставления информации ТП о

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

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

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

Gateway Certificate Request/Response Messages. Эта пара сообщений позволяет ТП

запросить у платежного шлюза его сертификат Key-Exchange Key.

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

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

Inquiry Request/Response Messages. С помощью этой пары сообщений владелец

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

Authorization Reversal Request/Response Messages. Пара сообщений  используется

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

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

Capture Request/Response Messages. Сообщение Capture Request передается от ТП к

платежному шлюзу и запрашивает у обслуживающего банка платеж за сделанную покупку.

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