|
|
|
BC/NW 2003г., №1(3)/ 13.6 РАЗРАБОТКА ПРОТОКОЛА ЗАЩИЩЕННОЙ ПЕРЕДАЧИ ДАННЫХ ДЛЯ ЭЛЕКТРОННЫХ ПЛАТЕЖНЫХ СИСТЕМ Харченко
А.С., Голзицкий Д.И. (г. Москва, Московский
Энергетический Институт, Россия) На протяжении многих лет
компании обменивались деловой информацией с помощью частных сетей. Интернет дал
возможность внедрить торговлю в комплексную сеть коммерческой деятельности,
осуществляемой в мировом масштабе между постоянно увеличивающимся количеством
участников (как корпоративных, так и частных лиц). Для традиционной электронной
торговли сеть является средством передачи данных, для торговли через Интернет, сеть является рынком
осуществления сделок. В самом общем случае
электронную платежную систему можно рассматривать как набор правил и средств
взаимодействия покупателя, интернет-магазина (продавца) и банка. Покупатель и
продавец имеют свой счет в банке. Банк реализует три основные транзакции –
снятие со счета, платеж, депозит и является посредником покупателя и продавца.
Естественно, одна из основных проблем, которая возникает при разработке
платежной системы – насколько уязвим протокол взаимодействия между участниками
системы. Может ли кто-либо нарушить целостность передаваемых в результате
транзакций данных? Можно ли обманным путем получить чужие деньги? Важно
отметить, что в качестве нарушителя могут выступать как банк, покупатель и
продавец, так и любое другое лицо, ведь сеть открыта для всех. При осуществлении платежей с помощью сети необходимым
компонентом является защита передаваемой информации. Исходя из требований
защищенности, разрабатывается настоящий протокол, использующий в качестве
алгоритмов для шифрования данных RSA и
ГОСТ 28147-89. На этапе установления соединения сервер отсылает клиенту уникальный
идентификатор соединения (USI) длиной 14 байт, создание
которого необходимого для исключения атак, основанных на повторе ранее
передавшихся пакетов информации. Значение USI, должно быть использовано
только один раз из соображений стойкости к некоторым видам атак. Поэтому
рекомендуется брать его как некоторую функцию от времени установления
соединения. Структура USI представлена на рис. 1. 
Рис. 1. Формат уникального идентификатора
соединения Для передачи
ключей шифрования по алгоритму ГОСТ от клиента к серверу используется открытый
ключ RSA, длины от 508
до 1024 бит, позволяющий клиентам, у которых он хранится, шифровать данные для
сервера. В свою очередь, сервер с помощью своего закрытого ключа может
дешифровать эти данные. В данном
протоколе используются следующие обозначения для ключей RSA: – OSK (open/public server key) – открытый ключ сервера; – PSK (private server key) – закрытый ключ сервера. Для шифрования и
дешифрования информации по алгоритму RSA требуется
довольно длительное, по сравнению с другими алгоритмами, время, поэтому в
разрабатываемом протоколе для закрытия передаваемой информации используется
алгоритм ГОСТ 28147-89. Для его работы необходимы ключи размером 256 бит (8
частей по 32 бит), но допускается уменьшать длину ключа для ускорения операций
шифрования и дешифрования. Используются следующие ключи: – ключ шифрования данных Клиента (SKC),
размер 64 бита; – ключ шифрования данных Сервера (SKS),
размер 64 бита; – ключ вычисления
имитовставки и зашифрования синхропосылки (KI),
размер 64 бита. На этапе установления
соединения между абонентами клиент
инициирует логическое соединение с сервером, что обеспечивается протоколом
более низкого уровня. Далее сервер формирует пакет следующего
вида: 
Рис. 2. Формат 1 Нулевой байт – поле идентификатора пакета, далее расположены поля открытого ключа сервера и уникального идентификатора соединения. После получения
пакета формата 1 клиент формирует и направляет серверу ответ с ключевой
информацией: 
Рис. 3. Формат 2 Нулевой
байт – идентификатор пакета. Начиная с первого байта располагаются ключи: шифрования данных клиента
(SKC), шифрования данных сервера (SKS),
вычисления имитовставки и зашифрования синхропосылки (KI), полученный ранее клиентом USI. Второе поле имеет
переменную длину т.к. ключи зашифрованы алгоритмом RSA на открытом ключе сервера,
размер которого может принимать значения из диапазона 508...1024 бит. Подтверждение
получения сервером ключевой информации представляет собой единственный байт
(одно поле, являющееся идентификатором формата): 
Рис. 4.
Формат 3 Далее клиент должен передать пароль на доступ к ресурсам сервера.
Разумеется, пароль шифруется с помощью алгоритма ГОСТ и передается вместе с
зашифрованной синхропосылкой и имитовставкой: 
Рис. 5.
Формат 4 Ответ на правильный пароль, формат 5, аналогичен третьему, за исключением передаваемого идентификатора – значения F5h. 
Рис. 6.
Формат 5 Пакет с данными имеет формат, аналогичный формату 4. Единственное
отличие – поле идентификатора, в данном
случае это байт со значением F4h: 
Рис. 7.
Формат 6 Один из форматов – пакет с открытым ключом. Сервер имеет
возможность создавать новые ключи и
передавать их клиенту: 
Рис. 8.
Формат 7 Если клиент хочет получить новый ключ, то отправляет пакет формата 8,
который аналогичен третьему, но имеет значение поля идентификатора – FFh: 
Рис.
9. Формат 8 Безопасность
разработанного протокола полностью основана на ключах, а не на деталях алгоритма его работы. Это
значит, что протокол может быть опубликован и проанализирован. Продукты,
использующие этот протокол, могут широко тиражироваться. Без знания ключей
злоумышленнику не удастся раскрыть передаваемую информацию. ЛИТЕРАТУРА 1.
Шнайер
Б. Прикладная криптография. Протоколы, алгоритмы, исходные тексты на языке С. 2.
Ященко
В.В. Введение в криптографию. 3.
Домашев
А.Ю., Грунтович М.М. Программирование алгоритмов защиты информации. Учебное
пособие. |