Russian Language English Language

13 Методы и средства информационной безопасности ВС

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

13.2 Методология построения систем безопасности для электронных платежных систем на основе субъектно-объектной модели безопасности

13.3 Аспекты практического применения методологии построения защищенных платежных систем

13.4 Стеганографическое сокрытие информации в текстовом файле при работе в вычислительных сетях

13.5 Обеспечение неотслеживаемости клиента в системах электронных платежей

13.6 Разработка протокола защищенной передачи данных для электронных платежных систем


Экспресс информация

Редколлегия журнала

Подписка на новости

Гостевая книга

Предоставление материалов

Письмо в редакцию

На начало


2003, Номер1, ( 3)



Place for sale
Рассматривается абстрактная модель электронной торговли, реализуемая посредством использования глобальной вычислительной сети

BC/NW 2003г., №1(3)/ 13.3

 

 

АСПЕКТЫ ПРАКТИЧЕСКОГО ПРИМЕНЕНИЯ МЕТОДОЛОГИИ ПОСТРОЕНИЯ ЗАЩИЩЕННЫХ ПЛАТЕЖНЫХ СИСТЕМ

 

 

Теренин А.А.

 

(г. Москва, Московский Энергетический Институт, Россия)

 

 

 

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

                                

Неформальное описание компонент (архитектуры) системы и неформальное задание правил политики безопасности.

Стандартный банковский офис состоит из следующих компонентов: кассы обслуживания населения Skas; банкомат Sbm; АРМ сотрудников банка Ssot; АРМ руководства банка Sruk.

Создается словесное описание политики безопасности.

Множество объектов можно разделить на два подмножества: клиентские данные (необходимые для работы с клиентами) и внутренние банковские данные (отчеты, регистрация операций и т.п.) данные о счетах физических лиц Opi; данные о счетах юридических лиц Ouj; идентификационные данные клиентов банка Oid; регистрационные данные Oreg.

Права доступа для банковской инфраструктуры весьма специфичные: Rread – чтение; Rwr+ – запись, добавление к остатку на счете; Rwr- – запись, вычитание из остатка на счете; Rreg – создание регистрационной записи об осуществленной операции, удаление записей из регистрационного журнала невозможно.

Изобразим схематично правила доступа субъектов системы к объектам в соответствии с оговоренной политикой безопасности.




Введем в модель субъект управления базами данных SDB. На практике это реализуется приложением СУБД. Все субъекты системы должны обращаться к этому новому субъекту за разрешением доступа определенного типа к некоторой базе данных. Sid – устройство чтения идентификационных объектов клиентов банка.




Потоки, принадлежащие разрешенному множеству потоков L:

;; ;; ;;

;;;;

;;

;.

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

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

Составление списков существующих средств и механизмов обеспечения информационной защиты, выполняющие требуемые функции. Например, цифровую электронную подпись можно реализовать по следующим стандартам: RSA; DSA; ГОСТ 34.10-2001; ElGamal; на основе эллиптических кривых.

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

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

Таблица 1. Набор механизмов реализации ЭЦП.

Компонент

УЗ

С

Т

Ц

RSA программно на С++

0,92

10

10

1

 

RSA аппаратно

0,94

80

3

5

 

DSA программно на pascal

0,90

12

15

2

 

ГОСТ аппаратно

0,99

100

10

7

 

ГОСТ программно на С++

0,96

15

25

3

 

ГОСТ программно на asm

0,97

25

20

2

 

Краткие обозначения:

УЗ – уровень защищенности; С – стоимость разработки и внедрения: Т – среднее время, затрачиваемое на транзакцию; Ц – удельная стоимость совершения одной операции; … - таблица может быть продолжена.

Таблица 2. Набор механизмов реализации хэш-функции.

Компонент

УЗ

С

Т

Ц

MD4 программно на С++

0,86

10

10

1

 

MD5 программно на С++

0,92

12

10

1

 

MD5 аппаратно

0,93

80

3

5

 

MD5 программно на pascal

0,91

12

15

2

 

SHA программно на С++

0,91

20

12

2

 

SHA аппаратно

0,96

90

4

4

 

ГОСТ аппаратно

0,95

100

10

7

 

ГОСТ программно на С++

0,82

15

25

3

 

ГОСТ программно на asm

0,90

25

20

2

 

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

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

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

Математически, условия для решения подобной задачи формулируются следующим образом:

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

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

Система должна удовлетворять следующим ограничениями.

Сдоп <= 30; Тдоп <= 22; Цдоп <=  4; Р -> max.

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

Таблица 3. Сводная таблица механизмов защиты.

Компонент

УЗ

С

Т

Ц

RSA программно на С++

0,92

10

10

1

 

DSA программно на pascal

0,90

12

15

2

 

MD4 программно на С++

0,86

10

10

1

 

MD5 программно на С++

0,92

12

10

1

 

MD5 программно на pascal

0,91

12

15

2

 

SHA программно на С++

0,91

20

12

2

 

Ограничения:

max

30

22

4

 

Выбранные варианты:

-         RSA программно на С++;

-         MD5 программно на С++.

Сэцп + Схэш <= Сдоп , 10+12 <= 30;

Tэцп + Tхэш <= Тдоп , 10+10 <= 22;

Цэцп + Цхэш <= Цдоп ,  1+ 1 <=  4;

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

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

-       Для ЭЦП – алгоритм RSA, реализованный программно на С++;

-     Для хэш-функции – стандарт MD5, реализованный программно на С++.


Литература

Теренин А.А. Разработка методологии построения защищенных платежных систем. Журнал «Вычислительные сети. Теория и практика» http://network-journal.mpei.ac.ru/