- •1. Понятие информационной безопасности
- •2. Важность и сложность проблемы информационной безопасности
- •3. Основные составляющие информационной безопасности
- •4. Категории информационной безопасности
- •5. Требования к политике безопасности в рамках iso
- •6. Общие сведения о стандартах серии iso 27000
- •Разработчики международных стандартов
- •Русские переводы международных стандартов
- •7. Iso 15408 - Общие критерии оценки безопасности информационных технологий
- •8. Iso 18028 - Международные стандарты сетевой безопасности серии
- •Iso/iec 18028-1:2006 Информационные технологии. Методы обеспечения безопасности. Сетевая ит безопасность. Управление сетевой безопасностью.
- •Iso/iec 18028-5:2006 Информационные технологии. Методы обеспечения безопасности. Защита сетевых взаимодействий при помощи Виртуальных Частных Сетей
- •9. Российские стандарты гост
- •10. Модель сетевого взаимодействия
- •11. Модель безопасности информационной системы
- •12. Классификация криптоалгоритмов
- •13. Алгоритмы симметричного шифрования
- •14. Криптоанализ
- •Дифференциальный и линейный криптоанализ
- •15. Используемые критерии при разработке алгоритмов
- •16. Сеть Фейштеля
- •17. Алгоритм des Принципы разработки
- •Проблемы des
- •18. Алгоритм idea
- •Принципы разработки
- •Криптографическая стойкость
- •21. Создание случайных чисел
- •22. Требования к случайным числам
- •Случайность
- •Непредсказуемость
- •Источники случайных чисел
- •Генераторы псевдослучайных чисел
- •Криптографически созданные случайные числа
- •Циклическое шифрование
- •Режим Output Feedback des
- •Генератор псевдослучайных чисел ansi x9.17
- •23. Разработка Advanced Encryption Standard (aes) Обзор процесса разработки aes
- •Обзор финалистов
- •Критерий оценки
- •Запасной алгоритм
- •Общая безопасность
- •25. Основные способы использования алгоритмов с открытым ключом
- •Алгоритм rsa
- •27. Алгоритм обмена ключа Диффи-Хеллмана
- •28. Транспортное кодирование
- •29. Архивация
- •Требования к хэш-функциям
- •31. Цифровая подпись Требования к цифровой подписи
- •Прямая и арбитражная цифровые подписи
- •32. Симметричное шифрование, арбитр видит сообщение:
- •33. Симметричное шифрование, арбитр не видит сообщение:
- •34. Шифрование открытым ключом, арбитр не видит сообщение:
- •35. Стандарт цифровой подписи dss
- •Подход dss
- •36. Отечественный стандарт цифровой подписи гост 3410
- •37. Алгоритмы распределения ключей с использованием третьей доверенной стороны Понятие мастер-ключа
- •38. Протоколы аутентификации
- •Взаимная аутентификация
- •39. Элементы проектирования защиты сетевого периметра.
- •40. Брандмауэр и маршрутизатор.
- •41. Брандмауэр и виртуальная частная сеть.
- •42. Многоуровневые брандмауэры.
- •43. Прокси-брандмауэры.
- •44.Типы прокси.
- •46.Недостатки прокси-брандмауэров.
- •48. Виртуальные локальные сети.
- •49. Границы виртуальных локальных сетей.
- •50. Частные виртуальные локальные сети.
- •51. Виртуальные частные сети.
- •52. Основы построения виртуальной частной сети.
- •53. Основы методологии виртуальных частных сетей.
- •54. Туннелирование.
- •55. Защита хоста.
- •56. Компьютерные вирусы
- •Структура и классификация компьютерных вирусов
- •2.3.3. Механизмы вирусной атаки
- •58. Протокол ррр рар
- •59. Протокол ррр chap
- •60. Протокол ррр еар
- •68. Виртуального удаленного доступа
- •69. Сервис Директории и Служб Имен
- •70. По и информационная безопасность
- •71. Комплексная система безопасности. Классификация информационных объектов
38. Протоколы аутентификации
Рассмотрим основные протоколы, обеспечивающие как взаимную аутентификацию участников, так и аутентификацию только одного из участников.
Взаимная аутентификация
Данные протоколы применяются для взаимной аутентификации участников и для обмена ключом сессии.
Основной задачей таких протоколов является обеспечение конфиденциального распределения ключа сессии и гарантирование его своевременности, то есть протокол не должен допускать повторного использования старого ключа сессии. Для обеспечения конфиденциальности ключи сессии должны передаваться в зашифрованном виде. Вторая задача, обеспечение своевременности, важна, потому что существует угроза перехвата передаваемого сообщения и повторной его пересылки. Такие повторения в худшем случае могут позволять взломщику использовать скомпрометированный ключ сессии, при этом успешно подделываясь под другого участника. Успешное повторение может, как минимум, разорвать операцию аутентификации участников.
Такие повторы называются replay-атаками. Рассмотрим возможные примеры подобных replay-атак:
Простое повторение: противник просто копирует сообщение и повторяет его позднее.
Повторение, которое не может быть определено: противник уничтожает исходное сообщение и посылает скопированное ранее сообщение.
Один из возможных подходов для предотвращения replay-атак мог бы состоять в присоединении последовательного номера (sequence number) к каждому сообщению, используемому в аутентификационном обмене. Новое сообщение принимается только тогда, когда его последовательный номер правильный. Трудность данного подхода состоит в том, что каждому участнику требуется поддерживать значения sequence number для каждого участника, с которым он взаимодействует в данный момент. Поэтому обычно sequence number не используются для аутентификации и обмена ключами. Вместо этого применяется один из следующих способов:
Отметки времени: участник А принимает сообщение как не устаревшее только в том случае, если оно содержит отметку времени, которая, по мнению А, соответствует текущему времени. Этот подход требует, чтобы часы всех участников были синхронизированы.
Запрос/ответ: участник А посылает в запросе к В случайное число (nonce - number only once) и проверяет, чтобы ответ от В содержал корректное значение этого nonce.
Считается, что подход с отметкой времени не следует использовать в приложениях, ориентированных на соединение, потому что это технически трудно, так как таким протоколам, кроме поддержки соединения, необходимо будет поддерживать синхронизацию часов различных процессоров. При этом возможный способ осуществления успешной атаки может возникнуть, если временно будет отсутствовать синхронизация часов одного из участников. В результате различной и непредсказуемой природы сетевых задержек распределенные часы не могут поддерживать точную синхронизацию. Следовательно, процедуры, основанные на любых отметках времени, должны допускать окно времени, достаточно большое для приспособления к сетевым задержкам, и достаточно маленькое для минимизации возможности атак.
С другой стороны, подход запрос/ответ не годится для приложений, не устанавливающих соединения, так как он требует предварительного рукопожатия перед началом передач, тем самым отвергая основное свойство транзакции без установления соединения. Для таких приложений доверие к некоторому безопасному серверу часов и постоянные попытки каждой из частей синхронизировать свои часы с этим сервером может быть оптимальным подходом.