Борботько Т.В. Защита информации в банковских технологиях

Подождите немного. Документ загружается.

111

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

ным участникам транзакции ЭК надежно аутентифицировать друг друга.

В протоколе SET используются четыре типа пар асимметричных ключей, отличаю-

щихся друг от друга по своему назначению:

— ключ для подписи (Digital Signature Key, используется для идентификации вла-

дельца ключа);

— ключ для шифрования данных (Key Encipherment/Data Encipherment Key, или

иначе Key-Exchange Key, ключ, используемый для шифрования данных в процессе проведе-

ния транзакции ЭК);

— ключ для подписывания сертификатов (Certificate Signature Key);

— ключ для подписывания списков отозванных сертификатов CRL (CRL Signature

Key).

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

ЭК.

Таблица 8

Типы ключей в протоколе SET

Участник системы ЭК

Digital

signature

key encipherment/

data encipherment

Cert signature

CRL

signature

Владелец карты

ТП

Платежный шлюз

Cardholder Certificate Authority

Merchant Certificate Authority

Payment Certificate Authority

Geopolitical Certificate

Authority

Brand Certificate Authority

Root Certificate Authority

Из табл. 8 следует, что владельцу карты достаточно иметь только один ключ типа

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

чи всех четырех типов. Далее на примерах процессов сертификации владельца карты в ССА

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

асимметричных ключей.

Разнообразие типов ключей, кроме того, что повышает безопасность системы ЭК в

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

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

ключи различной длины, что повышает производительность системы в целом. Например,

ключ ТП Key Exchange Key может иметь более короткую длину по сравнению с ключом ТП

Digital Signature Key - для того, чтобы при необходимом уровне криптостойкости уменьшить

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

Размер асимметричных ключей, используемых в протоколе SET, не фиксирован и

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

денные в табл. 9.

Формат сертификата открытого ключа в протоколе SET удовлетворяет стандарту

Х.509 v.3. Сертификат содержит следующие данные:

— версию протокола Х.509 (всегда устанавливается значение, равное 3)

— Serial Number - серийный номер сертификата - уникальный целочисленный номер

сертификата, присваиваемый ЦС, выдавшим сертификат;

— Algorithm Identifier - идентификатор алгоритма ЭЦП, используемого ЦС для под-

писывания сертификата;

— Issuer Name - имя ЦС, генерирующего сертификат;

— срок начала действия сертификата;

112

— срок окончания действия сертификата;

— Subject Name - имя владельца сертификата;

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

ключ;

— значение сертифицируемого открытого ключа;

— расширения (например, информация о ключе ЦС - эмитента данного сертификата;

уровень владельца сертификата в протоколе SET, тип сертификата (например, сертификат

владельца карты, сертификат ТП и т.п.) и другое);

— цифровую подпись сертификата, сделанную с использованием Certificate Signing

Key ЦС.

Таблица 9

Рекомендуемые размеры асимметричных ключей

Entity

Message

Signature

Key-Exchange

Certificate Signing

CRL Signing

Владелец карты

1024

ТП

1024

Платежный шлюз

1024

Cardholder CA

1024

Merchant CA

1024

Payment Gateway CA

1024

Brand Geo-political CA

1024

Brand CA

1024

Root CA

2048

Подлинность SET-сертификатов удостоверяется с помощью иерархической цепи

проверок.

Любой ЦС, выдавший сертификат следующему за ним в иерархии звену, в свою оче-

редь, должен иметь действительный сертификат от вышестоящей организации. Удостовере-

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

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

поля:

— поля Issuer Name в сертификате нижнего уровня и Subject Name в сертификате

более высокого уровня;

— поля Certlssuer и CertSerialNumber из Х.509 Extensions сертификата нижнего

уровня соответственно с полями Issuer Name и Serial Number в сертификате более высокого

уровня.

При положительном результате сравнения в сертификате нижнего уровня проверя-

ется:

— срок действия сертификата;

— срок действия ключа, указанного в сертификате;

— уровень владельца сертификата в иерархии системы ЦС;

— соответствие типа сертификата его содержимому;

