
- •7 Модели безопасности основных ос
- •7.1 Понятие доступа и мониторинг безопасности
- •7.2 Основные типы политики безопасности
- •7.3 Реализация политики безопасности
- •7.3.1 Условия гарантированного легального доступа
- •7.4 Построение изолированной программной среды
- •7.5 Методика проектирования защищаемого фрагмента компьютерной системы
- •7.6 Контроль целостности объекта
- •7.6.1 Метод «безопасной загрузки» («ступенчатого контроля»)
- •7.7 Процесс установки ипс
- •7.8 Работа в ипс
- •7.9 Домены безопасности
- •9 Алгоритмы аутентификации пользователей
- •9.1 Типовые схемы идентификации и аутентификации пользователя
- •9.2 Взаимная проверка подлинности пользователей
- •9.3 Применение пароля для аутентификации
- •9.4 Биометрическая идентификация и аутентификация
- •10 Многоуровневая защита корпоративных сетей
- •10.1 Реализации многоуровневой комплексной защиты
- •10.1.1 Многоуровневая защита от ошибок
- •10.1.2 Многоуровневая защита от закладок
- •10.1.3 Многоуровневая защита от нсд
- •10.2 Корпоративные сети с многоуровневой коммутацией
- •10.2.1 Безопасность в многоуровневой модели
- •10.3 Защита информации в базах данных
- •4) Случайный выбор записи для обработки: такая организация выбора записей не позволяет проследить множество запросов.
- •10.4 Назначение экранирующих систем и требования к ним
- •10.5 Ограничение доступа в www серверах
- •11 Защита информации в сетях
- •11.1 Потенциальные угрозы безопасности информации в лвс
- •11.2 Система защиты информации от нсд в лвс
- •11.2.1 Защита от преднамеренного нсд
- •1 При этом защита данных файл-сервера осуществляется одним способом или в различных сочетаниях четырьмя способами:
- •3 Опознание пользователя и разграничение доступа в лвс можно также организовать с помощью шифровального устройства.
- •4 В менее ответственных лвс для защиты от модификации информации при её передаче по телефонным каналам используется система «обратный вызов».
- •5 Для защиты данных, передающихся по кабелю, существует несколько способов.
- •11.2.2 Средства управления защитой информации в лвс
- •11.2.3 Защита информации лвс от случайных нсд
- •11.2.4 Архивирование данных
- •11.2.5 Схема системы защиты информации в лвс
- •11.3 Оценка уровня безопасности информации от преднамеренного нсд в лвс
9 Алгоритмы аутентификации пользователей
Одна из функций подсистемы защиты – ИДЕНТИФИКАЦИЯ пользователя (сообщение системе имени). Если процедура идентификации закончилась успешно, то пользователь является законным, так как он имеет некоторый признак (идентификатор), зарегистрированный в системе.
Следующий шаг – это ПРОВЕРКА ПОДЛИННОСТИ ПОЛЬЗОВАТЕЛЯ, то есть его АУТЕНТИФИКАЦИЯ: устанавливается, является ли данный пользователь тем, кем он себя объявляет.
Если аутентификация прошла успешно, и подтверждена подлинность пользователя, можно установить доступные ему ресурсы – это предоставление полномочий (АВТОРИЗАЦИЯ).
ПРИ ПЕРЕДАЧЕ ДАННЫХ, после того как соединение установлено, необходимо обеспечить требования:
а) получатель д. б. уверен в подлинности источника данных;
б) получатель д. б. уверен в подлинности передаваемых данных;
в) отправитель д. б. уверен в доставке данных получателю;
д) отправитель д. б. уверен в подлинности доставленных данных.
Для требований (а) и (б) средство защиты – ЦИФРОВАЯ ПОДПИСЬ; для требований (в) и (д) – отправитель должен получить уведомление о вручении с помощью УДОСТОВЕРЯЮЩЕЙ ПОЧТЫ (certified mail).
Средства защиты в такой процедуре – ЦИФРОВАЯ ПОДПИСЬ ОТВЕТНОГО СООБЩЕНИЯ.
АУТЕНТИФИКАЦИЯ ОТПРАВИТЕЛЯ обеспечивается цифровой подписью [5].
Подпись сообщения в асимметричной криптосистеме выполняется путем ШИФРОВАНИЯ на секретном ключе отправителя.
ПЕРЕДАВАЕМОЕ СООБЩЕНИЕ состоит из содержательной информации отправителя (в открытом виде) с добавленной к ней (конкатенации) цифровой подписью.
ПОЛУЧАТЕЛЬ, зная открытый ключ отправителя, может выполнить Дешифрование и тем самым осуществить Аутентификацию Источника по результату СРАВНЕНИЯ ПРИНЯТОЙ И ВЫЧИСЛЕННОЙ ПОЛУЧАТЕЛЕМЦИФРОВОЙ ПОДПИСИ.
Не зная секретного ключа отправителя, НЕВОЗМОЖНО СОЗДАТЬ ЛОЖНОЕ сообщение С ЗАДАННОЙ ЦИФРОВОЙ ПОДПИСЬЮ.
Использование хэш-функции в технологии цифровой подписи позволяет избежать удвоения размера передаваемого сообщения, когда размер цифровой подписи будет равен размеру исходного сообщения (в символах сообщения).
Таким образом, процедура ВЫЧИСЛЕНИЯ ПОДПИСИ сводится к последовательному ВЫЧИСЛЕНИЮ ЗНАЧЕНИЯ ХЭШ-ФУНКЦИИ ОТ ИСХОДНОГО СООБЩЕНИЯ и шифрованию полученного значения на секретном ключе отправителя (или дешифрованию на открытом ключе при проверке подписи).
Если отправитель и получатель знают один и тот же СЕАНСОВЫЙ КЛЮЧ, АУТЕНТИЧНОСТЬ СООБЩЕНИЙ можно обеспечить, вычислив значение хэш-функции от объединения (конкатенации) передаваемого сообщения и сеансового ключа.
Результат этого вычисления называется КОДОМ АУТЕНТИФИКАЦИИ СООБЩЕНИЯ (КАС) (message authentication code,MAC).
Имитовставка ГОСТ 28147–89 – классический пример кода МАС.
КАС нужен для защиты от навязывания ложных сообщений. Для защиты от подделки КАС не передается в открытом виде, а объединяется с открытым текстом (конкатенация).
Полученный в результате объединения блок шифруется затем на сеансовом ключе.
В асимметричной криптосистеме никто, кроме отправителя, не знает секретного ключа. Это позволяет ОДНОЗНАЧНО ДОКАЗЫВАТЬ ПРИНАДЛЕЖНОСТЬ при отказе отправителя (получателя) от ранее переданного (принятого) сообщения.
Также, ПОЛУЧАТЕЛЬ, не зная секретного ключа, НЕ МОЖЕТ ПОДПИСАТЬ СООБЩЕНИЕ от лица отправителя.
СХЕМА ЭЛЕКТРОННОЙ ПОДПИСИ СООБЩЕНИЯ m:
1 Отправитель А вычисляет пару: kA secret СЕКРЕТНЫЙ ключ подписывающего (абонента А) и kA public – соответствующий ОТКРЫТЫЙ ключ проверяющего (абонента В). Отправитель А посылает kA public получателю В, сохраняя kA secret в секрете.
2 Для получения подписи документа m отправитель А ВЫЧИСЛЯЕТ ПОДПИСЬ s с помощью алгоритма формирования подписи S от сообщения m на секретном ключе kA secret и посылает сообщение mи подпись s получателю В.
3 Получатель В вычисляет у себя подпись с помощью алгоритма V проверки (верификации) подписи от сообщения m, подписи s на открытом ключе kA public. В зависимости от результата вычисления, принимает или отвергает подпись s.
Классическая СХЕМА СОЗДАНИЯ И ПРОВЕРКИ ЭЛЕКТРОННОЙ ПОДПИСИ показана на рисунке 9.1.
В российском стандарте цифровой подписи используется разработанная отечественными криптографами ХЭШ-ФУНКЦИЯ (256 бит) стандарта ГОСТ Р 34.11–94 (в основе алгоритм блочного шифрования по ГОСТ 28147–89).
Стандарт определяет алгоритм и ПРОЦЕДУРУ ВЫЧИСЛЕНИЯ ХЭШ-ФУНКЦИИ ДЛЯ ЛЮБОЙ ПОСЛЕДОВАТЕЛЬНОСТИ двоичных символов, которые применяются в криптографических методах обработки и защиты информации, в том числе для реализации процедур электронной подписи (ЭЦП) при передаче, обработке и хранении информации в автоматизированных системах.
Определённая в стандарте функция хэширования используется при реализации систем электронной цифровой подписи на базе ассиметричного криптографического алгоритма по ГОСТ Р 34.10–94 «Информационная технология. Криптографическая защита информации. Процедуры выработки и проверки электронной цифровой подписи на базе ассиметричного криптографического алгоритма».
В общем, хэш-функция h отображает двоичные строки произвольной конечной длины в выходы небольшой (например, 64, 128, 160,192, 224, 256, 384, 512) фиксированной длины [13], называемые хэш-величинами:
где
{01}* – множество
двоичных строк произвольной конечной
длины; {01}n
– множество
двоичных строк длиной n
бит,
то есть {01}* –
это объединение
всех множеств
двоичных последовательностей длинойi бит,
принадлежащих системе N
(в ГОСТ Р
34.11-94, n = 256).
Сообщения с произвольной длиной можно сжать, используя хэш-функцию с фиксированным размером входа, при помощи двух методов:
– последовательного (итерационного);
– параллельного.
В
ГОСТ Р 34.11–94
использовали
первый путь –
метод
последовательного хэширования,
использующий
хэш-функцию с фиксированным размером
входа
(см. рисунок
9.2), то
есть функцию сжатия с коэффициентом 2.
Если необходимо хэшировать сообщение m = (m1, m2, …, mi), то хэширование выполняется следующим образом:
Здесь Hi – функция сжатия, а hi – переменная сцепления.
Если последний блок меньше, чем n бит, то он набивается одним из существующих методов до достижения длины, кратной n.
В отличие от стандартных предпосылок, что сообщение разбито на блоки и произведена набивка последнего блока, если необходимо (форматирование входа априори), до начала хэширования, то в ГОСТ Р 34.11–94 процедура хэширования ожидает конца сообщения (форматирование входного сообщения постериори).
Набивка производится следующим образом: последний блок сдвигается вправо, а затем набивается нулями до достижения длины в 256 бит.
Алгоритм хэширования по ГОСТ Р 34.11–94 можно классифицировать как устойчивый к коллизиям код (при n = 256, и один из видов атак потребует приблизительно 2256/2 операций хэширования), выявляющий модификации (Collision Resistant Hash Function, CRHF).
Также конструкторы предусмотрели ДОПОЛНИТЕЛЬНЫЕ МЕРЫ ЗАЩИТЫ:
а)
параллельно
рассчитываются контрольная сумма,
представляющая собой сумму всех блоков
сообщения
(последний
суммируется уже набитым) по
правилу A +
B [mod 2k],
где k
= |A| = |B|, а
|A| и
|B| битовые
длины слов A
и B
соответственно
(далее на рисунках и в тексте эта
операция будет обозначаться
);
б) параллельно рассчитываются битовая длина хэшируемого сообщения, приводимая по mod 2256 (MD-усиление), которые в финальной функции сжатия используются для вычисления итогового хэша (см. рисунок 9.3).
Указывать в передаваемом сообщении, сколько было добавлено нулей к последнему блоку, не требуется, так как длина сообщения участвует в хэшировании (см. рисунок 9.4).
Начальный вектор IV: согласно ГОСТ Р 34.11–94, IV – произвольное фиксированное слово длиной 256 бит (IV ϵ{01}256).
Если он априорно не известен верифицирующему целостность сообщения, то он должен передаваться вместе с сообщением с гарантией целостности.
При небольших сообщениях можно выбирать IV из небольшого множества допустимых величин. Также он может задаваться в рамках организации, домена, как константа.
Каждый входной блок рассматривается как результат конкатенации четырёх 64-разрядных двоичных наборов.
Функция сжатия Hi выполняется в ТРИ шага:
1) генерация четырёх 256-разрядных ключей для зашифрования в режиме простой замены 64-разрядных частей i-го блока;
2) зашифрование частей блока hi c использованием алгоритма ГОСТ 28147–89;
3) перемешивание результатов зашифрования