— использование по назначению ключа, указанного в сертификате,

— и некоторые другие поля.

В сертификате более высокого уровня проверяется:

— срок действия сертификата;

— срок действия ключа, указанного в сертификате;

— уровень владельца сертификата в иерархии системы ЦС;

— соответствие типа сертификата его содержимому;

— использование по назначению ключа, указанного в сертификате, и некоторые

другие поля.

113

Реализация транзакций в протоколе 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 после выполнения заказа, связанного с электронной покупкой.

Credit Request/Response Messages. Эта пара используется для того, чтобы вернуть

ранее сделанный платеж обслуживающего банка в адрес ТП.

Credit Reversal/Response Messages. Эта пара сообщений позволяет ТП отменить

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

Рассмотрим теперь подробнее, каким образом реализуется операция электронной

покупки с использованием протокола SET.

Владелец карты инициирует покупку с помощью сообщения PinitReq. В этом сооб-

щении владелец карты передает ТП сформированный им идентификатор пары сообщений

PinitReq/PinitRes, идентификатор транзакции LID-C, сгенерированный владельцем карты для

учета в системе владельца карты, идентификатор платежной системы Brand ID, карточкой

которой владелец карты собирается совершить электронную покупку, BIN карточки (первые

6 цифр номера карты), язык, используемый владельцем карты для совершения операции, па-

раметрически «отпечатки» сертификатов, списков CRL и каталога BCI, хранящихся в систе-

ме владельца карты, случайное число Chall-C, сгене-рированное владельцем карты, парамет-

рически идентификатор транзакции в системе ТП, использовавшийся в сообщении, иниции-

ровавшем систему владельца карты на совершение транзакции.

В ответном сообщении PinitRes ТП формирует следующие данные:

— копирует из запроса владельца карты данные LID-C и язык;

114

— генерирует глобальный идентификатор транзакции XID;

— копирует из запроса PinitReq «отпечатки» сертификатов, списки отозванных сер-

тификатов, каталоги BCI, Chall-C;

— генерирует случайное число Chall-M;

— на основании Brand ID, BIN и сертификата владельца карты выбирает соответст-

вующий платежный шлюз и вставляет в сообщение сертификат Key-Exchange Key этого пла-

тежного шлюза;

— вставляет в сообщение текущий каталог BCI, если в запросе клиента «отпечаток»

каталога BCI отсутствовал либо присутствовал «отпечаток» уже неактуального каталога (на-

помним, что в соответствии с принятыми в протоколе SET соглашениями наряду с BCI в по-

ле CRL данных SignedData передаются также ассоциированные с данным BCI списки CRL);

— некоторые другие данные.

ТП подписывает данные своим закрытым ключом Signing Key и направляет сформи-

рованное таким образом сообщение владельцу карты.

Владелец карты проверяет полученные сертификаты открытого ключа подписи ТП и

открытого ключа Key-Exchange Key платежного шлюза, после чего проверяется цифровая

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

После этого владелец карты начинает формирование сообщения PReq. Это сообще-

ние состоит из двух частей: инструкции по заказу (Order Instruction, или сокращенно — OI) и

платежной инструкции (Payment Instruction, или сокращенно PI).

OI предназначено для ТП и включает в себя значение Chall-M из сообщения PinitRes,

идентификатор транзакции XID, размер транзакции и валюту транзакции, идентификатор

ТП, идентификатор batch, к которому должна быть отнесена покупка, номер заказа в системе

магазина, хэш-функцию от PI (Н2) и некоторую другую информацию. PI предназначено для

платежного шлюза и включает в себя идентификатор транзакции XID, величину TranStain,

представляющую собой хэш-функцию от секрета карты S и XID, хэш-функцию OI (H,), па-

раметрически значение CVC2/CVC2, 2-ю дорожку магнитной полосы карты и другую ин-

формацию.

Далее владелец карты вычисляет хэш-функцию от последовательности, состоящей

из значений хэш-функции от PI и OI (H), и подписывает полученное значение своим секрет-

ным ключом.

Владелец карты генерирует случайным образом симметричный ключ К1, с помощью

которого он шифрует PI. Значение ключа К1 вместе с данными по карте (номер карты, срок

ее действия и секрет карты), в свою очередь, закрываются с помощью открытого ключа Key-

Exchange Key платежного шлюза. Сообщение Preq состоит из OI, зашифрованной инструк-

ции PI, зашифрованных данных о реквизитах карты и ключе К,, цифровой подписи владель-

ца карты.

ТП, получив сообщение PReq, проверяет сертификат владельца карты, после чего

проверяет цифровую подпись владельца карты. Для проверки цифровой подписи ТП вычис-

ляет значение хэш-функции от OI и далее, используя значение хэш-функции для PI (Н2), вы-

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

шифруется полученное из сообщения PReq значение цифровой подписи. Если дешифрован-

ное значение совпадает с общим значением, - подпись была сделана владельцем сертификата

открытого ключа владельца карты. Таким образом ТП аутентифицирует владельца карты.

Далее ТП подготавливает сообщение AuthReq. В это сообщение без изменений из

сообщения PReq включены зашифрованная платежная инструкция PI, зашифрованный сим-

метричный ключ К1 ( и данные о реквизитах карты, а также цифровая подпись владельца

карты. Кроме этих данных ТП формирует авторизационный запрос, содержащий информа-

цию о размере транзакции, идентификаторе ТП, идентификатор транзакции XID, случайное

число Chall-P и другую. Эта информация подписывается ключом Signing Key ТП, закрывает-

ся симметричным ключом К2, сгенерированным ТП по случайному закону, который в свою

очередь закрывается открытым ключом Key-Exchange Key платежного шлюза.

115

Платежный шлюз, получив AuthReq, дешифрует с помощью закрытого ключа Key-

Exchange Key оба симметричных ключа К1 и К2, а также данные о реквизитах карты, де-

шифрует данные о транзакции и PI, проверяет подпись владельца карты (по аналогии с тем,

как это делает ТП, для этого используется значение H1, содержащееся в PI), проверяет на

равенство значения XID из информации о транзакции и из PL Таким образом, платежный

шлюз аутентифицирует как ТП, так и владельца карты. На основании полученных данных

платежный шлюз готовит стандартное сообщение (например, в формате ISO 8583) для пере-

дачи его в платежную систему на авторизацию эмитента карты.

Получив из платежной системы ответ, платежный шлюз генерирует и подписывает

своим закрытым Signing Key сообщение AuthRes (в сообщении содержится случайная вели-

чина Chall-P, также данные Capture Token, в которых платежный шлюз запрашивает у ТП

ожидаемые им данные от ТП в сообщении Capture Request). Сообщение зашифровывается с

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

крывается с помощью открытого ключа ТП.

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

шлюза и формирует сообщение PRes, содержащее Chall-C, подписывая его своим закрытым

Signing Key.

Владелец карты, получив сообщение PRes, проверяет цифровую подпись ТП. На

этом процесс электронной покупки может быть закончен.

Расчеты между ТП и обслуживающим банком осуществляются либо на основании

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

са Capture Request от ТП.

Относительно протокола SET имеют место следующие утверждения.

Теорема 1. Протокол SET является устойчивым протоколом ЭК.

Доказательство этой теоремы следует из приведенного описания протокола.

Таким образом, SET обладает следующими свойствами:

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

пешно выполнить SET-транзакцию. Помимо реквизитов карты необходимо иметь закрытый

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

2. ТП при выполнении SET-транзакции точно знает, что владелец карты, совершаю-

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

рого открытый ключ сертифицирован банком-эмитентом клиента.

3. Клиент точно знает, что ТП, в котором совершается SET-транзакция, является ис-

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

рован обслуживающим банком ТП.

4. ОБ точно знает, что владелец карты и ТП являются подлинными, то есть обладают

сертифицированными ключами.

5. Информация о реквизитах карты не известна ТП.

6. ТП и владелец карты имеют заверенные подписями соответственно владельца

карты и ТП подтверждения факта совершения транзакции, что делает невозможным отказ от

результатов операции ни одного из участников транзакции ЭК.

Теорема 2. Протокол SET является единственным открытым (известным) ус-

тойчивым протоколом ЭК.

Сегодня не существует никакого другого (кроме SET) опубликованного устойчивого

протокола ЭК. Другими словами, на рынке аппаратно-программных решений, реализующих

устойчивый протокол ЭК, не существует альтернативы продуктам, реализующим SET. VISA

International предполагает в ближайшее время опубликовать спецификации нового глобаль-

ного стандарта аутентификации, называемого 3D Secure. Однако неочевидно, что этот стан-

дарт будет определять устойчивый протокол ЭК.

Теорема 3. Протокол SET де-факто является отраслевым стандартом в области

пластиковых карт.

116

Будучи признанным ведущими международными платежными системами (VISA,

MasterCard, Europay, AmEx, Diners Club) в качестве стандарта ЭК, SET де-факто является

отраслевым стандартом.

Таким образом, протокол SET является на сегодняшний день единственным откры-

тым и устойчивым протоколом ЭК.

10.4. Сравнительная характеристика протоколов SSL и SET

В табл. 10 приведены результаты сравнения протоколов SET и SSL по отношению к

наиболее вероятным типам мошенничества в ЭК.

Таблица 10

Результаты сравнения протоколов SET и SSL

Тип мошенничества

SET решает

проблему?

SSL решает

проблему?

Мошеннические транзакции по «правильным» кар-

там

Да

Нет

Злоупотребления магазинов

Да

Нет

Фиктивные магазины

Нет

Фиктивные банки

Да

Нет

Компрометация данных

Да

Из табл. 10 следует, что протокол SSL решает только проблему защиты данных о ре-

квизитах карты.

Важным критерием сравнения протоколов является вычислительная мощность (про-

изводительность) компьютеров и серверов владельца карты, ТП и шлюза обслуживающего

банка (аппаратно-программного комплекса, конвертирующего сообщения ЭК в стандартные

сообщения платежной системы), необходимая для реализации того или иного протокола.

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

криптографические операции при использовании SSL, на порядок меньше аналогичной ве-

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

мени (доли секунды) практической разницы для покупателя от того, используется SET или

SSL нет.

Несмотря на убедительные преимущества протокола SET, его внедрение связано с

возникновением различного рода проблем. В первые 2-3 года распространения стандарта по

миру главной проблемой являлось отсутствие взаимной совместимости (interoperability) про-

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

Проблема успешно была решена (и эффективно решается сегодня для новых разработчиков

ПО) усилиями компании SETCo и разработчиков ПО. Сегодня на рынке продается около 50

различных решений ЭК, в основе которых лежит протокол SET, более чем от 20 поставщи-

ков программного обеспечения.

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

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

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

магазины не спешат инвестироваться в новое решение. Это хорошо видно на примере Дании,

являющейся одним из лидеров по внедрению протокола SET, кампании, которой при заклю-

чении договоров на обслуживание предлагают Интернет-магазинам обе технологии - SSL и

SET. Количество заключенных договоров на работу по технологии SSL в 10 раз больше чем

по стандарту SET.

Кроме того, отсутствие инфраструктуры Интернет-магазинов, использующих стан-

дарт SET, сдерживает банки-эмитенты от инвестиций в SET.

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

пользуют протокол SSL и различного рода технологические решения для уменьшения уров-

ня мошенничеств при проведении транзакций.

117

11. РЕАЛИЗАЦИЯ ЗАЩИЩЕННЫХ ПЛАТЕЖНЫХ СИСТЕМ

11.1. Система SWIFT

Сообщество SWIFT было организовано в 1973 году и в 1977 г. начали осуществлять-

ся первые операции с использованием сетей связи. Члены сообщества находятся в Южной,

Центральной и Северной Америке, Европе, Африке, Австралии и на Дальнем Востоке. На

сегодняшний день объединяет 3200 пользователей из 84 стран мира.

Система SWIFT предлагает пользователям своей системы следующие преимущест-

ва:

— повышение эффективности работы банков за счет стандартизации и современных

способов передачи информации, способствующих развитию автоматизации и рационализа-

ции банковских процессов;

— надежный обмен платежными сообщениями;

— сокращение операционных расходов по сравнению с телексной связью;

— удобный прямой доступ пользователей SWIFT к своим корреспондентам по всему

миру (доставка сообщения с обычным приоритетом в любую точку мира - 20 минут, достав-

ка срочного сообщения - 5 минут);

— использование стандартизованных сообщений SWIFT, позволяющее преодолеть

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

операций;

— повышение конкурентоспособности банков-членов SWIFT за счет того, что меж-

дународный и кредитный оборот все более концентрируется на пользователях SWIFT.

Стоимость передачи сообщений членами сообщества определяется по единому та-

рифу и зависит от количества соединений, адреса, объема сообщения. За счет высокой ин-

тенсивности трафика (более 1 млн. сообщений в день) стоимость передачи одного сообще-

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

основной функции (обмену сообщениями) система SWIFT также выполняет роль форума для

выработки соглашения о стандартах представления и передачи данных.

Существует две системы SWIFT: SWIFT I (введена в строй в 1977 году) и SWIFT II

(внедряется с 1990 года). Хотя по архитектуре эти системы различны, пользователь не отли-

чает сообщений, полученных по SWIFT I или SWIFT II. Ниже мы рассмотрим архитектуру и

защиту системы SWIFT II.

Архитектура системы SWIFT

В архитектуре SWIFT II можно выделить четыре основные уровня иерархии

(рис. 26):

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

тупа персонала банка в сеть. Терминалами системы SWIFT обычно являются персональные

компьютеры. Смонтированное оборудование может сдаваться "под ключ" (на базе мини-

ЭВМ компаний Unisys и NCR) или интегрироваться в существующую банковскую систему

(например на базе семейство мини-ЭВМ VAX компании DEC);

— региональный процессор (РП), основным назначением которого является органи-

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

группы стран). Места расположения РП заранее не определяются. Как правило, РП оснаща-

ются сдублированными ЭВМ фирмы Unisys (Unisys A Series);

— слайс-процессор (СП), необходимый для обмена сообщениями между подклю-

ченными к нему РП, краткосрочного или длительного архивирования сообщений и генера-

ции системных отчетов. Система SWIFT может сохранять передаваемые сообщения на срок

до 14 дней.

118

Рис. 26. Архитектура системы SWIFT

Это помогает избегать проблем, связанных с трактовкой текстов сообщений. На се-

годняшний день существует два СП, каждый из них которых оснащен тремя машинами A12

фирмы Unisys, одна из которой является резервной. Один СП может может обработать до

1,5 миллионов сообщений в день. Допускается включение в сеть дополнительных СП; про-

цессор управления системой (ПУС), выполняющий функции монитора системы, управления

системой и сетью. Существует два ПУС, один из которых находится в Голландии, а второй в

США. Каждый ПУС может контролировать состояние и управлять работой СП и РП, рабо-

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

ми, включая выбираемые пользователем прикладные задачи. ПУС единственный уровень

системы, который не занят обработкой сообщений, а предназначен исключительно для

управления системой SWIFT в целом.

На рис. 27. показаны пути передачи сообщений и платежей в наиболее общем слу-

чае.

Рис. 26. Процесс передачи сообщений и осуществления платежей

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

передачи информации и платежей.

Банк заказчика операции информирует банк-отправитель о необходимости послать

сообщение и переводит ему соответствующую сумму. Банк получателя при приеме сообще-

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

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

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

счет, зависит от типа валюты, в которой производятся расчеты. Если платежи осуществляют-

119

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

щую сумму в дебет счета банка-отправителя в своем банке. Наоборот, если платежи осуще-

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

себя счет банка получателя и предоставляет ему кредит на соответствующую сумму.

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

банки-посредники (рис. 26), это зависит от конкретных условий платежей. Уведомление бан-

ков корреспондентов о платежах осуществляется специальными сообщениями. Если в орга-

низации связи участвуют четыре банка посредника, то в сообщении идентифицируются банк

заказчика, расчетный банк и корреспонденты отправителя и получателя. При этом иденти-

фикаторы отправителя и получателя в тексте сообщении не указываются, так как они нахо-

дятся в его заголовке.

Обеспечение безопасности системы SWIFT

Безопасность в системе SWIFT обеспечивается применением организационных, про-

граммных и технических мер.

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

безопасности системы. Так банк, подключенный к системе, отвечает за правильную эксплуа-

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

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

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

страция системы. Управление защитой осуществляется управлением Главного инспектора.

Контроль защищенности системы осуществляется через случайные промежутки времени,

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

Защита банковских терминалов предусматривает разграничение доступа пользовате-

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

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

от SWIFT происходит в следующих случаях:

— при обнаружении помехи или обрыве соединения;

— при неоднократном обнаружении ошибки при передаче данных или в принятом

сообщении;

— при сбое РП, к которому подсоединены терминалы.

Сведения о подключении и отключении терминала регистрируются в специальном

журнале.

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

рование при помощи специальных устройств (STEN), устанавливаемых в тракте передачи

"банковский терминал - региональный процессор". Для шифрования информации использу-

ются три типа ключей: главный (64 бита), вторичный (128 бит) и шифрования данных

(64 бита). Главный и вторичный ключи устанавливаются представителями SWIFT. Ключ

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

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

по указанию Главного инспектора системы. Банкам предоставляется возможность устанав-

ливать собственные устройства шифрования для защиты линии связи (естественно после

консультаций с представителями SWIFT). Обеспечение конфиденциальности сообщений не

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

Для аутентификации пользователей и обеспечения целостности сообщений в систе-

ме SWIFT существует оригинальный алгоритм аутентификации, детали которого держатся в

секрете. Как и для любого такого алгоритма, базовыми требованиями являются надежное

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

тентификация достигается за счет четкого распределения ответственности. Ключи рассыла-

ются банкам попарно, другие банки и персонал сети доступа к ним не имеют; рассылается

также руководство по управлению ключами: процедура и время замены ключей и т.д. Кроме

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

120

перацией банков, однако, в этом случае ответственность за обеспечение безопасности ло-

жится на участников обмена.

В то же время аутентификации взаимодействующих организаций недостаточно для

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

задержки сообщений.

Для обеспечения целостности потока передаваемых сообщений применяется меха-

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

двумя (входной и выходной) последовательностями номеров. Входная последовательность

обрабатывается слайс-процессорами системы, выходная - получателями сообщений. Такой

механизм обеспечивает полный контроль за последовательностью переданных и полученных

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

щение не уничтожено и не продублировано.

Еще одна задача защиты - предотвращение передачи ложных сообщений, не иска-

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

решается банками - оконечными пользователями системы. Именно они ответственны за кор-

ректность переданных от их имени сообщений. Кроме того, на пунктах обработки и передачи

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

Для центральной части SWIFT, состоящей из слайс-процессоров, региональных про-

цессоров и линий связи, защита сообщений является задачей администрации системы. Дос-

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

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

щие слайс-процессоры между собой, слайс-процессоры и региональные процессоры, имеют

надежную криптозащиту. Персонал системы SWIFT не имеет доступа к содержимому пере-

сылаемых сообщений.

11.2. Система CHAPS

Клиринговая система CHAPS осуществляет поддержку электронных платежей меж-

ду небольшой (около 300) группой банков Лондона, большинство из которых представляют

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

Системой используется концепция расчетов "same-day" ("в тот же день") с помощью счетов

этих банков в Bank of England. Помимо CHAPS, все банки могут работать с любой другой

доступной сетью по своему усмотрению.

Архитектура системы CHAPS

Рис. 27. Архитектура системы CHAPS

В отличие от SWIFT система CHAPS (рис. 27) не имеет своих операционных цен-

тров, а использует общую сеть коммутации пакетов (Packet SwitchStream - PSS). Высокая

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

Tandem, рассчитанных на непрерывную работу.