Автор: Столлингс В.
Теги: компьютерные технологии компьютерные науки компьютер компьютерные сети
ISBN: 5-8459-0298-3
Год: 2002
Текст
ОСНОВЫ ЗАЩИТЫ СЕТЕЙ
ПРИЛОЖЕНИЙ И СТАНДАРТЫ
ВИЛЬЯМ СТОЛЛИНГС
ОСНОВЫ ЗАЩИТЫ
СЕТЕЙ
Приложения и стандарты
NETWORK SECURITY
ESSENTIALS
Applications and standards
WILLIAM STALLINGS, PH.D.
Prentice
Hall
Prentice HALL
Upper Saddle River, New Jersey 07458
left—
нт
ОСНОВЫ ЗАЩИТЫ
СЕТЕЙ
Приложения и стандарты
ВИЛЬЯМ СТОЛЛИНГС
Москва • Санкт-Петербург • Киев
2002
ББК 32.973.26-018.2.75
С81
УДК 681.3.07
Издательский дом “Вильямс”
Зав. редакцией А.В. Слепцов
Перевод с английского и редакция А.Г. Сивака
По общим вопросам обращайтесь в Издательский дом “Вильямс” по адресу:
info@williamspublishing.com, http://www.williamspublishing.com
Столлингс, Вильям
С81 Основы защиты сетей. Приложения и стандарты : Пер. с англ. — М. :
Издательский дом “Вильямс”, 2002. — 432 с. : ил. — Парал. тит. англ.
ISBN 5-8459-0298-3 (рус.)
Наше время — это время широкого распространения компьютерных вирусов,
электронного шпионажа, хакерства и других угроз, связанных с глобализацией
Internet и повсеместным распространением компьютеров. Поэтому вопросы защиты
компьютеров и компьютерных сетей приобрели сейчас особую актуальность. Эта кни-
га представляет собой краткий и одновременно исчерпывающий справочник по со-
временным средствам и инструментам защиты в Internet, а также приложениям, не-
обходимым в любых системах передачи данных и компьютерных сетях.
Книга будет полезна как специалистам в области защиты компьютеров и компью-
терных сетей, так и студентам, изучающим соответствующие курсы в высших учеб-
ных заведениях.
ББК 32.973.26-018.2.75
Все названия программных продуктов являются зарегистрированными торговыми марками со-
ответствующих фирм.
Никакая часть настоящего издания ни в каких целях не может быть воспроизведена в какой
бы то ни было форме и какими бы то ни было средствами, будь то электронные или механические,
включая фотокопирование и запись на магнитный носитель, если на это нет письменного разреше-
ния издательства Prentice Hall, Inc.
Authorized translation from the English language edition published by Prentice Hall Europe,
Copyright © 2000
All rights reserved. No part of this book may be reproduced or transmitted in any form or by any
means, electronic or mechanical, including photocopying, recording or by any information storage re-
trieval system, without permission from the Publisher.
Russian language edition published by Williams Publishing House according to the Agreement with
R&I Enterprises International, Copyright © 2002
ISBN 5-8459-0298-3 (pyc.)
ISBN 0-1301-6093-8 (англ.)
© Издательский дом “Вильямс”, 2002
© Prentice Hall, Inc., 2000
Оглавление
Предисловие 13
Глава 1. Введение 17
Часть I. Криптография 39
Глава 2. Традиционное шифрование и конфиденциальность 41
Глава 3. Криптография с открытым ключом и аутентификация сообщений 71
Часть II. Приложения сетевой защиты 111
Глава 4. Приложения аутентификации 113
Глава 5. Защита электронной почты 151
Глава 6. Защита IP 203
Глава 7. Защита Web 253
Глава 8. Защита сетевого управления 293
Часть III. Защита систем 335
Глава 9. Нарушители и вирусы 337
Глава 10. Брандмауэры 385
Приложение 1. Список документов RFC, на которые ссылается книга 405
Приложение 2. Проекты для курса по защите сетей 407
Словарь терминов 411
Список сокращений 417
Список литературы 419
Предметный указатель 425
Содержание
Предисловие 13
Глава 1. Введение 17
1.1. Нарушения, механизмы и службы защиты 20
Службы защиты 21
Механизмы защиты 22
Нарушения 22
1.2. Нарушения защиты 24
Пассивные нарушения 26
Активные нарушения 26
1.3. Службы защиты 27
Конфиденциальность 27
Аутентификация 28
Целостность 28
Невозможность обмана 29
Управление доступом 29
Доступность ресурсов 29
1.4. Модель защиты сети 29
1.5. Стандарты Internet и документы RFC 32
Internet Society 32
Публикация документов RFC 33
Процесс стандартизации 33
Документы вне процесса стандартизации 34
1.6. Рекомендуемые источники дополнительной информации 35
Дополнение 1.1. Ресурсы Internet и Web 35
Web-узлы данной книги 35
Другие Web-узлы 36
Группы новостей USENET 36
Часть I. Криптография 39
Глава 2. Традиционное шифрование и конфиденциальность 41
2.1. Принципы традиционного шифрования 42
Криптография 43
Криптоанализ 44
2.2. Алгоритмы традиционного шифрования 49
Стандарт шифрования данных (DES) 49
“Тройной” DEA 54
Усовершенствованный стандарт шифрования (AES) 56
Другие симметричные блочные шифры 56
2.3. Режимы блочного шифрования 59
Режим сцепления шифрованных блоков 60
Режим шифрованной обратной связи 62
2.4. Размещение средств шифрования 63
2.5. Распределение ключей 65
2.6. Рекомендуемые источники дополнительной информации 67
2.7. Задачи 68
Глава 3. Криптография с открытым ключом и аутентификация сообщений 71
3.1. Методы аутентификации сообщений 72
Аутентификация сообщений с помощью шифрования 72
Аутентификация сообщений без шифрования 73
Код аутентичности сообщения 73
Односторонняя функция хэширования 74
3.2. Защищенные функции хэширования и НМАС 77
Необходимые свойства функции хэширования 77
Простые функции хэширования 78
Защищенная функция хэширования SHA-1 80
Другие защищенные функции хэширования 83
НМАС 85
3.3. Принципы криптографии с открытым ключом 88
Схема шифрования с открытым ключом 88
Применение криптосистем с открытым ключом 90
Условия применения методов криптографии с открытым ключом 91
3.4. Алгоритмы криптографии с открытым ключом 92
Алгоритм RSA 92
Обмен ключами по схеме Диффи-Хеллмана 95
Другие алгоритмы криптографии с открытым ключом 98
3.5. Цифровые подписи 99
3.6. Управление ключами 100
Цифровые сертификаты 100
Распределение секретных ключей по схеме с открытым ключом 102
3.7. Рекомендуемые источники дополнительной информации 103
3.8. Задачи 103
Допо лнение 3.1. Простые числа и арифметика в классах вычетов 106
Простые и взаимно простые числа 106
Арифметика в классах вычетов 108
Часть II. Приложения сетевой защиты 111
Глава 4. Приложения аутентификации 113
4.1. Система Kerberos 114
Цели разработки 115
Kerberos версии 4 116
Kerberos версии 5 128
4.2. Служба аутентификации Х.509 135
Сертификаты 135
Процедуры аутентификации 140
Версия 3 стандарта Х.509 142
4.3. Рекомендуемые источники дополнительной информации 145
Рекомендуемые Web-узлы 145
4.4. Задачи 146
Дополнение 4.1. Методы шифрования Kerberos 147
Содержание 7
Преобразование паролей в ключи 147
Режим распространения сцепления шифрованных блоков 148
Глава 5. Защита электронной почты 151
5.1. PGP 152
Обозначения 153
Описание работы системы 153
Криптографические ключи и связки ключей 159
Управление открытыми ключами 166
5.2. S/MIME 173
RFC 822 173
Многоцелевые расширения электронной почты 174
Функциональные возможности S/MIME 182
Сообщения S/MIME 185
Обработка сертификатов в S/MIME 189
Сервис усовершенствованной защиты 193
5.3. Рекомендуемые источники дополнительной информации 193
5.4. Задачи 194
Дополнение 5.1. Сжатие данных с помощью ZIP 194
Алгоритм сжатия 196
Алгоритм декомпрессии 197
Дополнение 5.2. Преобразование в 64-символьный формат 197
Дополнение 5.3. Генерирование случайных чисел PGP 200
Истинно случайные числа 200
Псевдослучайные числа 200
Глава 6. Защита IP 203
6.1. Обзор возможностей защиты на уровне IP 204
Области применения IPSec 205
Преимущества IPSec 206
Приложения маршрутизации 207
6.2. Архитектура защиты на уровне IP 207
Документы IPSec 207
СервисIPSec 208
Защищенные связи 210
Транспортный и туннельный режимы 213
6.3. Заголовок аутентификации 214
Сервис защиты от воспроизведения 215
Код контроля целостности 216
Транспортный и туннельный режимы 217
6.4. Защищенный полезный груз 219
Формат ESP 220
Шифрование и алгоритмы аутентификации 220
Использование заполнителя 221
Транспортный и туннельный режимы 221
6.5. Комбинации защищенных связей 225
Аутентификация плюс конфиденциальность 226
Основные.типы комбинаций защищенных связей 227
6.6. Управление ключами 229
8
Содержание
Протокол Oakley
Протокол ISAKMP
6.7. Рекомендуемые источники дополнительной информации
Рекомендуемые Web-узлы
6.8. Задачи
Дополнение 6.1. Протоколы межсетевого взаимодействия
Роль протокола межсетевого взаимодействия
IPv4
IPv6
Глава 7. Защита Web
7.1. Проблемы защиты Web
Угрозы нарушения защиты Web
Способы защиты потока данных в Web
7.2. Протоколы SSL и TLS
Архитектура SSL
Протокол записи SSL
Протокол изменения параметров шифрования
Протокол извещения
Протокол квитирования
Криптографические вычисления
Защита транспортного уровня
7.3. Протокол защищенных электронных транзакций (SET)
Общие сведения о SET
Дуальная подпись
Обработка платежей
7.4. Рекомендуемые источники дополнительной информации
Рекомендуемые Web-узлы
7.5. Задачи
Глава 8. Защита сетевого управления
8.1. Основные принципы работы SNMP
Архитектура сетевого управления
Архитектура протокола сетевого управления
Модули-посредники
SNMPv2
8.2. Объединения SNMPVI
Объединения и имена объединений
Сервис аутентификации
Политика доступа
Сервис посредничества
8.3. SNMPv3
Архитектура SNMP
Модель обработки сообщений и защиты пользователя
Управление доступом на основе представлений
8.4. Рекомендуемые источники дополнительной информации
Рекомендуемые Web-узлы
8.5. Задачи
Содержание
Часть III. Защита систем 335
Глава 9. Нарушители и вирусы 337
9.1. Нарушители 338
Методика вторжения 340
Защита паролей 342
Стратегии выбора пароля 348
Обнаружение нарушений 353
9.2. Вирусы и угрозы, связанные с вирусами 366
Вредоносные программы 367
Природа вирусов 371
Типы вирусов 374
Макровирусы 375
Антивирусная защита 376
Перспективные методы антивирусной защиты 378
9.3. Рекомендуемые источники дополнительной информации 381
Рекомендуемые Web-узлы 381
9.4. Задачи 382
Глава 10. Брандмауэры 385
10.1. Принципы работы брандмауэров 386
Характеристики брандмауэров 387
Типы брандмауэров 389
Конфигурации брандмауэров 395
10.2. Высоконадежные системы 397
Управление доступом к данным 397
Принципы использования высоконадежных систем 400
Защита от “троянских коней” 402
10.3. Рекомендуемые источники дополнительной информации 403
10.4. Задачи 404
Приложение 1. Список документов RFC, на которые ссылается книга 405
Приложение 2. Проекты для курса по защите сетей 407
2.1. Исследовательские проекты 408
2.2. Проекты по программированию 408
2.3. Задания по изучению/реферированию литературы 409
Словарь терминов 411
Список сокращений 417
Список литературы 419
Предметный указатель 425
10
Содержание
Моей любимой жене А.Т.С.
и ее постоянным компаньонам
Жоффрею и Кейт Лан Кинетик
This page intentionally left blank
Предисловие
Сейчас, когда повсюду используются электронные
средства связи, в эпоху вирусов и хакеров, электронной
разведки и мошенничества, вопросы безопасности, без со-
мнения, не могут оставаться чем-то второстепенным. Акту-
альность темы этой книги определяется двумя ясно обозна-
ченными моментами. Во-первых, вследствие лавинообраз-
ного распространения компьютерных систем и их
взаимодействия посредством сетей возникает все большая
зависимость как организаций, так и отдельных людей от
информации, хранящейся в связанных сетями системах.
Это, в свою очередь, заставляет осознать необходимость за-
щиты данных и ресурсов, использования специальных
средств проверки аутентичности получаемых данных и со-
общений, а также защиты систем от несанкционированного
доступа и сетевых атак. Во-вторых, вполне сформирована
теоретическая основа разработки реальных приложений се-
тевой защиты — криптография и теория защиты сетей.
КНИГИ
Книга ставит своей целью предложить систематизи-
рованный обзор существующих приложений и стандартов
в области защиты сетей. Особое внимание в книге уделя-
ется приложениям, широко используемым в Internet и
корпоративных сетях, а также стандартам (в особенно-
сти стандартам Internet), которые уже получили все-
общее признание.
АДРЕСОВАНА
Книга предназначена как для академической ауди-
тории, так и для профессионалов-практиков. Как учеб-
ник эта книга может выступать в качестве основы курса
по защите сетей для студентов, изучающих информати-
ку, вычислительную технику или электротехнику. Кни-
га также может служить базовым справочным пособием
и подходит для самостоятельного изучения предмета.
Структура книги
Книга состоит из трех частей.
I. Криптография. Краткий обзор алгоритмов шифрования и протоколов, ле-
жащих в основе приложений, обеспечивающих сетевую защиту. Здесь рас-
смотрены, в частности, средства шифрования, вычисления хэш-кодов и
цифровых подписей, а также алгоритмы обмена ключами.
II. Приложения сетевой защиты. Описание важнейших средств защиты сетей и
соответствующих приложений, включая Kerberos, сертификаты X.509v3,
PGP, S/MIME, IP Security, SSL/TLS, SET и SNMPv3.
III. Защита систем. Обсуждение вопросов защиты системного уровня, включая
защиту сети от нарушителей и вирусов, а также вопросов использования
брандмауэров и высоконадежных систем (т.е. систем, заслуживающих дове-
рия с точки зрения защиты данных).
Более подробное описание структуры содержимого книги по главам вы най-
дете в конце главы 1. Кроме того, в книге имеется достаточно обширный словарь
терминов, списки используемых аббревиатур и литературы. В конце глав чита-
телю предлагаются упражнения и задачи для самостоятельного решения, а так-
же ссылки на другие источники информации, в которых можно найти более
подробные сведения по вопросам, рассматриваемым в книге.
inteknet-поддержка
ДЛЯ ПРЕПОДАВАТЕЛЕЙ И СТУДЕНТОВ
J ' - . -. _ - .-а*-.-. ’ '' ' ' Д. " . -г-
В Internet имеется соответствующая этой книге Web-страница, созданная в по-
мощь преподавателям и студентам. На ней вы найдете полезные ссылки, оригиналы
рисунков книги в формате PDF (Adobe Acrobat) и информацию о том, как добавить
свой адрес в соответствующий книге список рассылки Internet. Web-страница, о ко-
торой идет речь, размещена по адресу http://www.shore.net/~ws/NetSec.hlml.
Список рассылки был создан для того, чтобы использующие книгу преподаватели
могли обмениваться информацией и пожеланиями, а также задавать друг другу и
автору книги вопросы по освещаемой в книге теме. Если в книге обнаружатся опе-
чатки или ошибки, список соответствующих исправлений будет размещен по адресу
http://www.shore.net/~ws.
ПРОЕКТЫ ПРАКТИЧЕСКПХРАБОТ
ПО ЗАЩИПЕ СЕТЕЙ
‘ • ...... -I ........ ... .: . .......... i.«— _ ...j. _ .- .. „ „дД
Многие преподаватели считают важным компонентом курсов по криптогра-
фии и защите сетей организацию практических занятий. Эта книга предлагает
совершенно оригинальную методику дополнения теоретических знаний практи-
ческими. Рекомендации преподавателям содержат не только инструкции по раз-
работке планов и организации таких занятий, но и вполне готовые проекты за-
даний, темы которых охватывают широкий диапазон освещенных в книге во-
просов. Среди предлагаемых проектов имеются следующие.
14
Предисловие
Исследовательские проекты. Задания для учащихся с предложениями про-
вести исследование по конкретным вопросам в Internet и подготовить соответст-
вующий обзор.
Проекты по программированию. Задания по программированию, практиче-
ски реализующие решения конкретных проблем. Для их выполнения можно ис-
пользовать любой подходящий язык программирования в рамках любой аппа-
ратной платформы.
Задания по изучению/реферированию литературы. Списки опубликован-
ных статей, по каждой главе в отдельности, которые можно предложить уча-
щимся для реферирования.
Подробности вы найдете в приложении 2.
СВЯЗЬ С КНИГОЙ КРИПТОГРАФИЯ
И ЗАЩИТА СЕТЕЙ, 2-е издание
Эта книга создана на основе книги Криптография и защита сетей, 2-е из-
дание, уже переведенной на русский язык и выпущенной издательством
“Вильямс”. Книга Криптография и защита сетей, 2-е издание предлагает доста-
точно основательный обзор вопросов криптографии, включая подробные описа-
ния алгоритмов и лежащих в их основе математических идей, что в общей
сложности занимает более 300 страниц печатного текста. Книга Основы защиты
сетей: приложения и стандарты, напротив, предлагает краткий обзор этих во-
просов в главах 2 и 3. Но данная книга включает весь остальной материал книги
Криптография и защита сетей, 2-е издание с некоторыми дополнениями и ис-
правлениями, соответствующими изменениям, произошедшим со времени выхо-
да последней. В книгу, которую вы держите в руках, добавлено обсуждение во-
просов защиты SNMP, которые не рассматривались в книге Криптография и
защита сетей, 2-е издание. Книга Основы защиты сетей: приложения и стан-
дарты предназначена для преподавателей и слушателей соответствующих курсов
колледжей, а также профессионалов, чьи интересы лежат главным образом в
плоскости практического применения средств защиты сетей и не предполагают
необходимость или наличие желания глубоко изучать вопросы теории защиты
сетей и фундаментальные идеи криптографии.
Предисловие
15
This page intentionally left blank
ГЛАВА
Введение
1.1. Нарушения, механизмы и службы защиты
1.2. Нарушения защиты
1.3. Службы защиты
1.4. Модель защиты сети
1.5. Стандарты Internet и документы Rfc
1.6. Рекомендуемые источники дополнительной
информации
Дополнение 1.1. Ресурсы Internet и Web
За последние десятилетия смысл термина информационная безопасность суще-
ственно изменился. До широкого распространения оборудования, предназна-
ченного для автоматизированной обработки данных, защита информации, ко-
торую организация считала важной, обеспечивалась с помощью физических и адми-
нистративных мер. Физические меры включали, например, использование снабжен-
ного замком массивного сейфа, в котором хранились важные документы. Админист-
ративные меры сводились к проверке личных дел персонала при приеме на работу.
С появлением и распространением компьютеров и средств автоматизированной
обработки данных возникла потребность в автоматизированных средствах защиты
файлов и другой хранимой компьютерами информации. Особенно остро потребность
в средствах защиты ощущается в таких многопользовательских системах, как сис-
темы с разделением времени, а также в системах, к которым можно получить доступ
по обычным телефонным линиям связи или через открытые компьютерные сети.
Для обозначения совокупности методов защиты данных и средств противодействия
хакерам стал использоваться термин компьютерная безопасность.
Второе крупное изменение, повлиявшее на формирование нового подхода к
вопросу о безопасности, произошло в результате появления распределенных сис-
тем обработки данных, в которых сети и коммуникационное оборудование ис-
пользуются для обмена данными между пользовательскими терминалами и цен-
тральными компьютерами или между любыми компьютерами вообще. В этой
связи возникла необходимость защиты сетей, по которым передаются данные, а
вместе с ней появился и термин сетевая безопасность. При этом подразумевает-
ся не одна отдельно взятая локальная сеть, а некоторая совокупность сетей
предприятий, правительственных учреждений и учебных заведений, связанных
между собой в объединенную сеть обработки данных (internet1).
Между этими двумя формами безопасности — компьютерной и сетевой —
вряд ли можно провести четкую границу. Например, одним из широко извест-
ных типов вмешательства в работу информационной системы является компью-
терный вирус. Вирус может вноситься в систему как физически, например с
дискеты, с которой он считывается и попадает в компьютер, так и через объеди-
ненную сеть. Но как бы то ни было, после заражения компьютерной системы
вирусом для его идентификации и удаления приходится использовать локальные
средства компьютерной безопасности.
Данная книга посвящена вопросам защиты информации и безопасности ее пе-
редачи в объединенных сетях, методам выявления и предотвращения возможных
нарушений защиты, а также ликвидации негативных последствий таких нарушений.
Это самая общая формулировка, охватывающая множество самых разных аспектов.
Чтобы дать более точное представление о круге вопросов, поднимаемых в книге, рас-
смотрим следующие примеры нарушений защиты при передаче данных в сети.
1. Пользователь А передает файл пользователю Б. Файл содержит важную
информацию (например, платежную ведомость), которая должна быть за-
щищена от разглашения. Пользователь В, не обладающий правом чтения
1 Термин “internet” используется как имя нарицательное, когда речь идет о неко-
торой совокупности связанных друг с другом локальных сетей. Примером такой сово
купности может быть, например, внутренняя сеть предприятия. А привычная всем
сеть Internet оказывается одним из возможных средств, на основе которых организация
может строить свою сеть internet.
18
Глава 1
этого файла, может, осуществляя мониторинг передаваемых данных, полу-
чить копию этого файла в свое распоряжение.
2. Сетевой администратор Г передает сообщение компьютеру Д, находящемуся
под управлением этого администратора. Сообщение предписывает компью-
теру Д обновить файл с учетными записями и привилегиями пользователей,
имеющих право работать с этим компьютером. Пользователь Е перехваты-
вает сообщение, меняет его содержимое, а затем пересылает сообщение
компьютеру Д, который воспринимает модифицированный пользователем Е
файл как сообщение, исходящее от администратора Г. В результате таблица
прав доступа будет изменена в соответствии с интересами пользователя Е.
3. Вместо того чтобы перехватывать сообщение, пользователь Е составляет
собственное сообщение нужного ему содержания и передает его компьютеру
Д, имитируя отправку сообщения администратором Г. Компьютер Д прини-
мает сообщение как исходящее от администратора Г и обновляет файл с
таблицей прав доступа.
4. Служащий увольняется из-за дисциплинарного проступка. Менеджер по
персоналу отправляет сообщение серверу с требованием удалить учетную
запись уволенного служащего. После удаления сервер отправляет уведомле-
ние в личный файл служащего для подтверждения выполненной операции.
Служащий может перехватить это сообщение и задержать его на срок, дос-
таточный для того, чтобы в последний раз подключиться к серверу и полу-
чить важную информацию. После этого сообщение пересылается, операция
удаления завершается и менеджеру отправляется подтверждение. Такие
действия, выполненные служащим во время последнего сеанса работы, мо-
гут остаться незамеченными достаточно долго.
5. Клиент отправляет своему биржевому брокеру сообщение с указанием о
проведении ряда биржевых операций. После падения курсов акций, приоб-
ретенных для клиента брокером, клиент отказывается от того, что отправ-
лял такое сообщение.
Данный перечень далеко не является исчерпывающим, но он достаточно
ттрэшо иллюстрирует, насколько широк диапазон угроз безопасности при пере-
даче информации в сети.
Безопасность работы в объединенной сети — предмет настолько увлекатель-
ный. насколько и сложный. В подтверждение этому можно привести следующие
щгументы.
1. Гарантия безопасности коммуникаций и обмена информацией в сети — дело не
такое простое, как может показаться на первый взгляд. Основные требования к
обеспечению безопасности передачи информации вытекают из обычных сообра-
жений здравого смысла и могут быть представлены четырьмя говорящими сами
за себя терминами: конфиденциальность, аутентификация, сохранение целост-
ности и невозможность обмана. Однако для подробного изучения используемых
при этом средств защиты требуется значительно больше, чем простой здравый
смысл, поскольку механизмы реализации этих средств на практике могут
иметь весьма сложную теоретическую подоплеку.
2. Разрабатывая тот или иной механизм или алгоритм защиты, следует обяза-
тельно рассмотреть и возможные контрмеры. Во многих случаях, чтобы вы-
’ -тление 19
явить ускользнувшие от внимания разработчика недостатки системы защиты,
необходимо взглянуть на проблему с точки зрения противоположной стороны.
3. Исходя из п. 2, процедуры, используемые как те или иные средства защи-
ты, часто не являются интуитивно очевидными: из самой формулировки су-
ти средства защиты совсем не следует его необходимость. Применение
средств защиты находит свое обоснование только в контексте рассмотрения
всей совокупности контрмер.
4. Имея уже разработанную систему мер обеспечения безопасности, следует
решить, где и когда эти меры применять. Это касается как физического
места применения (например, выбора точки сети, в которой следует исполь-
зовать определенные средства защиты), так и места применения в логиче-
ской цепи обеспечения безопасности (например, выбора уровня или уровней
протокола передачи информации, такого как TCP/IP, где эти средства за-
щиты можно использовать).
5. Средства защиты, как правило, представляют собой нечто большее, чем оп-
ределенный алгоритм или протокол. Они обычно требуют, чтобы какая-то
часть информации всех заинтересованных в защите сторон всегда остава-
лась секретной (например, была ключом шифра), что влечет необходимость
разработки методов создания, распределения и защиты такой секретной
информации. При этом следует также учитывать ограничения используе-
мых протоколов передачи данных, что вносит дополнительные сложности в
задачу создания механизмов защиты. Так, если механизм защиты предпо-
лагает безусловные ограничения на время, прошедшее с момента отправле-
ния сообщения до его получения, то любой протокол передачи данных или
сеть, допускающие непредсказуемые по длительности задержки, могут сде-
лать такие ограничения практически бессмысленными.
Таким образом, система обеспечения безопасности представляет собой предмет
глубоких размышлений. Данная глава содержит общий обзор составных частей этого
предмета, формирующих структуру всей книги. Мы начнем с описания типов нару-
шений защиты, которые, собственно, и являются причиной разработки механизмов
защиты и создания соответствующих средств их применения. Затем мы рассмотрим
общую модель, охватывающую все такие средства защиты вместе с их механизмами.
1.1. НАРУШЕНИЯ, МЕХАНИЗМЫ И СЛУЖБЫ
ЗАЩИТЫ
Чтобы понять истинные потребности организации в средствах защиты, а также
оценить и выбрать необходимые средства и систему мер безопасности из всего
имеющегося многообразия мер, менеджеру, отвечающему за обеспечение безопасно-
сти, следует использовать некоторый систематический подход, в рамках которого
можно сформулировать необходимые требования защиты и выявить характеристики
средств, призванных удовлетворить эти требования. Один из таких подходов состоит
в рассмотрении следующих трех аспектов защиты информации.
• Нарушения защиты. Любые действия, компрометирующие безопасность
хранения и использования принадлежащей организации информации.
20
Глава 1
• Механизмы защиты. Механизмы выявления и предотвращения нарушений
защиты, а также ликвидации последствий таких нарушений.
• Службы защиты. Сервисные службы, задачей которых является повышение
уровня безопасности систем обработки данных и транспортировки принад-
лежащей организации информации. Такие службы предназначены для про-
тиводействия попыткам нарушить защиту на основе использования одного
или сразу нескольких механизмов защиты.
Службы защиты
Мы рассмотрим указанные аспекты защиты в порядке, обратном тому, в
?:отором они приведены выше. Функции служб защиты можно сравнить с дейст-
зиями, обычно выполняемыми по отношению к реальным документам. Многие
:±»еры человеческой деятельности, даже такие разные, как коммерция, внешне-
золитические связи, военные операции и личная жизнь, связаны с использова-
нием документов и обеспечением целостности и достоверности этих документов
каждой из участвующих в обмене информацией сторон. Документы обычно
жрепляются подписью и помечаются датой, они могут требовать защиты от раз-
глашения, подделки или уничтожения, нотариального или свидетельского заве-
дения, регистрации или лицензирования и т.д.
С тех пор как использование информационных систем стало жизненно не-
:бходимым для ведения многих дел, электронная информация взяла на себя
толь, которая традиционно отводилась бумажным документам. Соответственно,
те операции, которые ранее выполнялись при обработке бумажных документов,
теперь должны выполняться в отношении документов, существующих в элек-
тронном виде. Однако электронные документы имеют несколько иные, особые
:зойства, в результате чего задача выполнения операций, являвшихся ранее co-
re ем простыми, становится сегодня нетривиальной.
1. В подавляющем большинстве случаев оригинальный документ можно отли-
чить от его копии. Но электронный документ — это просто последователь-
ность битов, поэтому между “оригиналом” и любой из его копий нет ника-
кого различия вообще.
2. Изменение бумажного документа оставляет следы физического воздействия
на этот документ. Например, использование ластика делает бумагу в месте
трения более тонкой или менее гладкой по сравнению с остальными участ-
ками листа. Изменение битов в памяти компьютера или в потоке переда-
ваемых данных не оставляет никаких физических следов.
3. Процесс заверения физического документа выражается в физических ха-
рактеристиках этого документа (например, в индивидуальности почерка
подписавшего документ лица или в особенностях оттиска печати нотариу-
са). А любое подтверждение аутентичности электронного документа должно
базироваться на некотором внутреннем доказательстве, заключенном в са-
мой получаемой информации.
В табл. 1.1 приведен список некоторых традиционно выполняемых с бу-
: южными документами операций. Аналогичные действия требуются и при рабо-
с электронными документами и сообщениями. Этот список можно рассматри-
- ведение
21
вать как список функций, которые желательно иметь в любой системе, обеспе-
чивающей защиту данных.
Таблица 1.1. Некоторые из функций, обеспечивающих общую целостность
информации [SIMM92b]
• Идентификация
• Авторизапия
• Лицензирование и/или сертификация
• Подпись
• Освидетельствование (нотариальное заверение)
• Согласование
• Обязательство
• Квитанции (расписки)
• Сертификация происхождения и/или получения
• Индоссамент (передаточная надпись)
• Ограничение доступа (выхода)
• Ратификация
• Учет времени появления
• Аутентификация
• Голосование
• Указание авторства
• Регистрация
• Одобрение/неодобрение
• Конфиденциальность (секретность)
Перечень функций, приведенный в табл. 1.1, слишком длинен и вряд ли
может служить основой для создания какой-либо реальной системы безопасно-
сти. В действительности исследовательские и проектные работы в области защи-
ты компьютерных систем и сетей обычно ограничиваются разработкой неболь-
шого числа основных средств защиты, обеспечивающих различные функции, не-
обходимые для создания достаточно надежной системы. Мы вернемся к
обсуждению этого вопроса после рассмотрения механизмов защиты и соответст-
вующих нарушений.
Механизмы защиты
Не существует единого механизма, который мог бы предоставить в наше распо-
ряжение все возможные средства или выполнять все функции, приведенные в
табл. 1.1. По мере чтения этой книги вы увидите, что на практике используется
множество механизмов защиты. Сейчас необходимо лишь подчеркнуть, что в основе
большинства таких механизмов лежат методы криптографии. Шифрование или
близкое к шифрованию преобразование информации являются наиболее распростра-
ненными методами защиты данных. Поэтому в нашей книге мы сконцентрируем
внимание на принципах разработки и использовании таких методов.
Нарушения
Как указал Симмонс (G. J. Simmons) в работе [SIMM92a], защита информа-
ции сводится к недопущению или, если это не удается, выявлению искажений в
несущих информацию системах, вне зависимости от того, что именно представ-
ляет собой эта информация.
В табл. 1.2 перечислены примеры самых очевидных нарушений, которые
часто наблюдаются в реальных жизненных ситуациях. Эти нарушения представ-
ляют краткий перечень типов атак, которым так или иначе приходится противо-
стоять практически всем организациям и отдельным лицам. Причины посяга-
22
Глава 1
тельств на принадлежащую организации информацию могут быть самыми раз-
ными. К счастью, рассмотрев проблему со стороны возможностей нарушителя,
мы получаем вполне обозримую классификацию таких посягательств.
Таблица 1.2. Побудительные мотивы нарушений [SIMM92b]
1. Несанкционированный доступ к информации (т.е. нарушение секретности или тайны
частной информации).
2. Представление себя в качестве другого лица с целью уклонения от ответственности
(обязательств) либо с целью использования прав другого лица для:
а) отправки фальсифицированной информации;
б) искажения имеющейся информации;
в) несанкционированного доступа с помощью фальсификации идентификационных
данных;
г) фальсифицированной авторизации транзакций или их подтверждения.
3. Уклонение от ответственности за созданную информацию.
4. Заявление о получении информации от другого лица, тогда как на самом деле инфор-
мация была создана самим нарушителем (т.е. фальсификация источника или ответст-
венности).
з. Заявление о том, что (в определенное время) информация была отправлена получате-
лю, тогда как на самом деле информация отправлена не была (или была отправлена в
другое время).
6. Отрицание факта получения информации или же искажение сведений о времени ее
получения.
". Расширение полномочий злоумышленника (например, на получение доступа, создание
информации, ее распространение и т.п.).
S. Несанкционированное изменение полномочий других пользователей (создание учетных за-
писей пользователей, ограничение или расширение имеющихся у них полномочий и т.п.).
J. Сокрытие наличия некоторой информации (тайный контакт) в другой информации
(открытый контакт).
10. Внедрение в линию связи между другими пользователями в качестве активного
(тайного) ретранслятора.
11. Слежение за тем, к какой информации (источники, файлы и т.п.), кем и в какое вре-
мя осуществляется доступ, даже если сама информация остается недоступной (т.е.
анализ потока данных, передаваемых по коммуникационным каналам к базам дан-
ным, программному обеспечению и т.п.).
12. Дискредитация протокола защиты целостности информации путем разглашения све-
дений, которые (по этому протоколу) должны храниться в секрете.
13. Изменение функций программного обеспечения (обычно с помощью добавления скры-
тых функций).
14. Провоцирование других на нарушение протокола путем предоставления неправильной
информации.
15. Подрыв доверия к протоколу путем искусственного создания ситуаций, приводящих к
явным отказам системы.
16. Создание препятствий взаимодействию других пользователей, например, путем скры-
того вмешательства, заставляющего систему прекратить легальный сеанс связи как
нелегальный.
введение
23
Попытки нарушения защиты компьютерной системы или сети можно клас-
сифицировать, рассмотрев функции компьютерной системы как объекта, предос-
тавляющего информацию. В общем случае мы имеем дело с потоком информа-
ции от некоторого источника (например, из файла или области памяти) в на-
правлении адресата информации (например, в другой файл или непосредственно
пользователю). Нормальный поток информации схематически изображен на
рис. 1.1, а. Остальные части рис. 1.1 иллюстрируют следующие четыре типа
атак (нарушений нормального потока информации).
Источник Адресат
информации информации
а) нормальный поток
Рис. 1.1. Угрозы безопасности
• Разъединение. Ресурс системы уничтожается, становится недоступным или
непригодным к использованию. При этом нарушается доступность инфор-
мации. Примерами такого типа нарушений могут служить вывод из строя
оборудования (например, жесткого диска), обрыв линии связи или разру-
шение системы управления файлами.
• Перехват. К ресурсу открывается несанкционированный доступ. При этом
нарушается конфиденциальность информации. Получившим несанкциони-
рованный доступ нарушителем может быть физическое лицо, программа
или компьютер. Примерами такого типа нарушений являются подключение
к кабелю связи с целью перехвата данных и незаконное копирование фай-
лов или программ.
24
Глава 1
• Модификация. К ресурсу не только открывается несанкционированный дос-
туп, но и сам ресурс изменяется нарушителем. При этом нарушается цело-
стность информации. Примерами такого типа нарушений являются измене-
ние значений в файле данных, модификация программы с целью изменения
ее функций и характеристик, изменение содержимого передаваемого по се-
ти сообщения и др.
• Фальсификация. В систему вносится подложный объект. При этом нарушается
аутентичность информации. Примерами такого типа нарушений могут служить
отправка поддельных сообщений по сети или добавление записей в файл.
Кроме того, заслуживает внимания классификация нарушений в терминах
пассивных и активных атак (рис. 1.2).
Раскрытие содержимого Анализ потока данных
сообщений
Активные угрозы
Разъединение
(нарушение
доступности)
Модификация
(нарушение
целостности)
Фальсификация
(нарушение
аутентичности)
Рис. 1.2. Активные и пассивные угрозы безопасности сети
-зение
25
Пассивные нарушения
Пассивные нарушения защиты (пассивные атаки) носят характер перехва-
та, или мониторинга передаваемых данных. Целью нарушителя в этом случае
является получение передаваемой информации. Пассивные нарушения можно
условно разделить на две группы: раскрытие содержимого сообщений и анализ
потока данных.
Что такое раскрытие содержимого сообщений, пояснять не нужно. Теле-
фонный разговор, сообщение электронной почты или пересылаемый файл могут
содержать важную или конфиденциальную информацию. Было бы желательно,
чтобы с передаваемой информацией не могли ознакомиться те, кому эта инфор-
мация не предназначена.
Второй тип пассивных нарушений — анализ потока данных — более изощрен.
Предположим, что мы используем такой способ маскировки содержимого сообщений
или других передаваемых данных, при котором нарушитель, даже получив сообще-
ние в свое распоряжение, не имеет возможности извлечь содержащуюся в сообщении
информацию. Чаще всего для маскировки содержимого применяется шифрование.
Но даже если содержимое вполне надежно скрыто шифрованием, у нарушителя ос-
тается возможность наблюдать характерные признаки передаваемых сообщений. На-
пример, можно обнаружить и идентифицировать отправителя и используемые для
отправки сообщений узлы, выяснить частоту обмена сообщениями и их длину. Та-
кая информация может оказаться весьма полезной при попытках определить причи-
ны и суть наблюдаемого обмена данными.
Пассивные нарушения защиты обнаружить очень трудно, поскольку они не
предполагают каких-либо изменений данных. Но нарушения такого типа вполне
реально предотвратить. Поэтому в случае пассивных нарушений зашиты необхо-
димо сосредоточиться на их предупреждении, а не выявлении.
Активные нарушения
Вторым типом нарушений защиты являются активные нарушения (активные
атаки). Эти нарушения связаны либо с изменением потока данных, либо с созданием
фальшивых потоков и могут быть разделены на четыре труппы: имитация, воспро-
изведение, модификация сообщений и помехи в обслуживании.
Имитация означает попытку одного объекта выдать себя за другой. Обычно
имитация выполняется вместе с попыткой активного нарушения какого-нибудь
другого типа. Например, перехватив поток данных аутентификации, которыми
обмениваются системы, нарушитель может затем воспроизвести реальную после-
довательность сообщений аутентификации, что позволяет объекту с ограничен-
ными полномочиями расширить свои полномочия, имитировав объект с более
широкими полномочиями.
Воспроизведение представляет собой пассивный перехват блока данных и
последующую ретрансляцию перехваченных данных с целью получения несанк-
ционированного эффекта.
Модификация сообщений означает либо изменение части легитимного сообще-
ния, либо его задержку, либо изменение порядка поступления сообщений с целью
получения несанкционированного эффекта. Например, сообщение “Разрешить доступ
к секретному файлу Бюджет Ивану Иванову” можно преобразовать к виду
“Разрешить доступ к секретному файлу Бюджет Петру Петрову”.
26
Глава 1
Помехи в обслуживании (блокирование сервиса) создают препятствия в
нормальном функционировании средств связи или управлении ими. Такие на-
рушения могут иметь вполне конкретную цель: например, объект может задер-
живать все сообщения, направленные определенному адресату (скажем, средст-
вам аудита системы защиты). Другим примером является блокирование работы
всей сети путем либо вывода сети из строя, либо преднамеренной ее перегрузки
интенсивным потоком сообщений, заметно снижающим производительность.
Активные нарушения защиты имеют характеристики, противоположные
характеристикам пассивных нарушений. Если пассивные нарушения трудно об-
наружить, но существуют методы, позволяющие их предотвратить, то активные
нарушения полностью предотвратить очень сложно, поскольку это можно осуще-
: твить только непрерывной физической защитой всех средств связи. Поэтому в
:лучае активных нарушений защиты основной целью должно быть оперативное
::х выявление и быстрое восстановление нормальной работоспособности системы,
которая после таких нарушений может работать медленнее или не работать во-
:5ще. В то же время, поскольку своевременное выявление нарушений, как пра-
; ило, играет для нарушителя роль сдерживающего фактора, оно тоже может
а досматриваться как часть системы предупреждения нарушений.
1.3. СЛУЖБЫ ЗАЩИТЫ
Одним из используемых на практике наборов функций защиты является
т-дующий:2
• конфиденциальность;
• аутентификация;
• целостность;
• невозможность обмана;
• управление доступом;
• доступность ресурсов.
нфиденциальность
Средства обеспечения конфиденциальности призваны защитить поток дан-
. эт пассивных атак. Можно установить несколько уровней защиты в зависи-
те от важности содержимого сообщений. В самой широкой форме соответст-
х:ая служба защиты должна обеспечивать защиту всех данных, передавае-
< - между любыми двумя пользователями в течение определенного времени.
- -; имер, если между двумя системами установлена виртуальная связь, такая
1 д а я защита может препятствовать утечке любых пользовательских данных
~ передаче. В более узкой форме служба защиты может обеспечивать за-
3 литературе по безопасности нет единого мнения по поводу используемой тер-
ли. Например, термин “целостность" иногда служит для обозначения всей сово-
~.и аспектов защиты информации, а термин “аутентификация” может обозна-
. литификацию вместе со всеми функциями, отнесенными в данном списке к
обеспечения целостности.
:е 27
щиту отдельных сообщений или даже отдельных частей сообщения. Такие меры
обычно менее эффективны, чем общая защита, а их реализация в некоторых
случаях может оказаться и сложнее, и дороже.
Другим аспектом конфиденциальности является защита потока данных от
возможности его аналитического исследования. Это означает невозможность для
нарушителя обнаружить как источник информации, так и адресата, выяснить
частоту отправки сообщений, их размеры и другие подобные свойства, которыми
характеризуются сообщения в системе связи.
Аутентификация
Сервис аутентификации предназначен для того, чтобы обеспечить надежную
идентификацию источника информации. В случае единичного сообщения, например
информирующего извещения или сигнала тревоги, задачей службы аутентификации
является проверка того, что источником такого сообщения является именно тот объ-
ект, за который выдает себя отправитель. При внешнем интерактивном взаимодей-
ствии, например подключении к главному узлу с терминала, можно выделить два
аспекта функционирования такого сервиса. Во-первых, при установке соединения
средства аутентификации должны гарантировать, что оба участвующих в сеансе свя-
зи объекта аутентичны (т.е. действительно являются теми, за кого себя выдают). Во-
вторых, в ходе последующего обмена данными эти средства не должны допускать,
чтобы на поток данных влияла какая-либо третья сторона, имитирующая один из
двух законных объектов связи и использующая это с целью несанкционированной
отправки и получения информации.
Целостность
Как и конфиденциальность, целостность может относиться к потоку сооб-
щений, отдельному сообщению или даже части сообщения. И точно так же в
этом случае наиболее целесообразной является защита всего потока.
Средства защиты целостности сообщений на основе соединений имеют дело с
потоком сообщений и обеспечивают гарантию того, что принятые сообщения будут в
точности соответствовать отправленным, без изъятий, дополнений, изменений в ис-
ходном порядке следования и повторов. Эти средства обеспечивают также защиту от
разрушения данных. Таким образом, средства защиты целостности на основе соеди-
нений содержат средства защиты потока данных как от модификации, так и от по-
мех в обслуживании. С другой стороны, средства защиты целостности сообщений без
установления соединений, имеющие дело с отдельными сообщениями, обеспечивают
защиту только от модификации сообщений.
Различают службы, предлагающие и не предлагающие возможность восста-
новления целостности сообщений. Поскольку средства защиты целостности при-
званы противостоять активным атакам, здесь более важным оказывается выяв-
ление, а не предупреждение нарушений. Если выявлено нарушение целостности
потока данных, такая служба может только сообщать о нарушении, а восстанов-
ление поврежденной или утраченной информации может выполняться другими
программными средствами или требовать вмешательства оператора. В других
случаях, которые мы рассмотрим ниже, сами средства обеспечения целостности
могут предполагать наличие некоторого механизма, с помощью которого утра-
ченная целостность данных должна восстанавливаться автоматически. В общем
28
Глава 1
случае использование средств автоматического восстановления является более
предпочтительным вариантом.
Невозможность обмана
Средства, гарантирующие невозможность обмана, должны не позволить от-
правителю или получателю отказаться от факта пересылки сообщения. Таким
образом, если сообщение было отправлено не внушающим доверия отправите-
лем, получатель должен иметь возможность доказать, что сообщение этим от-
правителем действительно было отправлено. Точно так же, когда сообщение от-
правлено не внушающему доверия адресату, отправитель должен иметь возмож-
ность доказать, что оно этим адресатом было действительно получено.
Управление доступом
В контексте защиты сетей управление доступом означает возможность огра-
- -.шивать и контролировать доступ к узлам сети и приложениям по каналам свя-
Для осуществления такого контроля, при котором каждый объект имеет
нэй набор полномочий в системе, необходимо иметь возможность идентифици-
: . зать объекты при каждой попытке получения ими доступа к ресурсам.
доступность ресурсов
Многие виды нарушений приводят к недоступности ресурсов или значительно-
- затруднению доступа к ним. При этом в одних случаях эффективными оказыва-
•_тся автоматизированные контрмеры, такие как аутентификация и шифрование, в
время как в других случаях для предупреждения отказов или восстановления
2 ктупности системы могут потребоваться определенные физические действия.
1.4. МОДЕЛЬ ЗАЩИТЫ СЕТИ
Модель, в самых общих терминах описывающая большую часть того, что
..ц собираемся рассмотреть в данной книге, показана на рис. 1.3. Пусть требует-
- передать сообщение одной участвующей в передаче стороны другой через ка-
:-:-то связывающую их сеть. Чтобы обмен информацией состоялся, обе сторо-
называемые доверителями (принципалами) транзакции, должны вступить
. взаимодействие. С этой целью создается логический информационный канал,
: чего определяется маршрут прохождения данных от источника к адресату и
в- использования обеими сторонами выбирается коммуникационный протокол
в .пример протокол TCP/IP).
Вопросы безопасности возникают в тех случаях, когда необходимо или же-
ш.пьно обеспечить защиту передаваемой информации от некоторого потенци-
.-.:Н"о противника, который может угрожать конфиденциальности, аутентич-
ен информации и т.п. При этом любая технология защиты имеет следующие
. - : вставляющие.
» Обеспечивающее защиту преобразование отправляемой информации. При-
черами таких преобразований являются шифрование сообщения, в резуль-
тате которого противник лишается возможности это сообщение прочесть, и
-пение 29
добавление зависящего от сообщения кода, по которому адресат сможет
идентифицировать отправителя.
Заслуживающая доверия
третья сторона
(арбитр, распределитель секретной информации)
Доверитель
Обеспечивающее
защиту
преобразование
Доверитель
Сообщение —►
Информационный
канал
Секретная
информация А
-► Сообщение
Секретная
информация
Обеспечивающее
защиту
преобразование
Противник
Рис. 1.3. Модель защиты сети
• Использование некоторой секретной информации (общей для обеих участвую-
щих в транзакции сторон), которая должна оставаться неизвестной противнику.
Примером такой секретной информации может быть ключ шифра, применяе-
мый для кодирования сообщения с помощью соответствующего преобразования
перед отправкой и для последующего декодирования после получения.3
Для обеспечения защиты может понадобиться участие третьей стороны, за-
служивающей доверия обоих участников транзакции. Например, третья сторона
может осуществлять доставку секретной информации обоим доверителям, обес-
печивая ее защиту от всех других. Или же третья сторона может требоваться
для гарантии аутентичности передаваемого сообщения.
Из приведенной на рис. 1.3 общей модели следует, что при разработке конкрет-
ного средства защиты необходимо решить следующие четыре основные задачи.
1. Разработать алгоритм для обеспечивающего защиту преобразования инфор-
мации. Алгоритм должен быть таким, чтобы противник не мог отменить
его действие.
2. Создать секретную информацию, которая будет использоваться с алгоритмом.
3. Разработать методы доставки и совместного использования этой секретной
информации.
3 В главе 3 описывается одна из форм шифрования, называемая шифрованием с от-
крытым ключом, при которой такой секретной информацией достаточно располагать
только одной из участвующих в транзакции сторон.
30
Глава 1
4. Выбрать протокол, с помощью которого оба доверителя смогут использовать
разработанный алгоритм и созданную секретную информацию для обеспе-
чения необходимого уровня защиты.
Часть II настоящей книги посвящена рассмотрению различных механизмов и
•тозб защиты, укладывающихся в рамки представленной на рис. 1.3 модели. Одна-
зутцествуют и другие ситуации, которые относятся к вопросам защиты и тоже
з-зматриваются в данной книге, но не отражаются адекватно этой моделью. Общая
гель для таких ситуаций показана на рис. 1.4, где представлена схема защиты
зз< рмационной системы от нежелательного доступа. Многие читатели слышали о
зс.темах, связанных с существованием хакеров, пытающихся проникнуть в систе-
подключенные к общедоступной сети. Хакером может быть человек, которому
з-зто нравится взламывать защиту систем и входить в защищенные системы, без
з- их бы то ни было недоброжелательных намерений. Но нарушителем может ока-
зъзя и недовольный служащий, решивший нанести ущерб компании, и преступ-
з-:. намеревающийся использовать имеющиеся в компьютерной системе данные с
тьз-о обогащения (например, получить номера платежеспособных кредитных кар-
тоз-: или осуществить незаконный перевод денег).
Информационная система
зэотивник
звек
пример, взломщик)
граммное обеспечение
пример, вирус, “червь”) Канал доступа Функция
«привратника»
Вычислительные ресурсы
(процессор, память,
устройства ввода/вывода)
Данные
Процессы
Программное обеспечение
Внутренние средства защиты
Рис. 1.4. Модель защиты доступа к сети
Еще одним типом нежелательного воздействия является внедрение в ком-
з-з торную систему программной логики, которая использует уязвимые места
зтомы и вмешивается в работу приложений и утилит (например, редакторов и
зззиляторов). Программы могут порождать угрозы двух следующих типов.
• Угроза несанкционированного доступа к информации означает перехват
или модификацию данных пользователями, которые не должны иметь дос-
тупа к этим данным.
• Угроза злонамеренного использования сервисных служб основана на недос-
татках средств защиты и заключается в создании помех в их применении
легальными пользователями.
Примерами нарушений, осуществляемых с помощью программного обеспе-
тозя. является использование вирусов и “червей”. Такие объекты могут вно-
тозя в систему с дискеты, содержащей нежелательную программную логику,
знтую в другом, полезном, программном обеспечении. Нежелательная про-
з. зззная логика может внедряться в систему и через сеть — такой способ вне-
-зззз.я значительно усложняет задачу защиты сети.
- ление
33
Защитные механизмы, необходимые для противодействия попыткам неже-
лательного доступа, можно разделить на два больших класса (см. рис. 1.4). За-
щитные механизмы первого класса играют роль “привратника”. К функциям
“привратника” относится выполнение процедур входа в систему, призванных
разрешить вход в систему только легальным пользователям на основе использо-
вания паролей, а также применение экранирующей программной логики, пред-
назначенной для выявления и пресечения попыток внедрения в систему
“червей”, вирусов и других подобных объектов. Если же нарушителю или про-
граммному обеспечению все же удастся получить доступ к системе, должна сра-
ботать “вторая линия обороны”, состоящая из различных внутренних средств
контроля основных параметров системы и анализа хранящейся в системе ин-
формации с целью выявления присутствия нарушителей. Эти вопросы обсужда-
ются в части III книги.
1.5. СТАНДАРТЫ INTERNET
И ДОКУМЕНТЫ RFC
Многие защищенные сетевые протоколы и приложения, описываемые в
этой книге, являются стандартами Internet и определены в документах RFC
(Request for Comments — запрос разъяснений). Список всех документов RFC,
цитируемых в данной книге, приводится в приложении 1. В этом разделе пред-
лагается краткий обзор соответствующих стандартов Internet и документов RFC.
Internet Society
По общепринятому соглашению организация, известная под названием In-
ternet Society (Сообщество Internet), взяла на себя ответственность за разработку
и публикацию стандартов, предназначенных для использования в Internet. In-
ternet Society представляет собой объединение профессионалов, руководящих
целым рядом комиссий и исследовательских групп, занимающихся разработкой
средств и стандартов Internet.
Internet Society является координационным комитетом проектирования и
разработки средств Internet. В сфере интересов этой организации находятся как
функционирование самой Internet, так и вопросы стандартизации протоколов,
используемых в конечных системах для обеспечения взаимодействия разнород-
ных систем. В рамках Internet Society за конкретную работу по созданию и пуб-
ликации стандартов отвечают следующие три организации.
• IAB (Internet Architecture Board — Совет по архитектуре Internet). Несет
ответственность за разработку общей архитектуры Internet, обеспечивая ру-
ководство и указывая общее направление деятельности IETF.
• IETF (Internet Engineering Task Forces — Проблемная группа проектиро-
вания Internet). Звено Internet, осуществляющее разработку протоколов и
обеспечивающее развитие Internet.
• IESG (Internet Engineering Steering Group — Исполнительный комитет
IETF). Несет ответственность за техническое управление деятельностью
IETF и процессом стандартизации Internet.
32
Глава 1
Публикация документов RFC
Процесс разработки новых стандартов и протоколов для Internet осуществ-
ляется рабочими группами, создаваемыми IETF. Участие в рабочей группе доб-
ровольно, и входить в такую группу может любая заинтересованная сторона. В
ходе разработки спецификаций рабочая группа создает проект документа, назы-
ваемый Internet Draft (Internet-проект), помещаемый в доступный в оператив-
ном режиме каталог “Internet Drafts” IETF. Такой документ может оставаться в
состоянии Internet-проекта до шести месяцев, и в течение этого времени заинте-
ресованные стороны имеют возможность анализировать и комментировать про-
ект. В течение этого времени IESG может одобрить публикацию Internet-проекта
в виде документа RFC (Request for Comments). Если проект в течение шести ме-
сяцев не получает статуса RFC, он из каталога отзывается. Впоследствии рабо-
чая группа может опубликовать исправленную версию проекта.
IETF несет ответственность за публикацию документов RFC, одобренных IESG.
Документы RFC представляют собой практические комментарии сообщества иссле-
дователей и разработчиков Internet. Документы этой серии могут касаться любой
темы, связанной с компьютерными коммуникациями, а могут быть и отчетом кон-
ференции, посвященной обсуждению спецификаций конкретного стандарта.
Процесс стандартизации
Решение о том, какие из документов RFC станут стандартами Internet,
принимается IESG на основе рекомендаций IETF. Чтобы стать стандартом, спе-
цификации должны удовлетворять следующим критериям:
• быть устойчивыми и вполне понятыми;
• быть технически состоятельными (компетентными);
• иметь разнообразные независимые и пригодные для межплатформенной
среды реализации со значительным опытом их использования;
• получить заметную публичную поддержку;
• быть действительно полезными для использования в некоторых или во всех
областях Internet.
Ключевой разницей между этими критериями и критериями, используемы-
ми для международных стандартов ISO (International Organization for Standardi-
zation — Международная организация по стандартизации) и ITU-T (International
Telecommunications Union — Международный телекоммуникационный союз),
является выделение здесь особой роли практического опыта применения.
В левой части рис. 1.5 показана последовательность шагов, называемая по-
рядком утверждения стандарта. Этот порядок обязателен для любых специфи-
каций, претендующих на то, чтобы стать стандартом (сам процесс определяется
документом RFC 2026). При переходе от каждого из этих шагов к следующему
предполагается возрастание тщательности анализа и интенсивности тестирова-
ния. На каждом шаге IETF должна выдать рекомендации по улучшению прото-
кола, a IESG — их ратифицировать. Процесс начинается тогда, когда IESG одоб-
ряет публикацию документа Internet Draft (Internet-проект) в виде документа
RFC, имеющего статус Proposed Standard (предлагаемый стандарт).
Введение
33
Рис. 1.5. Процесс публикации документов RFC
Белые блоки схемы представляют временные состояния документа, время
существования которых, в принципе, должно на практике быть сведено к мини-
муму. Однако документ должен сохранять статус Proposed Standard
(предлагаемый стандарт) по крайней мере шесть месяцев, а статус Draft Stan-
dard (черновик стандарта) — не менее четырех месяцев, чтобы было достаточно
времени для обсуждения и критики. Серые блоки представляют долгосрочные
состояния документа, которые могут существовать многие годы.
Чтобы определенный набор спецификаций получил статус Draft Standard
(черновик стандарта), должно существовать не менее двух независимых реализа-
ций, успешно взаимодействующих с другими продуктами и доказавших свою
функциональную адекватность на практике.
В результате положительного опыта использования практической реализа-
ции набора спецификаций эти спецификации могут получить статус стандарта
Internet (Internet Standard): набор спецификаций получает номер стандарта
(номер STD), и с ним связывается соответствующий номер RFC.
Наконец, когда протокол устаревает, ему присваивается статус Historic
(исторический).
Документы вне процесса стандартизации
Протоколы и другие спецификации, которые не готовы для выдвижения на
роль стандарта, могут быть опубликованы как экспериментальные документы
RFC (Experimental RFC). После соответствующей доработки такие спецификации
обсуждются повторно. Если набор спецификаций оказывается достаточно ста-
бильным, удовлетворяет определенным требованиям дизайна, кажется вполне
понятным, получает заметную поддержку сообщества и кажется удовлетворяю-
34
Глава 1
щим интересы сообщества в степени, достаточной для того, чтобы считаться
важным, то соответствующий документ RFC получит статус предлагаемого стан-
дарта (Proposed Standard).
Наконец, с целью общего информирования сообщества Internet публикуют-
ся информационные спецификации (Informational Specification).
1.6. РЕКОМЕНДУЕМЫЕ ИСТОЧНИКИ
ДОПОЛНИТЕЛЬНОЙ ИНФОРМАЦИИ
В книге [PFLE97] предлагается хорошее введение в область защиты компь-
ютеров и сетей. Другим неплохим источником информации по данной теме яв-
ляется [ABRA95].
ABRA95 Abrams, М.; Jajodia, S.; and Podell, Н., eds. Information Security: An Integral j
Collection of Essays. Los Alamitos, CA: IEEE Computer Security Press, 1995.
PFLE97 Pfleeger, C. Security in Computing. Upper Saddle River, NJ: Prentice Hall,
1997.
ДОПОЛНЕНИЕ 1.1. РЕСУРСЫ INTERNET И WEB
В Internet и Web имеется множество ресурсов, содержащих сведения, до-
полняющие материал данной книги и позволяющие всегда быть в курсе послед-
них достижений в области защиты компьютерных систем.
Web-узлы данной книги
Для поддержки читателей книги был создан Web-узел по адресу
http://www.shore.net/~ws/NetSec.html. На этом узле содержится следующая
информация.
• Страница для студентов факультетов информатики. Эта Web-страница
предлагает информационную помощь студентам, изучающим информатику,
и содержит соответствующие ссылки. Там имеется целый ряд документов,
которые могут оказаться полезными при изучении компьютерных наук.
Кроме того, на странице предлагаются обзоры, посвященные математиче-
ским методам, лежащим в основе использования соответствующих средств,
имеются советы, касающиеся выполнения и оформления исследовательских
работ и самостоятельных заданий, ссылки на исследовательские ресурсы в
области информатики (например, на хранилища отчетов и библиографиче-
ских ссылок) и другие полезные ссылки.
• Список исправлений. Будет поддерживаться список исправлений для этой
книги. По мере необходимости соответствующий файл будет обновляться.
Пожалуйста, присылайте любые замеченные вами ошибки электронной по-
чтой по адресу ws@shore.net.
• Адреса полезных Web-узлов. Ссылки на другие Web-узлы, включая узлы,
перечисленные в данном дополнении и в остальных главах книги.
Введение
35
• Рисунки и диаграммы. Набор используемых в этой книге рисунков и диа-
грамм в формате PDF (Adobe Acrobat).
• Список рассылки Internet. Информация о подключении к списку рассылки
Internet, соответствующему данной книге.
• Курсы по защите сетей. Ссылки на начальные страницы курсов, основан-
ных на материале данной книги. Эти страницы могут быть полезны другим
преподавателям в отношении использования новых идей для совершенство-
вания структуры их собственных курсов.
Списки исправлений для других моих книг, а также информация о торго-
вых скидках на эти книги доступна по адресу http: //www.shore.net/~ws.
Другие Web-узлы
Существует множество других Web-узлов, предлагающих интересные сведе-
ния в дополнение к материалу данной книги. В последующих главах ссылки на
Web-узлы будут приводиться в разделах “Рекомендуемые источники дополни-
тельной информации”. Поскольку адреса URL многих узлов часто меняются, в
книге не указываются конкретные адреса, а предлагается обратиться к упомяну-
той выше Web-странице книги, где должны быть указаны текущие адреса соот-
ветствующих узлов.
I С точки зрения защиты сетей интересными являются следующие
Лг, t т т, Web-узлы.
(ЗЬЙМкх’''' • COAST. Обширный перечень ссылок на узлы, посвященные во-
просам криптографии и защиты сетей.
• IETF Security Area. Постоянно обновляемые сведения о стан-
дартах на средства обеспечения безопасности в Internet.
• Computer and Network Security Reference Index. Хороший
справочник по поставщикам и коммерческим продуктам, отве-
ты на часто задаваемые вопросы, архивы групп новостей, ста-
тьи и ссылки на другие Web-узлы.
• The Cryptography FAQ. Обширный и заслуживающий внимания
список часто задаваемых вопросов с ответами на них, охваты-
вающий все аспекты криптографии.
• Tom Dunigan’s Security Page. Прекрасный перечень ссылок на
Web-узлы, посвященные криптографии и защите сетей.
• IEEE Technical Committee on Security and Privacy. Копии ин-
формационных бюллетеней и сведения о деятельности IEEE.
Группы новостей USENET
Различным аспектам защиты сетей и криптографии посвящено множество
групп новостей, правда, для них характерен слишком низкий уровень соотноше-
ния “сигнал/шум”, но имеет смысл проверить экспериментальным путем, удов-
летворяет ли ваши запросы какая-то из этих групп. К теме данной книги имеют
непосредственное отношение следующие группы новостей.
36
Глава 1
• alt. security. Общее обсуждение тем, связанных с безопасностью.
• sci. crypt. Общая дискуссия по криптологии и связанным с ней темам.
• sci. crypt. research. Эта модерируемая группа включает новости о прово-
димых исследованиях; публикуемые в ней статьи должны иметь отношение
к техническим аспектам криптологии.
• comp, security .firewalls. Общее обсуждение брандмауэров и технологии
их использования.
Введение
37
This page intentionally left blank
зчи Криптография
До сих пор наиболее важным из автоматизирован-
‘ _ . И| ных средств защиты сетей и коммуникаций является
' ' шифрование. Широко используются две формы шифро-
J ' "Д; вания — традиционное, или симметричное, шифрование
| и шифрование с открытым ключом, иначе называемое
к асимметричным шифрованием. В части I книги предла-
t . - ; ’”1'', гается обзор основных принципов криптографии на ос-
; . /;- . - нове традиционного шифрования и криптографии с от-
; ~ крытым ключом, рассматриваются широко используе-
'. : ’ мь1е алгоритмы и обсуждаются основные сферы
применения этих двух подходов.
-’Л. Глава 2. Традиционное шифрование
и конфиденциальность
В главе 2 обсуждаются методы традиционного
шифрования на основе наиболее широко используемой
технологии: стандарта шифрования DES и его последо-
вателя — версии DES с тремя ключами. Наряду с вопро-
сами внутренней структуры алгоритма шифрования при
использовании традиционного шифрования для обеспе-
чения конфиденциальности большое значение имеют во-
просы реализации. В главе обсуждается шифрование
длинных сообщений, сравнивается сквозное и канальное
шифрование, а также рассматриваются методы распре-
деления ключей.
Глава 3. Шифрование с открытым ключом
и аутентификация
Аутентификация является мерой защиты, не ме-
нее важной, чем конфиденциальность. Как минимум,
аутентификация сообщения должна гарантировать,
что сообщение пришло из указанного в нем источни-
ка. Кроме того, аутентификация может включать за-
щиту от модификации, задержки, повторного воспро-
изведения сообщений и изменения порядка их следо-
вания. Глава 3 начинается с анализа требований,
предъявляемых к средствам аутентификации, а затем
рассматриваются различные подходы к обеспечению аутентификации. Ключе-
вым элементом различных схем аутентификации является использование аутен-
тификатора, в качестве которого обычно выступают либо код аутентификации
сообщения (МАС), либо значение функции хэширования. В главе рассматрива-
ются вопросы реализации соответствующих типов алгоритмов и анализируется
несколько конкретных примеров.
Шифрование с открытым ключом осуществило революцию в сфере защиты
коммуникаций. Глава 3 предлагает введение в область шифрования с открытым
ключом. Подробно рассматривается алгоритм RSA и снова поднимается вопрос
управления ключами. В этой же главе обсуждается нашедшая широкое приме-
нение технология обмена ключами Диффи-Хеллмана. Кроме того, в главе опре-
деляются цифровые подписи и рассматривается их применение.
40
Часть I. Криптография
ГЛАВА
Традиционное
шифрование
и конфиденци-
альность
2.1. Принципы традиционного шифрования
2.2. Алгоритмы традиционного шифрования
2.3. Режимы блочного шифрования
2.4. Размещение средств шифрования
2.5. Распределение ключей
2.6. Рекомендуемые источники дополнительной
информации
2.7. Задачи
Традиционное шифрование, называемое также симметричным шифрова-
нием, шифрованием с секретным ключом и шифрованием с одним клю-
чом, до изобретения шифрования с открытым ключом было единствен-
ным методом шифрования.1 Сегодня этот метод по-прежнему остается самым
распространенным.
Мы начнем эту главу с обсуждения общей модели процесса традиционного
шифрования — это поможет в дальнейшем понять контекст, в котором приме-
няются конкретные алгоритмы. Затем мы рассмотрим три важных алгоритма
шифрования — DES, “тройной” DES и AES. После этого будет рассмотрено при-
менение этих алгоритмов в контексте обеспечения конфиденциальности.
2.1. ПРИНЦИПЫ ТРАДИЦИОННОГО
ШИФРОВАНИЯ
Схема традиционного шифрования складывается из следующих пяти со-
ставляющих (рис. 2.1).
• Открытый текст. Это исходное сообщение или данные, подаваемые на вход
алгоритма шифрования.
• Алгоритм шифрования. Алгоритм, выполняющий различные подстановки и
преобразования в открытом тексте.
• Секретный ключ. Секретный ключ также подается на вход алгоритму. От
этого ключа зависят конкретные подстановки и преобразования, выполняе-
мые алгоритмом.
• Шифрованный текст. Это “перемешанное” сообщение, получаемое на выхо-
де алгоритма. Оно зависит от открытого текста и секретного ключа. Для
одного и того же сообщения два разных ключа порождают разные шифро-
ванные тексты.
• Алгоритм дешифрования. По сути, это алгоритм шифрования, выполняе-
мый в обратную сторону. Он берет шифрованный текст и тот же секретный
ключ, который применялся при шифровании, и восстанавливает исходный
открытый текст.
Для надежности традиционного шифрования необходимо выполнение сле-
дующих требований.
1. Алгоритм шифрования должен быть достаточно стойким. Как минимум, ал-
горитм должен быть таким, чтобы противник, знающий алгоритм и имею-
щий доступ к одному или нескольким фрагментам открытого текста, не
смог бы расшифровать весь текст или вычислить ключ. Это требование
обычно формулируется в более строгой форме: противник не должен иметь
возможности дешифровать шифрованный текст или открыть ключ даже при
1 Шифрование с открытым ключом было впервые описано в открытой литературе
в 1976 г. Представители NSA (National Security Agency — Агентство национальной
безопасности США) заявляют, что специалисты NSA разработали этот метод не-
сколькими годами раньше.
42
Часть I. Криптография
наличии нескольких фрагментов шифрованного текста вместе с
соответствующими им фрагментами открытого текста.
2. Отправитель и получатель должны некоторым тайным образом получить
копии секретного ключа и сохранять его в тайне. Если кто-то сможет от-
крыть ключ и узнать алгоритм, то все сообщения, шифруемые с использо-
ванием этого ключа, окажутся незащищенными.
Секретный ключ,
известный отправителю
и адресату
Секретный ключ,
известный отправителю
и адресату
Алгоритм
шифрования
(например, DES)
открытый
текст
Пересылаемый
шифрованный текст
Алгоритм открытый
дешифрования текст
(обращение алгоритма
шифрования)
Рис. 2.1. Упрощенная модель традиционного шифрования
Важно отметить, что надежность традиционного шифрования зависит от
секретности ключа, а не от секретности алгоритма. Поэтому предполагается, что
должна быть обеспечена практическая невозможность расшифровки сообщения
на основе знания шифрованного текста, даже если известен алгоритм шифрова-
ния/дешифрования. Другими словами, не требуется обеспечивать секретность
алгоритма — необходимо обеспечить секретность ключа.
Именно эта особенность схемы традиционного шифрования является причиной
ее широкого применения. Отсутствие необходимости хранить в секрете алгоритм да-
ет производителям возможность реализовать алгоритмы шифрования данных в виде
дешевых общедоступных микросхем, которыми оснащены сегодня многие современ-
ные системы. При использовании традиционного шифрования основная проблема
защиты заключается в надежном сохранении секретности ключа.
Криптография
Классификация криптографических систем в общем случае строится на ос-
нове следующих трех независимых характеристик.
1. Тип операций по преобразованию открытого текста в шифрованный. Все алго-
ритмы шифрования основываются на использовании двух операций: замены,
означающей замещение каждого элемента открытого текста (бита, буквы, груп-
пы битов или группы букв) некоторым другим элементом, и перестановки, оз-
начающей изменение порядка следования элементов открытого текста. При
этом главным требованием оказывается отсутствие потерь информации (т.е. об-
ратимость всех операций). В большинстве реальных схем шифрования приме-
няют не одну, а комбинацию нескольких операций замены и перестановки. Со-
ответствующие шифры называются продукционными.
Глава 2. Традиционное шифрование и конфиденциальность
43
2. Число применяемых ключей. Если и отправитель, и получатель используют
один и тот же ключ, система называется симметричной, системой с одним
ключом, системой с секретным ключом или схемой традиционного шифро-
вания. Если отправитель и получатель используют разные ключи, система
называется асимметричной, системой с двумя ключами или схемой шифро-
вания с открытым ключом.
3. Метод обработки открытого текста. Блочное шифрование предполагает об-
работку открытого текста блоками, в результате которой получаются блоки
шифрованного текста. Поточное шифрование подразумевает шифрование
элементов открытого текста последовательно, после чего на каждом этапе
получается по одному элементу шифрованного текста.
Криптоанализ
Процесс воссоздания противником открытого текста или ключа называется
криптоанализом. При этом используемая криптоаналитиком стратегия зависит
от схемы шифрования и информации, имеющейся в его распоряжении.
В табл. 2.1 приведен обобщенный перечень различных типов криптоанализа
в зависимости от информации, которой обладает криптоаналитик. Самым слож-
ным из всех представленных в таблице является случай, когда в распоряжении
криптоаналитика есть только шифрованный, текст. Иногда бывает неизвестен
даже алгоритм шифрования, но в основном можно предполагать, что алгоритм
шифрования противник знает. При этих условиях один из возможных подходов
криптоанализа заключается в простом переборе всех возможных вариантов клю-
чей. Однако, если пространство возможных ключей очень велико, такой подход
становится нереальным. Поэтому противнику приходится больше полагаться на
анализ самого шифрованного текста, что, как правило, означает выявление ста-
тистических особенностей такого текста. Для этого противник должен иметь не-
которые общие предположения о содержимом открытого сообщения, например,
о том, что текст написан на английском или французском языке, что это испол-
няемый файл MS DOS, что это исходный код программы на языке Java, что это
файл с информацией о банковских счетах и т.п.
Таблица 2.1. Типы криптоанализа шифрованных сообщений
Тип криптоанализа Данные, известные криптоаналитику
Анализ только шиф- • Алгоритм шифрования
рованного текста • Подлежащий расшифровке шифрованный текст
Анализ с известным • Алгоритм шифрования
открытым текстом • Подлежащий расшифровке шифрованный текст • Одна или несколько пар соответствующих фрагментов откры- того и шифрованного текста, созданного с помощью одного секретного ключа
Анализ с избранным • Алгоритм шифрования
открытым текстом • Подлежащий расшифровке шифрованный текст • Выбранный криптоаналитиком открытый текст и соответст- вующий шифрованный текст, созданный с помощью одного секретного ключа
44
Часть I. Криптография
Окончание табл. 2.1
Тип криптоанализа Данные, известные криптоаналитику
Анализ с избранным шифрованным текстом • Алгоритм шифрования • Подлежащий расшифровке шифрованный текст • Выбранный криптоаналитиком шифрованный текст и соот- ветствующий открытый текст, дешифрованный с помощью одного секретного ключа
Анализ с избранным текстом • Алгоритм шифрования • Подлежащий расшифровке шифрованный текст • Выбранный криптоаналитиком открытый текст и соответст- вующий шифрованный текст, созданный с помощью одного секретного ключа • Выбранный криптоаналитиком шифрованный текст и соот- ветствующий открытый текст, дешифрованный с помощью одного секретного ключа
При наличии у противника только шифрованного текста его атакам проти-
востоять легче всего, так как в этом случае объем имеющейся у него информа-
ции минимален. Однако довольно часто аналитику бывает известно больше. Не-
редко такой специалист имеет возможность перехватить одно или нескольких
открытых сообщений вместе с соответствующими им шифрованными текстами.
Или же аналитик может знать о том, что в сообщении обязательно должны при-
сутствовать те или иные наборы символов. Например, файл в формате PostScript
всегда начинается одной и той же последовательностью символов, в файле может
присутствовать стандартный заголовок или идентификатор сообщения об элек-
тронном переводе денег и т.п. Все это примеры известного открытого текста.
Владея подобной информацией, аналитик может восстановить ключ шифрования
на основе логических умозаключений и знания того, каким образом преобразо-
вывался известный открытый текст.
Родственной по отношению к задаче криптоанализа с известным открытым
текстом является задача криптоанализа с вероятно известным текстом. Если
противник вообще не имеет представления о теме сообщения, ему будет трудно
решить, в каком направлении вести поиск. Однако, если он знает какую-то спе-
цифичную информацию о содержимом сообщения, часть сообщения может ока-
заться для него с большой вероятностью известной. Например, если известно,
что пересылаемый файл содержит информацию о банковских счетах, противник
может угадать расположение определенных слов в заголовке этого файла. А ис-
ходный код программы, созданной некоторой компанией, может содержать ин-
формацию об авторских правах, для которой компания в своих программах мо-
жет всегда выбирать одну и ту же позицию.
Если аналитик сможет тем или иным способом получить доступ к сис-
теме, генерирующей сообщения, чтобы пропустить через нее выбранное им
сообщение, то он получит возможность провести криптоанализ с избранным
открытым текстом. В общем случае, если криптоаналитик имеет возмож-
ность по своему усмотрению выбирать сообщение и шифровать его, то при
правильном выборе сообщений для шифрования он может вполне оправданно
надеяться разгадать ключ.
Глава 2. Традиционное шифрование и конфиденциальность
45
В табл. 2.1 упоминаются еще две разновидности криптоанализа: анализ
с избранным шифрованным текстом и анализ с избранным текстом. Они ис-
пользуются реже, но в арсенале криптоаналитика тоже представляются тео-
ретически возможными.
Лишь относительно слабые алгоритмы могут быть взломаны при анализе
только шифрованного текста. В общем случае при разработке любого алгоритма
шифрования ставится задача обеспечить его стойкость к попыткам анализа с из-
вестным открытым текстом.
Здесь уместно дать следующее определение. Схема шифрования называется
защищенной по вычислениям, если она удовлетворяет хотя бы одному из сле-
дующих критериев защищенности.
• Стоимость взлома шифра превышает стоимость зашифрованной информации.
• Время, которое требуется для взлома шифра, превышает время, в течение
которого информация актуальна.
Проблема заключается в том, что весьма непросто количественно оценить те
усилия, которые необходимы для успешного криптоанализа шифрованного тек-
ста, созданного на основе данной конкретной схемы шифрования. Однако, пред-
полагая, что в алгоритме нет внутренних математических дефектов, в качестве
меры стойкости можно выбрать простой перебор всех ключей, поскольку для не-
го можно получить достаточно надежные оценки времени и стоимости.
Перебор всех вариантов ключей заключается в проверке каждого из воз-
можных ключей до тех пор, пока из шифрованного текста не будет получен
какой-нибудь вразумительный открытый текст. В среднем для этого нужно пе-
ребрать примерно половину всех ключей. В табл. 2.2 показано, сколько време-
ни уйдет на перебор в зависимости от длины ключа. Ключи 56-битовой длины
используются в алгоритме DES (Data Encryption Standard — стандарт шифро-
вания данных). Время оценивается исходя из предположения, что на одну по-
пытку расшифровки уходит 1 |1с (что является вполне реальным для совре-
менных компьютеров). При использовании машин с параллельной архитекту-
рой можно достичь гораздо лучших показателей, поэтому в последнем столбце
табл. 2.2 приведены результаты некоторой гипотетической системы, которая в
состоянии проверить 1 миллион ключей за 1 |1с. Как видно из таблицы, при
такой производительности алгоритм DES уже нельзя считать защищенным по
вычислениям.
Таблица 2.2. Среднее время анализа при простом переборе ключей
Длина ключа, бит Число различных ключей Необходимое время при скорости 1 шифрование/цс Необходимое время при скорости 10е шифрований/цс
32 232 = 4,3 х 109 231 рс = 35,8 мин. 2,15 мс
56 256 = 7,2 х 1016 255 цс = 1142 года 10 часов
128 2128 = 3,4 х 1038 2127 рс = 5,4 х 1024 лет 5,4 х 1018 лет
168 2168 = 3,7 х 1О50 2167 рс = 5,9 х 1036 лет 5,9 х 103° лет
46
Часть I. Криптография
Структура шифра Файстеля
Практически все алгоритмы традиционного блочного шифрования, включая
Г Z.S, имеют структуру, впервые описанную специалистом из IBM Хорстом Фай-
‘тггм (Horst Feistel) в 1973 году [FEIS73J. Соответствующая схема показана на
:: 2.2. На вход алгоритма шифрования подается блок открытого текста дли-
й 2 i бит и ключ К. Блок открытого текста разделяется на две равные части,
Ro , которые последовательно проходят п раундов обработки, а затем объе-
пяются снова для получения блока шифрованного текста соответствующей
.- Для раунда i в качестве входных данных выступают и R,_i, полу-
£=ые на выходе предыдущего раунда, и подключ К,, вычисляемый по общему
-: -:у К. В общем случае все подключи К,- отличаются как от общего ключа К,
и друг от друга.
Все раунды обработки проходят по одной и той же схеме. Сначала для ле-
;::: половины блока данных выполняется операция подстановки. Она заключа-
= в применении к правой половине блока данных некоторой функции раунда
п последующем сложении полученного результата с левой половиной блока
_,-:ь:х с помощью операции XOR (исключающее “ИЛИ”). Для всех раундов
: :-::-:ция раунда имеет одну и ту же структуру, но зависит от параметра — под-
-:ча раунда К,-. После подстановки выполняется перестановка, представляю-
_ 1 собой обмен местами двух половин блока данных.
Практическая реализация схемы Файстеля зависит от конструктивных осо-
-т.-гостей и выбора значений для следующих параметров.
• Размер блока. Чем больше размер блока, тем выше надежность шифра (при
прочих равных условиях), но ниже скорость выполнения операций шифро-
вания и дешифрования. Разумным компромиссом является 64-битовый
блок. Блоки именно такого размера используют почти все современные
блочные шифры.
• Длина ключа. Чем длиннее ключ, тем выше надежность шифра, но с уве-
личением длины ключа скорость шифрования и дешифрования замедляет-
:я. В современных алгоритмах обычно используются 128-битовые ключи.
• Число раундов обработки. Суть идеи шифра Файстеля в том, что за один
саунд обработки данных обеспечивается недостаточно высокая надежность
лгифрования, но стойкость шифра повышается с каждым новым раундом.
Дак правило, число раундов выбирают равным 16.
• Алгоритм вычисления подключей. Чем сложнее этот алгоритм, тем труднее
г- риптоанализ шифра.
Функция раунда. Здесь, опять же, усложнение, как правило, повышает
"гйкость шифра с точки зрения криптоанализа.
л того, существуют еще два фактора, которые приходится принимать во
при построении любой реализации шифра Файстеля.
• Скорость выполнения программ шифрования/дешифрования. Часто функ-
_r::i шифрования встраиваются в приложения или утилиты, чтобы избежать
- -сходимости аппаратной реализации шифрования. В таких случаях важ-
-л.м фактором оказывается скорость выполнения алгоритма.
1 2. Традиционное шифрование и конфиденциальность 47
Шифрованный текст (2к бит)
Рис. 2.2. Классическая схема Файстеля
• Простота анализа. Хотя целью является создание максимально сложного алго-
ритма, все же весьма выгодно, чтобы сам такой алгоритм оставался простым
для понимания. Иными словами, если алгоритм прост и понятен, его легче
анализировать с точки зрения уязвимости и, следовательно, легче совершенст-
вовать с целью достижения более высокого уровня надежности. Алгоритм DES,
например, нельзя отнести к алгоритмам, слишком простым для анализа.
Процесс дешифрования Файстеля принципиально не отличается от процесса
шифрования. Применяется тот же алгоритм, но на вход подается шифрованный
текст, а подключи К, используются в обратной последовательности: для первого
раунда берется подключ Кя , для второго — и так далее, пока не будет вве-
48
Часть I. Криптография
ден ключ Kj для последнего раунда. Такое свойство этой схемы шифрования
оказывается очень удобным, так как для дешифрования не требуется вводить
второй алгоритм, отличный от алгоритма шифрования.
2.2. АЛГОРИТМЫ ТРАДИЦИОННОГО
ШИФРОВАНИЯ
Почти все широко используемые сегодня алгоритмы симметричного шифро-
вания являются блочными шифрами. Блочный шифр обрабатывает вводимый
открытый текст блоками фиксированной длины и для каждого блока открытого
текста порождает соответствующий блок шифрованного текста той же длины.
Двумя наиболее важными алгоритмами традиционной схемы шифрования явля-
ются блочные шифры DES (Data Encryption Standard — стандарт шифрования
данных) и TDEA (Triple Data Encryption Algorithm — алгоритм тройного шиф-
рования данных). Мы рассмотрим оба эти алгоритма, а также планируемый на
роль стандарта алгоритм AES (Advanced Encryption Standard — усовершенство-
ванный стандарт шифрования). Затем будет проведено краткое обсуждение дру-
гих популярных алгоритмов традиционной схемы шифрования.
Стандарт шифрования данных (DES)
Самая популярная современная схема шифрования определяется стан-
дартом DES (Data Encryption Standard — стандарт шифрования данных),
принятым в 1977 году Национальным бюро стандартов (NBS) США, теперь
называемым Национальным институтом стандартов и технологии (NIST).
Этот стандарт получил официальное название Federal Information Processing
Standard 46 (FIPS PUB 46). В 1994 году NIST подтвердил использование DES
в качестве федерального стандарта еще на пять лет в документе FIPS
PUB 46-2. Сам алгоритм называется алгоритмом DEA (Data Encryption Algo-
rithm — алгоритм шифрования данных).2
Описание алгоритма
Общая схема процесса шифрования DES показана на рис. 2.3. Как и в
любой схеме шифрования, здесь на вход функции шифрования подается два
типа данных — открытый текст, который требуется зашифровать, и ключ. В
данном случае длина открытого текста предполагается равной 64 бит, а дли-
на ключа — 56 бит.
2 Используемая терминология немного запутана. До недавнего времени термины
DES и DEA были взаимозаменяемы. Однако в самое последнее издание документации
DES были включены спецификации и алгоритма DEA, описываемого здесь, и “тройного”
УЕА (TDEA), рассматриваемого в этой же главе ниже. И DEA, и TDEA являются ча-
~.ью стандарта шифрования данных. Кроме того, до недавнего принятия официального
- -у.ча “TDEA” алгоритм “тройной” DEA назывался “тройным” DES и сокращенно
л" - г - 2.7 с я 3DES.
.2 3. 2. Традиционное шифрование и конфиденциальность 49
64-битовый блок
открытого текста
С'у
у...—.....Л
Начальная I
перестановка J
56-битовый ключ
л...............t
Первая перестановка
с выбором
Вторая перестановка
с выбором
Циклический
сдвиг влево
Вторая перестановка
с выбором
Циклический
сдвиг влево
64-битовый блок
шифрованного текста
Рис. 2.3. Общая схема алгоритма шифрования DES
Из левой части рис. 2.3 видно, что процесс преобразования открытого тек-
ста состоит из трех этапов. Сначала 64-битовый блок открытого текста поступает
для обработки на вход начальной перестановки (IP). Затем следует этап, состоя-
щий из 16 итераций одной и той же функции. На выходе последней (16-й) ите-
рации получается 64-битовая последовательность, являющаяся некоторой функ-
цией открытого текста и ключа. Левая и правая половины полученной последо-
вательности данных меняются местами, образуя предрезультат. Наконец, этот
предрезультат проходит через перестановку IP1 , обратную начальной, и получа-
ется 64-битовый блок шифрованного текста.
В правой части рис. 2.3 показано, каким образом используется 56-битовый
ключ. Сначала к ключу тоже применяется функция перестановки. Затем для
каждой из 16 итераций из полученного результата с помощью циклического
50
Часть I. Криптография
сдвига влево и некоторой перестановки генерируется подключ (К,). Функция пе-
рестановки одна и та же для всех итераций, но генерируемые подключи оказы-
ваются разными из-за того, что в результате циклического сдвига на ее вход по-
ступают разные биты ключа.
На рис. 2.4 показана внутренняя структура алгоритма, используемого при ите-
рациях. Преобразованное с помощью перестановки частей 64-битовое входное значе-
ние проходит через 16 итераций преобразования, на каждой из которых получается
промежуточное 64-битовое значение. Левая (L) и правая (R) половины каждого 64-
битового значения рассматриваются как независимые 32-битовые величины. Опера-
ции, выполняемые на каждой итерации, можно записать в виде формул
L/=R,-i,
R,=Li_1®F(R,_1,Ki),
где ® обозначает операцию XOR (побитовое исключающее “ИЛИ”).
Рис. 2.4. Один раунд шифрования алгоритма DES
Таким образом, левая часть значения вывода итерации (L, ) равна правой
части значения ввода для этой итерации (R;_j). Правая часть значения вывода
(R, ) представляет собой результат связывания операцией XOR значений L(_] и
сложной функции F от R1_1 и К;. Эта сложная функция предполагает использо-
вание операций как перестановки, так и подстановки. Операция подстановки,
представляемая в виде таблиц, называемых кодирующими матрицами (или
Глава 2. Традиционное шифрование и конфиденциальность
51
S-матрицами), отображает каждую комбинацию 48 бит ввода в соответствующий
32-битовый набор.
Возвращаясь к рис. 2.3, заметим, что 56-битовые ключи, используемые
в качестве входных данных алгоритма, сначала преобразуются с помощью
перестановки. Полученное в результате 56-битовое значение рассматривается
как комбинация двух 28-битовых значений, для которых используются обо-
значения Со и Do. На каждой итерации к значениям С и D по отдельности
применяются операции циклического сдвига влево (вращения) на 1 или 2
бит. Полученные после сдвига значения поступают на вход следующей ите-
рации, а также подаются на вход второй функции перестановки, с помощью
которой получается 48-битовое выходное значение, подаваемое на вход
функции F(R,_1,K().
Процесс дешифрования DES по сути аналогичен процессу шифрования.
Правило здесь следующее: в качестве ввода алгоритма DES используется шифро-
ванный текст, а ключи К, применяются в обратном порядке, т.е. К16 использу-
ется на первой итерации, К15 — на второй и так далее, вплоть до использования
К] на последней, шестнадцатой, итерации.
Надежность DES
Вопрос надежности DES складывается из двух частей — вопроса о на-
дежности самого алгоритма и вопроса о достаточности 56-битового ключа. За
многие годы предпринимались неоднократные попытки обнаружить и ис-
пользовать слабые места этого алгоритма, что превратило DES в наиболее
изученный изо всех когда-либо существовавших алгоритмов шифрования.
Но, несмотря на эти многочисленные попытки, обнаружить существенные
недостатки DES не удалось никому.3
Более серьезные опасения вызывает длина ключа. Еще в конце 70-х
эксперты предупреждали, что дни DES как надежного алгоритма сочтены, и
лишь вопросом времени является создание достаточно быстрых и достаточно
дешевых процессоров, позволяющих осуществить быстрый взлом DES с по-
мощью простого перебора возможных вариантов. О “смерти пациента” было
объявлено в июле 1998 года, когда группа EFF (Electronic Frontier Founda-
tion) сообщила о взломе DES с помощью специализированной “машины для
взлома DES” стоимостью менее $250000. Для успешного завершения атаки
потребовалось менее 3-х дней. В публикации содержалось подробное описа-
ние машины, что давало возможность строить подобные машины кому угод-
но [EFF98]. Ясно, что с ростом скоростей процессоров стоимость создания
подобных машин будет уменьшаться, что в конце концов сделает DES прак-
тически бесполезным.
Важно отметить, что для атаки поиска ключа перебор всех вариантов
ключей является не единственной проблемой. Когда известного открытого
текста нет, аналитик должен иметь возможность распознать дешифрованное
сообщение как открытый текст. Если дешифрованное сообщение представля-
ет собой обычный текст (например, на английском языке), эта задача реша-
ется просто (хотя еще и требуется автоматизировать сам процесс распознава-
3 Во всяком случае никто публично о подобном открытии не заявил,
5.9
Часть I. Криптография
=ия). Но если текстовое сообщение перед шифрованием было каким-либо об-
разом сжато, задача распознавания открытого текста усложняется. А если
:: общение представляет собой числовые данные более общего вида, которые
твред шифрованием были еще и сжаты, то проблема автоматизации распо-
знавания текста становится совсем сложной. Поэтому для перебора всех воз-
•южных вариантов требуется некоторая информация о том, что может пред-
юавлять собой открытый текст, и необходимы технические средства, помо-
гающие автоматически распознать дешифрованное сообщение как открытый
_в:-:ст, а не отбросить его, как мусор. Подход EFF предусматривает решение
зз злобных проблем, предлагая автоматизированные технологии, оказываю-
щиеся эффективными во многих случаях.
Можно сделать следующие выводы. Если единственной возможностью
лея атаки является перебор всех вариантов, то противодействие такой атаке
:-завидно — использовать более длинные ключи. Чтобы получить представ-
ление о том, какая длина ключа необходима, приведем некоторые оценки,
для которых в качестве отправной точки рассматривалось использование
взломщика” EFF. “Взломщик” EFF является прототипом, на основе которо-
гз современные технологии позволяют создать быструю и достаточно деше-
еую машину. Если предположить, что такой “взломщик” сможет выполнять
здин миллион операций дешифрования в микросекунду (что предполагается
в табл. 2.2), то для взлома DES потребуется всего 10 часов. Это примерно в 7
:=з быстрее результата, объявленного EFF. На рис. 2.5 показана зависимость
времени взлома алгоритма типа DES от длины используемого ключа. Так,
три использовании 128-битовых ключей, которые типичны для современных
алгоритмов, “взломщику” EFF для взлома шифра потребуется более 1018лет.
Z даже если удастся увеличить скорость работы в 1 триллион раз (1012), на
взлом такого шифра потребуется не менее миллиона лет. Поэтому 128-
готовую длину ключа можно считать гарантией того, что соответствующий
алгоритм окажется стойким к перебору всех вариантов ключей.
К счастью, на рынке средств шифрования имеется немало альтернативных
предложений, составляющих конкуренцию алгоритму DES. Ниже мы рассмот-
зим наиболее популярные из них.
. лава 2. Традиционное шифрование и конфиденциальность
53
Длина ключа в битах
Рис. 2.5. Время, требующееся для взлома шифра (при выполнении
106 шифрований/усек)
“Тройной” DEA
Использовать “тройной” DEA (TDEA) предложил Тачман (Tuchman)
[TUCH79], а в качестве стандарта для финансовых приложений этот алгоритм
был впервые представлен в документе Х9.17 ANSI в 1985 году. Алгоритм TDEA
явился одной из составляющих стандарта шифрования данных 1999 года, опуб-
ликованного в документе FIPS PUB 46-3. В алгоритме TDEA используются три
ключа и трижды применяется алгоритм DES. Функция, обеспечивающая после-
довательность шифрования-дешифрования-шифрования, оказывается следующей
(рис. 2.6, а)'.
C = EK3[DK2[EKi[P]]],
где
С — шифрованный текст,
Р — открытый текст,
ЕК[Х] — шифрование X с использованием ключа К,
DK[Y] — дешифрование Y с использованием ключа К.
54
Часть I. Криптография
Дешифрование представляет собой ту же операцию, выполняемую с ключа-
ми в обратном порядке (рис. 2.6, б):
P-DKi[EK2[DK2[C]]].
а) шифрование
б) дешифрование
Рис. 2.6. “Тройной" DEA
То, что на второй стадии используется операция дешифрования, не сущест-
венно с точки зрения шифрования, но это дает возможность пользователям
TDEA расшифровывать данные, зашифрованные пользователями более старой,
обычной версии DES:
C=EKi[DKi[EKi[P]]] = EKi[P],
При использовании трех разных ключей длина ключа TDEA оказывается
равной 168 бит. Документ FIPS 46-3 допускает также использование двух клю-
чей, когда К] = К3 , в результате чего общая длина ключа оказывается равной
112 бит. В FIPS 46-3 содержатся следующие рекомендации, касающиеся TDEA.
• TDEA является алгоритмом традиционной схемы шифрования, рекомен-
дуемым FIPS.
• Использование оригинального алгоритма DEA с 56-битовым ключом допус-
кается только в уже действующих системах. Новые разработки должны
поддерживать TDEA.
• Правительственным организациям, применяющим системы на основе DEA,
настоятельно рекомендуется перейти к использованию TDEA.
• Ожидается, что TDEA и новый стандарт AES (Advanced Encryption Stan-
dard — усовершенствованный стандарт шифрования) будут сосуществовать
в качестве рекомендуемых FIPS алгоритмов одновременно, что позволит
осуществить плавный переход к AES.
Очевидно, TDEA является достаточно грозным алгоритмом. Поскольку в его
основе лежит DEA, в отношении TDEA можно декларировать уровень крипто-
Глава 2. Традиционное шифрование и конфиденциальность
55
стойкости, присущий DEA. А 168-битовая длина ключа гарантирует, что атаки
простого перебора ключей окажутся практически неэффективными.
Можно ожидать, что популярность TDEA в ближайшие годы будет расти,
поскольку ограничения DES становятся неприемлемыми, а готового к полно-
масштабному применению варианта AES все еще нет.
Усовершенствованный стандарт шифрования (AES)
Алгоритм TDEA имеет две привлекательные особенности, обеспечивающие
ему перспективы широкого распространения в течение ближайших нескольких
лет. Во-первых, этот алгоритм использует 168-битовые ключи, что позволяет, в
отличие от DEA, не опасаться атак, предполагающих перебор всех вариантов
ключей. Во-вторых, в TDEA используется тот же алгоритм, что и в DEA. Этот
алгоритм подвергся более тщательной и более длительной проверке по сравне-
нию с любым другим алгоритмом шифрования, и для него не было обнаружено
ни одного способа атаки, по эффективности более выгодного, чем простой пере-
бор всех ключей. Соответственно, степень стойкости TDEA в отношении крип-
тоанализа достаточно высока. Если бы требовалось учитывать только защищен-
ность, алгоритм TDEA мог бы выступить в качестве стандарта алгоритма шиф-
рования на многие десятилетия.
Принципиальным недостатком TDEA является то, что этот алгоритм оказы-
вается весьма медленным в условиях программной реализации. Оригинальный
алгоритм DEA был разработан в середире 70-х для реализации в виде микросхе-
мы, а не эффективного программного кода. А алгоритм TDEA, в котором число
раундов шифрования оказывается в три раза больше, чем в DEA, соответственно
оказывается еще более медленным. Вторым недостатком является то, что и DEA,
и TDEA используют 64-битовые блоки, а с точки зрения и эффективности, и за-
щищенности, было бы предпочтительнее использовать блоки большей длины.
Из-за этих двух недостатков TDEA не выглядит реальным кандидатом на
роль долгосрочного стандарта. В 1997 году NIST (National Institute of Standards
and Technology — Национальный институт стандартов и технологий США) объя-
вил прием предложений, касающихся создания нового усовершенствованного
стандарта шифрования (AES), который должен иметь стойкость не меньше, чем
TDEA, но быть существенно более эффективным. В дополнение к этим общим
требованиям, NIST выдвигает требование, чтобы AES был симметричным блоч-
ным шифром с длиной блока в 128 бит, поддерживающим использование 128-,
192- и 256-битовых ключей. Критерии оценки качества включают вопросы за-
щищенности и вычислительной эффективности, требования к памяти, возмож-
ность программной и аппаратной реализации, а также гибкость.
На первом этапе оценки было выделено 15 из предложенных алгоритмов.
Второй этап сузил круг рассмотрения до 5 алгоритмов. На момент написания
данной книги NIST планировал завершить процесс оценки и определить стан-
дарт к середине 2001 года. Процесс практического принятия этого стандарта
рынком может затянуться еще на несколько лет.
Другие симметричные блочные шифры
Вместо того, чтобы вновь “изобретать колесо”, практически все современные
алгоритмы традиционной схемы блочного шифрования используют структуру Фай-
56
Часть I. Криптография
стеля. Причина заключается в том, что эта структура хорошо изучена и ее использо-
вание позволяет упростить процесс оценки криптографической стойкости соответст-
вующего алгоритма. Совершенно новая структура может иметь скрытые недостатки,
которые разработчик может сначала не заметить. В этом разделе мы рассмотрим не-
которые другие шифры, которые получили коммерческое распространение наряду с
DES и TDEA. Их основные характеристики сравниваются в табл. 2.3.
Таблица 2.3. Алгоритмы традиционной схемы шифрования
Алгоритм Длина ключа Число раундов шифрования Математические операции Приложения
DES 56 бит 16 XOR, фиксированные S-матрицы SET, Kerberos
“Тройной” DES 112 или 168 бит 48 XOR, фиксированные S-матрицы Управление ключами в фи- нансовой сфере, PGP, S/MIME
IDEA 128 бит 8 XOR, сложение, ум- ножение PGP
Blowfish Изменяемая, до 448 бит 16 XOR, переменные S-матрицы, сложение
RC5 Изменяемая, до 2048 бит Изменяемое, до 255 Сложение, вычита- ние, XOR, вращение
CAST-128 От 40 до 128 бит 16 Сложение, вычита- ние, XOR, вращение, фиксированные S-матрицы PGP
IDEA
Алгоритм IDEA (International Data Encryption Algorithm — международный
алгоритм шифрования данных) представляет собой симметричный блочный
шифр. Его разработали сотрудники Швейцарского федерального института тех-
нологий (Swiss Federal Institute of Technology) Сюдзя Лай (Xuejia Lai) и Джеймс
Массей (James Massey) в 1991 году [LAI91], В IDEA используется 128-битовый
ключ. Алгоритм IDEA существенно отличается от DES и функцией раунда, и
функцией генерирования подключей. Функция раунда в IDEA строится на ис-
пользовании не S-матриц, а трех разных математических операций: XOR, поби-
тового сложения и побитового умножения 16-битовых целых чисел. Эти опера-
ции комбинируются таким образом, чтобы в результате получилось сложное
преобразование, вызывающее большие трудности для анализа вообще и крип-
тоанализа в частности. Алгоритм генерирования подключей строится исключи-
тельно на использовании циклических сдвигов для получения шести подключей
для каждого из восьми раундов IDEA.
Поскольку алгоритм IDEA явился одной из первых альтернатив DES, исполь-
зующей 128-битовые ключи, он подвергся тщательному анализу и до сих пор счита-
ется исключительно стойким. Алгоритм IDEA используется в PGP (в качестве одной
из альтернатив), а также в целом ряде коммерческих приложений.
Глава 2. Традиционное шифрование и конфиденциальность 57
Blowfish
Алгоритм Blowfish был разработан в 1993 году Брюсом Шнайером (Bruce
Schneier) [SCHN93, SCHN94], независимым консультантом и специалистом по
криптографии, и быстро завоевал популярность как одна из альтернатив DES.
При разработке Blowfish одной из поставленных целей было обеспечить простоту
реализации и высокую скорость выполнения алгоритма. Этот алгоритм также
довольно компактен и требует для выполнения менее 5 Кбайт памяти. Интерес-
ной особенностью Blowfish является переменная длина ключа, которая может
достигать 448 бит. На практике используются 128-битовые ключи. В алгоритме
Blowfish используется 16 раундов шифрования.
В Blowfish, как и в DES, используются S-матрицы и операции XOR, но,
кроме того, выполняется операция побитового сложения. В отличие от DES, где
S-матрицы фиксированы, в Blowfish используются динамические S-матрицы, ге-
нерируемые в зависимости от значений ключа. В Blowfish подключи и S-
матрицы генерируются с помощью повторного применения самого алгоритма
шифрования Blowfish к данному ключу. В целом для генерирования подключей
и S-матриц требуется применить алгоритм Blowfish 521 раз. Соответственно
Blowfish оказывается неподходящим для приложений, в которых секретный
ключ меняется часто.
Blowfish является одним из наиболее впечатляющих алгоритмов традици-
онной схемы шифрования, поскольку в нем и ключи, и S-матрицы строятся пу-
тем последовательного применения самого алгоритма, что в результате сильно
перемешивает биты и делает криптоанализ исключительно трудным делом. На
сегодня имеется лишь несколько публикаций, касающихся криптоанализа Blow-
fish, но о практических недостатках Blowfish в них не сообщается.
Blowfish используется в целом ряде коммерческих приложений.
RC5
Алгоритм RC5 был разработан в 1995 году Роном Райвестом (Ron Rivest)
[RIVE94, RIVE95], одним из авторов алгоритма RSA (шифрования с открытым
ключом). RC5 определяется в документе RFC 2040, и при разработке RC5 стави-
лась задача достижения следующих характеристик.
• Пригодность для аппаратной и программной реализации. В RC5 использу-
ются только элементарные вычислительные операции, обычно применяемые
в микропроцессорах.
• Скорость выполнения. RC5 является простым алгоритмом, предполагаю-
щим работу с данными длиной в одно машинное слово. Все основные опе-
рации RC5 предусматривают работу с данными длиной в одно слово.
• Адаптация к процессорам с разной длиной машинного слова. Длина слова
в битах является параметром RC5 — при изменении длины слова меняется
алгоритм.
• Изменяемое число раундов. Число раундов является вторым параметром
RC5. Этот параметр позволяет выбрать оптимальное соотношение скорости
работы и степени защиты.
58
Часть I. Криптография
• Изменяемая длина ключа. Длина ключа представляет третий параметр
RC5. Этот параметр позволяет найти приемлемый компромисс между ско-
ростью работы и обеспечиваемой степенью защиты.
• Простота. Структура RC5 очень проста не только для реализации, но и для
оценки ее криптостойкости.
• Низкие требования к памяти. Низкие требования к памяти делают RC5
пригодным для использования в смарт-картах и других подобных устройст-
вах с ограниченным объемом памяти.
• Высокая степень защиты. RC5 призван обеспечить высокую степень защи-
ты при условии выбора соответствующих значений параметров.
• Зависимость циклических сдвигов от данных. В RC5 используются враще-
ния (циклические сдвиги битов), зависящие от данных, что должно повы-
шать криптостойкость алгоритма.
Алгоритм RC5 используется в целом ряде продуктов компании RSA Data
Security, Inc.
CAST-128
CAST представляет собой процедуру построения алгоритмов симметричного
шифрования, разработчиками которой являются Карлайл Адамс (Carlisle Adams) и
Стаффорд Таварес (Stafford Tavares) из Entrust Technologies [ADAM97]. Одним из
алгоритмов, созданных в рамках общего проекта CAST, является алгоритм CAST-
128, описание которого предлагается в документе RFC 2144. В CAST-128 допускает-
ся использование ключей длиной от 40 до 128 бит с шагом в 8 бит. Технология
CAST явилась результатом длительного процесса исследований и усовершенствова-
ний под пристальным вниманием специалистов-криптологов. В настоящее время эта
технология уже применяется в ряде продуктов, одним из которых является PGP.
CAST использует фиксированные S-матрицы, но по размерам они значи-
тельно больше, чем матрицы, применяемые в алгоритме DES. Эти S-матрицы
были специально подобраны таким образом, чтобы обеспечить сильную нелиней-
ность и достаточную стойкость в отношении криптоанализа. Процесс генериро-
вания подключей CAST-128 отличается от подобных процессов, используемых в
других алгоритмах. Разработчики CAST ставили задачу обеспечить максималь-
ную стойкость подключей в отношении криптоанализа и сочли, что эта задача
решается путем использования сильно нелинейных S-матриц при генерировании
подключей из главного ключа. Другой интересной особенностью CAST-128 явля-
ется использование для каждого раунда разных функций раунда F, что тоже по-
вышает криптостойкость алгоритма.
2.3. РЕЖИМЫ БЛОЧНОГО ШИФРОВАНИЯ
Симметричный блочный шифр обрабатывает блоки данных по одному. В
DEA и TDEA длина блока равна 64 бит. Для более длинных фрагментов откры-
того текста необходимо разбить текст на блоки по 64 бит (дополнив последний
элок битами заполнителя, если это необходимо). Простейшим способом даль-
нейшей обработки является процедура, называемая режимом электронной шиф-
ровальной книги (режим ЕСВ), когда открытый текст обрабатывается блоками
Глава 2. Традиционное шифрование и конфиденциальность 59
по 64 бит и каждый блок шифруется одним и тем же ключом. Термин шифро-
вальная книга объясняется тем, что при заданном ключе каждый 64-битовый
блок открытого текста представляется уникальным блоком шифрованного тек-
ста. Такое соответствие вызывает аналогию с гигантской шифровальной книгой,
в которой для каждой 64-битовой последовательности открытого текста указана
соответствующая последовательность шифрованного текста.
Если в режиме ЕСВ в сообщении присутствуют одинаковые 64-битовые блоки
открытого текста, в шифрованном тексте они тоже будут представляться одинако-
выми блоками. Поэтому при передаче достаточно длинных сообщений режим ЕСВ
может не обеспечивать необходимый уровень защиты. Если сообщение имеет явно
выраженную структуру, у криптоаналитика появляется возможность использовать
регулярности текста. Например, если известно, что в начале сообщения всегда раз-
мещается определенный заголовок, криптоаналитик может получить в свое распо-
ряжение целый набор соответствующих пар блоков открытого и шифрованного тек-
ста. Если же сообщение содержит повторяющиеся элементы с периодом повторения,
кратным 64 бит, такие элементы тоже могут быть выявлены аналитиком. Подобные
сведения упрощают задачу криптоанализа и открывают возможность замещения или
реорганизации блоков текста передаваемого сообщения.
Технология, свободная от недостатков режима ЕСВ, должна в случае повто-
рения в сообщении уже встречавшегося ранее блока открытого текста генериро-
вать блок шифрованного текста, отличный от сгенерированного ранее. В этом
разделе мы рассмотрим два режима, являющиеся общепризнанными альтерна-
тивами режиму ЕСВ.
Режим сцепления шифрованных блоков
В режиме сцепления шифрованных блоков (режим СВС) значение, подаваемое
на вход алгоритма шифрования, задается равным XOR-разности текущего блока от-
крытого текста и полученного на предыдущем шаге блока шифрованного текста, и
для всех блоков используется один и тот же ключ (рис. 2.7). В результате в процессе
шифрования все блоки открытого текста оказываются связанными, а входные дан-
ные, поступающие на вход функции шифрования, уже зависят не только от текуще-
го блока шифруемого открытого текста. Поэтому повторяющиеся 64-битовые после-
довательности в шифрованном тексте не проявляются.
При дешифровании текст тоже проходит через алгоритм дешифрования по-
блочно. При этом соответствующий блок открытого текста получается как XOR-
разность выходного блока алгоритма дешифрования и предыдущего блока шиф-
рованного текста. Чтобы понять, как это происходит, запишем процесс шифро-
вания в виде формулы
С,=ЕК[С,_1®1’],
где ЕК[Х] обозначает шифрование блока открытого текста X с помощью ключа
К, а © — операцию XOR. Тогда
DK[C,] = DK[EK(C,_1©^)],
DK[C,] = (€,_! ФР,),
C,_i ©DK[C,] = C,_1 ©С,.! ©1>- = Р,,
что соответствует рис. 2.7, б.
60
Часть I. Криптография
б) дешифрование
Рис. 2.7. Режим сцепления шифрованных блоков (СВС)
Чтобы получить первый блок шифрованного текста, рассматривается XOR-
разность некоторого инициализационного вектора (IV) и первого блока открыто-
го текста. При дешифровании для восстановления первого блока открытого тек-
:та необходимо будет тоже выполнить операцию XOR по отношению к тому же
зектору IV и первому блоку на выходе алгоритма дешифрования.
Значение IV должно быть известно и отправителю, и получателю сообще-
ния. Для обеспечения максимальной безопасности значение IV должно быть за-
щищено точно так же, как и ключ. Можно, например, отправить значение IV,
зашифровав его в режиме ЕСВ. Одной из причин, по которым необходимо за-
щищать IV, является следующая: если противник сможет обмануть адресата со-
збщения, предоставив подложный IV, то противник получит возможность инвер-
тировать избранные биты в первом блоке открытого текста. Чтобы убедиться в
?том, рассмотрим следующие уравнения:
c^EKdvePj),
p^iveD^Cj).
Обозначив j-й бит 64-битового значения X через Х[/], получим
. лава 2. Традиционное шифрование и конфиденциальность
61
Pi[./] = IV[j]©Dk(C1)[j] .
Поэтому, используя свойства операции XOR, мы можем заключить, что
Pi[jl/ = IV[y]/®DK(C1)[7],
где штрих означает дополнение бита. Как видите, если противник имеет воз-
можность управляемым образом менять биты значения IV, он сможет поменять
и соответствующие значения Р1.
Как будет показано во второй части книги, режим СВС используется во
многих приложениях защиты.
Режим шифрованной обратной связи
Схема DES представляет собой блочный шифр с размером блока 64 бит. Но
DES можно преобразовать и в поточный шифр, используя режим шифрованной
обратной связи (CFB). Использование поточного шифра избавляет от необходи-
мости дополнять сообщение до целого числа блоков. Кроме того, с поточным
шифром можно работать в режиме реального времени. Например, при передаче
потока символов с помощью посимвольного поточного шифра каждый символ
можно шифровать и сразу же передавать адресату, не дожидаясь окончания
шифрования остальной части сообщения.
Одним из желательных свойств поточного шифра является точное соответ-
ствие длины шифрованного текста длине открытого. Поэтому при передаче 8-
битовых символов следует обратиться к 8-битовому шифрованию. Если исполь-
зовать шифрование блоками длиной более 8 бит, часть ресурсов канала передачи
данных будет расходоваться впустую.
На рис. 2.8 показана схема шифрования в режиме CFB. Предполагается,
что единицей передачи данных являются j битов (обычно j = 8). Как и в режиме
СВС, происходит сцепление элементов открытого текста, поэтому шифрованный
текст, соответствующий любому элементу открытого текста, будет зависеть от
всех предыдущих элементов открытого текста.
Сначала рассмотрим шифрование. На входе функции шифрования распо-
лагается 64-битовый регистр сдвига, в котором изначально размещается неко-
торое значение инициализационного вектора (IV). Крайние слева (главные) j
битов этого значения связываются операцией XOR с первой порцией открытого
текста Р], в результате чего получается первая порция шифрованного текста
С] , передаваемая в канал связи. Содержимое регистра сдвига смещается влево
на j битов, а в крайние справа (наименее значимые) j битов помещается значе-
ние Q . Затем весь процесс повторяется до тех пор, пока не будут зашифрова-
ны все элементы открытого текста.
Для дешифрования используется та же схема, но очередная порция от-
крытого текста вычисляется как XOR-разность полученной по связи порции
шифрованного текста и выходных данных функции шифрования. Обратите
внимание на то, что в данном случае используется функция шифрования, а не
дешифрования. Объяснить это просто. Обозначим крайние слева j битов значе-
ния X через S,(X). Тогда
c^p.es/EdV)),
62
Часть I. Криптография
и поэтому
p^es/Eav)).
Те же выкладки имеют место и для последующих шагов дешифрования.
а) шифрование
рМ
Р1 р2
б) дешифрование
Рис. 2.8. Режим ^битовой шифрованной обратной, связи (режим CFB)
₽м
2.4. РАЗМЕЩЕНИЕ СРЕДСТВ ШИФРОВАНИЯ
Наиболее эффективным и чаще всего используемым средством противодей-
ствия угрозам безопасности сети является шифрование. При использовании
шифрования необходимо решить, что именно следует шифровать и где размес-
Глава 2. Традиционное шифрование и конфиденциальность
63
тить средства шифрования. В общем случае для этого имеется два основных ва-
рианта: канальное и сквозное шифрование; их использование в сети с коммута-
цией пакетов показано на рис. 2.9.
УКП — узел коммутации пакетов
Рис. 2.9. Шифрование в сети с коммутацией пакетов
При канальном шифровании каждый уязвимый канал оборудуется устройства-
ми шифрования на обоих концах. Таким образом, весь поток данных в канале ока-
зывается защищенным. Хотя для этого в большой сети потребуется немало уст-
ройств шифрования, преимущества такого подхода очевидны. Одним из недостатков
является то, что сообщение должно дешифровываться каждый раз, проходя через
коммутатор пакетов, поскольку коммутатор должен прочитать адрес (номер вирту-
ального канала) в заголовке пакета, чтобы направить пакет по нужному адресу. По-
этому сообщение оказывается уязвимым в каждом коммутаторе. При использовании
общедоступных сетей с коммутацией пакетов пользователь не имеет никакой воз-
можности контролировать безопасность соответствующих узлов.
При сквозном шифровании процесс шифрования выполняется только в двух
конечных системах. Исходные данные шифруются в узле или терминале источ-
ника. Затем данные в шифрованном виде передаются без изменений через всю
сеть к терминалу или узлу адресата. Адресат использует тот же ключ, что и от-
правитель, и поэтому может дешифровать полученные данные. Эта схема кажет-
ся безопасной с точки зрения защиты от воздействий в канале связи или узлах
коммутации пакетов. Однако и у такого подхода есть слабое место.
Рассмотрим следующую ситуацию. Некоторый узел подключается к сети с
коммутацией пакетов по протоколу Х.25, открывает виртуальный канал связи с
другим узлом и готовится передать данные этому узлу с использованием сквоз-
ного шифрования. Данные передаются по такой сети в виде пакетов, состоящих
64
Часть I. Криптография
из заголовка и каких-то данных пользователя. Какую часть каждого пакета
должен шифровать узел-источник? Предположим, что узел шифрует весь пакет,
зключая заголовок. Но этого делать нельзя, так как, напомним, выполнить де-
шифрование сможет только узел-адресат. Узел коммутации пакетов получит
шифрованные данные, не сможет прочитать заголовок и поэтому не сумеет пере-
стать пакет дальше. Отсюда следует, что узел-источник должен шифровать
только ту часть пакета, которая содержит данные пользователя, и оставить заго-
ловок нетронутым.
Итак, при сквозном шифровании данные пользователя оказываются защи-
шенными, чего нельзя сказать о самом потоке данных, поскольку заголовки па-
кетов передаются в открытом виде. Чтобы достичь более высокого уровня за-
щищенности, необходима комбинация канального и сквозного шифрования, на-
пример, как показано на рис. 2.9.
При использовании обеих форм шифрования узел-источник шифрует порцию
пакета данных пользователя, используя ключ сквозного шифрования. Затем весь
пакет шифруется с помощью ключа канального шифрования. При движении пакета
по сети каждый коммутатор сначала дешифрует пакет с применением ключа шиф-
рования соответствующего канала, чтобы прочитать заголовок, а затем снова шиф-
рует весь пакет для передачи его по следующему каналу. Теперь весь пакет защищен
почти все время — за исключением времени, когда он находится в памяти коммута-
тора пакетов, где заголовок пакета оказывается открытым.
2.5. РАСПРЕДЕЛЕНИЕ КЛЮЧЕЙ
При традиционном шифровании обе участвующие в обмене данными сторо-
ны должны получить общий ключ, к которому другие пользователи доступа
иметь не должны. При этом ключи приходится менять довольно часто, чтобы
уменьшить объем теряемых данных в случае, когда ключ становится известным
противнику. Поэтому надежность любой криптографической системы во многом
зависит от системы распределения ключей, обеспечивающей средства доставки
ключей сторонам, планирующим начать обмен данными, и гарантирующей со-
хранение этих ключей в тайне от других. Для двух сторон, А и В, как указано
ниже, распределение ключей можно организовать разными способами.
1. Ключ может быть выбран стороной А и физически доставлен стороне В.
2. Ключ может выбрать третья сторона и физически доставить его сторо-
нам А и В.
3. Если стороны А и В уже используют некоторый общий ключ, одна из сто-
рон может передать новый ключ второй стороне в шифрованном виде, ис-
пользуя старый ключ.
4. Если обе стороны А и В имеют защищенные шифрованием каналы связи с
третьей стороной С, то последняя может доставить ключ участникам А и В
по этим защищенным каналам.
Варианты 1 и 2 предполагают передачу ключа из рук в руки. При каналь-
ном шифровании это требование может оказаться вполне разумным, поскольку
любое устройство канального шифрования предполагает обмен данными только с
соответствующим устройством на другом конце канала. Но при сквозном шиф-
Глава 2. Традиционное шифрование и конфиденциальность 65
ровании физическая доставка ключа практически неприемлема. В любой распре-
деленной системе каждый узел или терминал может участвовать в обмене дан-
ными со многими другими узлами и терминалами. Поэтому каждому такому
устройству потребуется множество ключей, которые придется поставлять дина-
мично. Проблема оказывается весьма трудной для решения, особенно в больших
глобально распределенных системах.
Способ 3 применяется как для канального шифрования, так и для сквоз-
ного, но если противнику когда-либо удастся получить доступ к одному из
ключей, то он сможет получить и все последующие. Даже если ключи каналь-
ного шифрования необходимо менять часто, все равно это следует делать вруч-
ную. Для доставки ключей сквозного шифрования наиболее предпочтительным
оказывается вариант 4.
На рис. 2.10 показана схема, соответствующая варианту 4 при сквозном
шифровании. Возможности канального шифрования на схеме не представлены.
Их можно добавить или не добавлять, в зависимости от конкретных условий и
необходимости. Для схемы определяются следующие два вида ключей.
• Сеансовый ключ. Когда двум конечным системам (узлам, терминалам и
т.п.) необходимо обменяться сообщениями, они должны установить логиче-
ское соединение (например, открыть виртуальный канал). В течение всего
времени существования этого логического соединения передаваемые по не-
му данные будут шифроваться одноразовым сеансовым ключом. По завер-
шении сеанса связи или после разрыва соединения сеансовый ключ унич-
тожается.
• Постоянный ключ. Ключ, используемый объектами для распределения се-
ансовых ключей.
распределение ключей для
протокола с установлением
Рис. 2.10. Автоматическое
логических соединений
66
Часть I. Криптография
Рассматриваемая конфигурация состоит из следующих элементов.
• Центр распределения ключей. Такой центр определяет, каким системам по-
зволено связываться друг с другом. Если двум данным системам разрешено
установить соединение, центр распределения ключей предоставит одноразо-
вый сеансовый ключ для такого соединения.
• Коммуникационный процессор. Осуществляет сквозное шифрование и по-
лучает одноразовые сеансовые ключи для своего узла или терминала.
На рис. 2.10 отражены действия, которые выполняются при установке соедине-
ния. Когда ведущий узел одной системы готов установить соединение с ведущим уз-
лом другой системы, он передает пакет с запросом соединения (шаг 1). Коммуника-
ционный процессор (КП) сохраняет этот пакет и обращается к центру распределения
ключей (ЦРК) за разрешением установить соединение (шаг 2). Связь между КП и
ЦРК шифруется с использованием главного ключа, известного только КП и ЦРК.
Если ЦРК разрешает соединение, он генерирует сеансовый ключ и доставляет его
двум соответствующим коммуникационным процессорам, используя при шифрова-
нии уникальные постоянные ключи, свои для каждого из этих двух коммуникаци-
онных процессоров (шаг 3). Коммуникационный процессор, выдавший запрос, те-
перь может освободить требующий соединения пакет, установив соединение между
двумя конечными системами (шаг 4). Все пользовательские данные, пересылаемые
между двумя конечными системами, шифруются соответствующими коммуникаци-
онными процессорами с помощью полученного одноразового сеансового ключа.
Подход, использующий автоматизированное распределение ключей, обеспе-
чивает гибкость и динамику, необходимые для того, чтобы множество пользова-
телей терминалов могло соединяться со своими ведущими узлами, а множество
ведущих узлов — друг с другом.
Другой подход к распределению ключей, использующий шифрование с от-
крытым ключом, будет обсуждаться в главе 3.
2.6. РЕКОМЕНДУЕМЫЕ ИСТОЧНИКИ
ДОПОЛНИТЕЛЬНОЙ ИНФОРМАЦИИ
Обсуждавшиеся в данной главе вопросы более подробно рассмотрены в кни-
ге [STAL99J. Для изучения криптографических алгоритмов важным справочным
пособием является книга [SCHN96], в которой содержатся описания практиче-
ски всех алгоритмов шифрования и соответствующих протоколов за последние
15 лет. Другим заслуживающим внимания подробным обзором является книга
[МЕМЕ97]. Более глубокое с точки зрения математических основ обсуждение
предмета предлагается в [SNIN95].
MENE97 Menezes, A., Oorshcot, Р., and Vanstone, S. Handbook of Applied
Cryptography. Boca Raton, FL: CRC Press, 1997.
SCHN96 Schneier, B. Applied Cryptography. New York: Wiley, 1996. <
STAL99 Stallings, W. Cryptography and Network Security: Principles and Practice,
2nd edition. Upper Saddle River, NJ: Prentice Hall, 1999. (Перевод на русский
язык: В. Столлингс, Криптография, и защита сетей: принципы и практика, >
2-е издание, “Вильямс”, 2001.)
STIN95 Stinson, D. Cryptography: Theory and Practice. Boca Raton, FL: CRC Press, >
1995.
Глава 2. Традиционное шифрование и конфиденциальность
67
2.7. ЗАДАЧИ
2.1. а. Покажите, что в схеме Файстеля дешифрование является операцией, обрат-
ной шифрованию.
б. Покажите, что/дешифрование DES является операцией, обратной шифрова-
нию DES.
2.2. В алгоритме DES после шестнадцатого раунда шифрования требуется 32-
битовый обмен, чтобы превратить обращение процесса шифрования в повтор-
ный прогон шифрованного текста через тот же алгоритм с обратным порядком
следования ключей. Это должно следовать из решения задачи 2.1. Однако ее
решение может не давать четкого объяснения необходимости 32-битового обме-
на, о котором идет речь. Чтобы прояснить ситуацию, выполните следующие уп-
ражнения. Пусть
А|| В — это конкатенация битовых строк А и В,
T;(R||L) — преобразование, соответствующее г-й итерации алгоритма
шифрования, 1 < г < 16,
TD;(R||L) — преобразование, соответствующее г-й итерации алгоритма де-
шифрования, 1 < i < 16,
T17(R || L) = L Н R , т.е. это преобразование, выполняемое после шестнадцатой
итерации алгоритма шифрования.
а. Докажите, что композиция TDj(IP(IP_‘(T17(T16(L15 ||R15))))) эквивалентна пре-
образованию, меняющему местами 32-битовые половинки Ь15 и R15. Иными
словами, требуется показать, что
TD1(IP(IP1(T17(T16(L15 || R15))))) =r15 IIL15 .
б. Теперь предположим, что мы отказались от 32-битового обмена в финале ал-
горитма шифрования. В этом случае нам хотелось бы иметь равенство
TD1(IP(IP~1(T16(L15 || R15)))) = L15 И R15.
Выполняется ли оно?
2.3. а. Пусть М' обозначает побитовое дополнение М. Докажите, что если для неко-
торых значений открытого текста и ключа рассмотреть их дополнения, то в
результате шифрования дополнений будет получено значение шифрованного
текста, являющееся дополнением оригинального шифрованного текста, а именно,
если Y = DESK(X),
то Y' = DESK'(X').
Подсказка. Начните с доказательства того, что для любых двух битовых строк
А и В одинаковой длины справедливо равенство (А®В)' = А'®В .
б. Как уже отмечалось, для анализа DES с помощью перебора всех ключей не-
обходимо вести поиск в пространстве, содержащем 256 элементов. Не меняет
ли данную оценку результат, полученный в пункте а этого упражнения?
2.4. Если в режиме ЕСВ алгоритма DES некоторый блок пересылаемого шифрован-
ного текста будет получен адресатом с искажением, то после дешифрования
окажется искаженным только соответствующий блок открытого текста. В ре-
68
Часть I. Криптография
жиме СВС такое искажение повлияет и на последующие блоки. Например, ис-
кажение, возникшее при передаче С] (см. рис. 2.7), очевидно, повлечет иска-
жения в полученных адресатом блоках Pt и Р2 .
а. Будут ли искажены блоки, следующие за Р2 ?
б. Предположим, что ошибка возникла в одном бите исходной версии Р| . На
какое число блоков шифрованного текста повлияет эта ошибка? Что при этом
получит адресат пересылаемого сообщения?
2.5. Если искажение одного бита символа шифрованного текста произойдет при пе-
редаче в 8-битовом режиме CFB, на сколько блоков распространится это иска-
жение в полученном сообщении?
2.6. Схемы распределения ключей, использующие центры управления доступом
и/или центры распределения ключей, уязвимы для атак определенного вида.
Охарактеризуйте проблемы защиты, возникающие при такой централизации.
2.7. Предположим, что некто предлагает вам следующий способ подтверждения то-
го, что вы оба владеете одним секретным ключом. Вы создаете строку случай-
ных битов, длина которой равна длине ключа, объединяете эту строку с ключом
с помощью операции XOR и посылаете результат в канал связи. Ваш партнер с
помощью операции XOR объединяет полученный блок с ключом (который дол-
жен совпадать с вашим) и возвращает вам результат. Убедившись, что получен-
ная вами строка совпадает с оригинальной, созданной вами, строкой случайных
битов, вы заключаете, что ваш партнер имеет тот же секретный ключ, что и вы,
хотя ни один из вас не пересылал секретный ключ другому. Нет ли в этой схеме
скрытых дефектов?
Глава 2. Традиционное шифрование и конфиденциальность
69
This page intentionally left blank
ГЛАВА
Криптография
с открытым
ключом и
аутентификация
сообщений
3.1. Методы аутентификации сообщений
3.2. Защищенные функции хэширования и НМАС
3.3. Основы шифрования с открытым ключом
3.4. Алгоритмы шифрования с открытым ключом
3.5. Цифровые подписи
3.6. Управление ключами
3.7. Рекомендуемые источники дополнительной
информации
3.8. Задачи
Дополнение 3.1. Простые числа и арифметика
в классах вычетов
Наряду с функцией обеспечения конфиденциальности одной из важнейших
функций сетевой защиты является аутентификация сообщений. В этой
главе рассматриваются три аспекта аутентификации сообщений. Сначала
будет описано использование кодов аутентичности сообщений и функций хэши-
рования. Затем мы обсудим принципы шифрования с открытым ключом и рас-
смотрим два конкретных алгоритма такого шифрования. Эти алгоритмы приме-
няются для обмена ключами, используемыми в схемах традиционного шифрова-
ния. После этого мы поговорим об использовании шифрования с открытым
ключом для создания цифровых подписей, которые применяются в усовершенст-
вованных схемах аутентификации сообщений. В заключение рассмотрим вопрос
управления ключами в свете новых знаний, полученных в данной главе.
3.1. МЕТОДЫ АУТЕНТИФИКАЦИИ
СООБЩЕНИЙ
Шифрование защищает от атак пассивной формы (подслушивания). Совершен-
но иной проблемой является защита от активных атак (фальсификации данных и
транзакций). Защита от таких атак обеспечивается аутентификацией сообщений.
Говорят, что сообщение, файл, документ или какой-то другой набор данных
является аутентичным (т.е. подлинным), если такой набор данных действитель-
но получен из того источника, который объявлен в сообщении, и в точности со-
ответствует тому набору данных, которые из этого источника отсылались. Ау-
тентификация сообщений представляет собой процедуру, обеспечивающую свя-
зывающимся сторонам возможность проверки аутентичности получаемых
сообщений. Двумя важными задачами аутентификации является проверка того,
что содержимое сообщения не было изменено, и того, что сообщение прибыло
именно из того источника, о котором информирует сообщение. Можно также по-
требовать проверку своевременности (т.е. того, что сообщение не было кем-то
специально задержано и впоследствии воспроизведено), а также соответствия
данного сообщения последовательности других сообщений в потоке обмена дан-
ными между двумя сторонами.
Аутентификация сообщений с помощью шифрования
Можно выполнить аутентификацию сообщения с помощью обычного
шифрования по традиционной схеме. Если предположить, что только отпра-
витель и получатель знают используемый совместно ключ (что на самом деле
должно иметь место), то только истинный отправитель сможет зашифровать
сообщение для соответствующего получателя. К тому же, если в сообщение
включить код контроля ошибок и порядковый номер, то получатель будет
уверен, что прибывшее сообщение не было изменено и что источник при-
бывшего сообщения идентифицирован правильно. А если сообщение включа-
ет еще и штамп времени, получатель может быть уверен, что сообщение не
было задержано на большее время, чем это допустимо для транзита данных в
соответствующей сети.
72
Часть I. Криптография
Аутентификация сообщений без шифрования
В этом разделе рассматривается несколько методов аутентификации сооб-
щений, не зависящих от шифрования. Во всех соответствующих случаях перед
пересылкой сообщения к нему присоединяется специально генерируемый ярлык
(тег) аутентичности. Само сообщение непосредственно не шифруется и может
быть прочитано в узле адресата вне зависимости от функции аутентификации.
Поскольку обсуждаемые в этом разделе методы не предполагают шифрова-
ния сообщений, конфиденциальность сообщений этими методами не обеспечива-
ется. Но если традиционное шифрование обеспечивает аутентификацию и широ-
ко используется во многих приложениях, почему бы не ограничиться простым
шифрованием вообще, что обеспечит как конфиденциальность, так и аутентифи-
кацию? В [DAVI89] предлагается рассмотреть три ситуации, в которых разделе-
ние вопросов аутентификации сообщений и обеспечения их конфиденциальности
оказывается более предпочтительным.
1. Существует ряд приложений, в которых одно и то же сообщение предпола-
гается передавать многим адресатам (это может быть извещение пользова-
телей сети о том, что сеть в данный момент недоступна, или сигнал тревоги
из центра управления). Тогда и дешевле, и надежнее иметь только одного
адресата, осуществляющего мониторинг аутентичности соответствующих
сообщений. В этом случае сообщение может передаваться в виде открытого
текста с соответствующим ярлыком аутентичности сообщения. Ответствен-
ная за аутентификацию система выполняет процедуру аутентификации, и,
если обнаруживается нарушение, все остальные системы извещаются об
опасности с помощью общего сигнала тревоги.
2. Другим возможным сценарием является пропедура обмена, при которой од-
на сторона очень загружена и не может тратить время на дешифрование
всех поступающих сообщений. Аутентификация выполняется на выбороч-
ной основе, когда сообщения для контроля выбираются случайным образом.
3. Весьма привлекательной возможностью является аутентификация компьютер-
ных программ, хранимых в открытом виде. При этом для выполнения компью-
терной программы не потребуется выполнять ее дешифрование, что, в свою
очередь, исключит бесполезное расходование ресурсов процессора. Если к про-
грамме присоединить ярлык аутентичности, его можно будет проверять каж-
дый раз, когда потребуется убедиться в целостности данной программы.
Таким образом, и для аутентификации, и для шифрования находятся свои
области применения в схеме защиты.
Код аутентичности сообщения
Одним из методов аутентификации является присоединение к сообщению
небольшого блока данных фиксированного размера, генерируемого с помощью
некоторого секретного ключа. Такой блок данных обычно называется крипто-
графической контрольной суммой или кодом аутентичности сообщения (Message
Authentication Code — МАС). При этом предполагается, что две участвующие в
обмене данными стороны, скажем, А и В, используют общий секретный ключ
КАВ . Чтобы послать сообщение М адресату В, отправитель А вычисляет код ау-
Глава 3. Криптография с открытым ключом и аутентификация... 73
тентичности сообщения как функцию сообщения и ключа: МАСм = F(KAB, М).
Сообщение с добавленным к нему значением МАС пересылается адресату. Полу-
чатель выполняет аналогичные вычисления с пришедшим сообщением, исполь-
зуя тот же секретный ключ, и получает свое значение МАС. Вычисленное значе-
ние МАС сравнивается с пришедшим вместе с сообщением (рис. 3.1). Если пред-
положить, что секретный ключ знают только получатель и отправитель, и если
пришедшее значение МАС совпадает с вычисленным получателем, то можно ут-
верждать следующее.
1. Получатель может быть уверен, что сообщение не было изменено. Если про-
тивник изменит сообщение, но не изменит соответствующим образом значе-
ние МАС, то вычисленное получателем значение будет отличаться от при-
шедшего с сообщением. Не зная секретного ключа, противник не сможет
правильно изменить значение МАС, чтобы оно соответствовало измененному
сообщению.
2. Получатель может быть уверен, что сообщение пришло из указанного ис-
точника. Поскольку секретный ключ никому, кроме указанного отправите-
ля, не известен, никто другой не может подготовить сообщение с соответст-
вующим значением МАС.
3. Если сообщение включает присвоенный ему порядковый номер (как это,
например, предполагается в случае использования протоколов Х.25, HDLC
и TCP), то получатель может быть уверен в том, что сообщения приходят в
правильной последовательности, поскольку противник не может изменить
порядковый номер сообщения.
Для генерирования кодов аутентичности имеется целый ряд алгоритмов.
Национальное бюро стандартов США в своей публикации DES Modes of
Operation (Режимы функционирования DES) для создания кодов аутентичности
рекомендует использовать алгоритм DEA. Алгоритм DEA используется для
шифрования сообщения, и определенное число последних битов результата ис-
пользуется как соответствующий код аутентичности. Обычно используют 16- или
32-битовые коды.
Только что описанный процесс подобен шифрованию. Различие заключается
в том, что алгоритм аутентификации не обязан быть обратимым, что при шиф-
ровании, очевидно, необходимо. Оказывается, что вследствие определенных ма-
тематических свойств функции аутентификации она менее уязвима в отношении
взлома, чем шифрование.
Односторонняя функция хэширования
Вариантом идеи использования кодов аутентичности сообщений, при-
влекающим в последнее время все большее внимание, является односторон-
няя функция хэширования. Как и в случае кодов аутентичности сообщений,
функция хэширования получает на вход сообщение М произвольной длины, а
на выходе выдает хэш-код Н(М) фиксированной длины, называемый также
профилем сообщения. В отличие от значения МАС, функция хэширования не
требует секретного ключа. Для аутентификации сообщения вместе с ним пе-
ресылается и его профиль, присоединяемый к сообщению некоторым специ-
альным образом.
74
Часть I. Криптография
Сообщение
Рис. 3.1. Аутентификация сообщений с помощью кода аутентичности (значения МАС)
На рис. 3.2 показано три способа аутентификации сообщения. Профиль со-
общения может быть зашифрован с помощью средств традиционного шифрова-
ния (рис. 3.2, а), и тогда для аутентификации требуется, чтобы отправитель и
получатель имели общий, известный только им, секретный ключ шифрования.
Сообщение можно зашифровать по схеме шифрования с открытым ключом
(рис. 3.2, б). Подход, предполагающий использование открытых ключей, имеет
два преимущества: он, кроме аутентификации сообщения, обеспечивает и циф-
ровую подпись, а кроме того, не требует доставки секретного ключа сообщаю-
щимся сторонам. Этот подход будет обсуждаться в разделе 3.5.
Эти два подхода предпочтительнее подхода, основанного на шифровании
всего сообщения, поскольку предполагают меньшие нагрузки на вычислитель-
ную систему. Тем не менее, наблюдается постоянный рост заинтересованности в
развитии методов, позволяющих избежать шифрования вообще. Как было ука-
зано в [TSUD92], основными причинами этого являются следующие.
• Программное обеспечение, выполняющее шифрование, работает довольно
медленно. Даже если объем данных, которые шифруются при передаче со-
общения, будет небольшим, поток исходящих и входящих сообщений в сис-
теме может оказаться очень интенсивным.
• Цены на аппаратные средства шифрования довольно высоки. Хотя и суще-
ствуют недорогие микросхемы, реализующие алгоритмы DES, общая стои-
мость может оказаться очень высокой, если придется установить их во всех
узлах сети.
Глава 3. Криптография с открытым ключом и аутентификация... 75
а) традиционное шифрование
б) шифрование с открытым ключом
в) использование секретного значения
Рис. 3.2. Аутентификация сообщений с помощью односторонней функции хэширования
• Аппаратные средства шифрования оптимизированы для работы с большими
объемами данных. При малых блоках данных значительная часть времени
тратится непроизводительно на процедуры инициализации/вызова.
• Алгоритмы шифрования могут быть защищены патентами. Например, ал-
горитм RSA шифрования с открытым ключом запатентован, и поэтому на
использование подобных алгоритмов требуются лицензии, что тоже вылива-
ется в дополнительные расходы.
• Алгоритмы шифрования относятся к вопросам экспортного государственно-
го регулирования США. Это касается, в частности, алгоритма DES.
На рис. 3.2, в показан вариант аутентификации сообщения с помощью
функции хэширования, не использующей шифрования. Соответствующая техно-
логия предполагает, что сообщающиеся стороны, скажем, А и В, имеют извест-
76
Часть I. Криптография
ное только им общее секретное значение SAB. Перед отсылкой сообщения сторо-
не В сторона А вычисляет функцию хэширования для результата конкатенации
этого секретного значения и текста сообщения: MDM = H(SAB || М) -1 Затем
[M||MDm] пересылается стороне В. Поскольку сторона В имеет значение SAB,
она может вычислить H(SAB || М) и проверить соответствие вычисленного значе-
ния полученному значению MDM . Поскольку само секретное значение с сообще-
нием не пересылается, у нарушителя нет возможности модифицировать перехва-
ченное сообщение. Пока секретное значение остается секретным, нарушитель не
может генерировать фальшивые сообщения.
Один из вариантов последнего из описанных здесь подходов, называемый
НМАС, принят в качестве стандарта защиты протокола IP (см. главу 6), а также
используется в протоколе SNMPv3 (см. главу 8).
3.2. ЗАЩИЩЕННЫЕ ФУНКЦИИ
ХЭШИРОВАНИЯ И НМАС
Односторонние функции хэширования, называемые также защищенными
функциями хэширования, оказываются важными не только с точки зрения ау-
тентификации сообщений, но‘и с точки зрения цифровых подписей. В этом раз-
деле мы сначала обсудим свойства, которыми должна обладать защищенная
функция хэширования, а затем рассмотрим одну из наиболее важных практиче-
ски используемых функций хэширования — SHA-1.
Необходимые свойства функции хэширования
Целью использования функции хэширования является получение
“дактилоскопической” характеристики файла, сообщения или вообще любого
блока данных. Чтобы оказаться полезной для аутентификации, функция хэши-
рования Н должна иметь следующие свойства.
1. Быть применимой к блоку данных любой длины.
2. Давать на выходе значение фиксированной длины.
3. Значение Н(х) должно вычисляться относительно легко для любого заданно-
го х, а алгоритм вычисления должен быть практически эффективным с точ-
ки зрения как аппаратной, так и программной реализации.
4. Для любого данного кода h должно быть практически невозможно вычис-
лить х, для которого Н(х) = h .
5. Для любого блока х должно быть практически невозможно вычислить
у Ф х , для которого Н(х) = Н(у).
6. Должно быть практически невозможно вычислить любую пару различных
значений х и у, для которых Н(х) = Н(у).
Первые три из указанных здесь свойств описывают требования, обеспечивающие
зозможность практического применения функции хэширования для аутентифи-
1 || означает операцию конкатенации.
Глава 3. Криптография с открытым ключом и аутентификация... 77
кации сообщений. Четвертое свойство обеспечивает “односторонность”: легко по-
лучить код на основе имеющегося сообщения, но практически невозможно вос-
создать сообщение, имея только соответствующий код. Это свойство важно то-
гда, когда алгоритм аутентификации предполагает использование секретного
значения (см. рис. 3.2, в). Само секретное значение непосредственно не пересы-
лается, но если функция хэширования не является односторонней, то противник
может определить секретное значение достаточно легко: при возможности на-
блюдать или перехватывать поток данных противник получит в распоряжение
сообщение М и хэш-код MDM = H(SAB ||М), рассмотрит функцию, обратную
функции хэширования, и получит SAB || М = H~‘(MDM), а затем, имея и М, и
SAB || М , легко восстановит значение SAB .
Пятое свойство гарантирует, что не удастся найти другое сообщение, даю-
щее в результате хэширования то же значение, что и данное. Это предотвращает
возможность фальсификации сообщения при использовании подхода, предпола-
гающего шифрование хэш-кода (см. рис. 3.2, б и в). Если это условие не выпол-
нено, противник может действовать по следующей схеме: сначала перехватить
сообщение вместе с присоединенным к нему шифрованным хэш-кодом, затем
вычислить нешифрованный хэш-код сообщения и наконец создать альтернатив-
ное сообщение с тем же хэш-кодом.
Функцию хэширования, удовлетворяющую первым пяти требованиям из пред-
ставленного выше списка, называют слабой функцией хэширования. Если шестое
требование также выполнено, то функция хэширования называется сильной. Шестое
требование призвано обеспечить защиту от конкретного класса атак, известных под
названием атак, построенных на парадоксе задачи о днях рождения.
В дополнение к аутентификации профиль сообщения обеспечивает также
целостность данных, выполняя функцию контрольной последовательности
фрейма: если какой-либо из битов сообщения при пересылке будет случайно из-
менен, профиль сообщения укажет на ошибку.
Простые функции хэширования
Все функции хэширования построены на следующих общих принципах. Вво-
димое значение (сообщение, файл и т.п.) рассматривается как последовательность п-
битовых блоков. Вводимые данные обрабатываются последовательно блок за блоком,
чтобы в результате получить «-битовое значение функции хэширования.
Одной из простейших функций хэширования является связывание всех
блоков операцией XOR (поразрядного исключающего “ИЛИ”). Это можно запи-
сать в следующем виде:
С, = Ь(1 ® Ь,2 ® ® b,m ,
где
С, — /-й бит хэш-кода, 1 < i < п ,
т — число «-битовых блоков ввода,
by — /-й бит в у-м блоке,
® — операция XOR.
Схема процедуры показана на рис. 3.3. Процедура осуществляет простой
побитовый контроль четности и обычно называется продольным контролем чет-
13
Часть I. Криптография
ности. Такая процедура оказывается достаточно эффективной для контроля це-
лостности данных произвольного вида. В этом случае любое «-битовое значение
функции хэширования оказывается одинаково вероятным. Значит, вероятность
того, что при появлении ошибки в данных значение функции хэширования ос-
танется прежним, равна 2~". Но если речь идет о форматированных данных, ко-
торые более прогнозируемы, такая функция будет менее эффективной. Напри-
мер, в текстовых файлах с обычным английским текстом старший разряд каж-
дого байта всегда равен нулю. Поэтому для этого типа данных при
использовании 128-битовых значений функции хэширования вместо эффектив-
ности 2~128 будет наблюдаться эффективность, равная 2~112 .
Бит 1 Бит 2 • . . Бити
Блок 1 Ьц Ь21 bni
Блок 2 Ь12 Ь22 ЬП2
• • •
Блок m Ь1т bam Ь„т
Хэш-код С, С2 Сп
Рис. 3.3. Простая функция хэширования, использующая операцию XOR
Проще всего усовершенствовать такую схему, рассмотрев возможность вы-
полнения однобитового циклического сдвига (поворота) значения функции хэ-
ширования после завершения обработки каждого очередного блока. Такая про-
цедура состоит из следующих этапов.
1. Начальная инициализация «-битового значения функции хэширования ну-
левым значением.
2. Последовательная обработка «-битовых блоков данных по следующему правилу.
• Выполнение циклического сдвига текущего значения функции хэширо-
вания влево на один бит.
• Добавление текущего блока к значению функции хэширования с помо-
щью операции XOR.
Результатом процедуры является “рандомизация” вводимых данных и разруше-
ние регулярности, которая может иметь для них место.
Хотя эта процедура и обеспечивает прекрасную возможность контроля целост-
ности данных, она практически бесполезна для защиты данных в том случае, когда
шифрованный хэш-код передается с открытым сообщением (см. рис. 3.2, а и б).
Имея некоторое сообщение, совсем нетрудно создать новое сообщение, которому бу-
дет соответствовать тот же хэш-код: для этого достаточно подготовить любое необхо-
димое альтернативное сообщение и присоединить к нему подходящий «-битовый
блок, который вместе с новым сообщением сформирует необходимый хэш-код.
Так что простое выполнение операции XOR или той же операции с цикличе-
ским сдвигом (RXOR) в случае шифрования только хэш-кода оказывается недоста-
Глава 3. Криптография с открытым ключом и аутентификация... 79
точным. Но вы можете убедиться, что такая простая функция полезна, когда шиф-
руются и хэш-код, и сообщение. Правда, здесь требуется быть предельно вниматель-
ным. Технология, предлагаемая Национальным бюро стандартов (National Bureau of
Standards), предполагает выполнение простой операции XOR по отношению к 64-
битовым блокам сообщения и последующее шифрование всего сообщения в режиме
сцепления шифрованных блоков (СВС). Такая схема может быть описана следую-
щим образом. Имея сообщение, складывающееся из последовательности 64-битовых
блоков Хь Х2,Хд, , сначала следует вычислить хэш-код С, равный результату свя-
зывания всех блоков с помощью операции XOR, а затем присоединить полученный
хэш-код к концу сообщения в качестве еще одного блока:
С = ХЛ,+1=Х1®Х2®...®ХЛГ.
После этого все сообщение вместе с присоединенным хэш-кодом шифруется в
режиме СВС, в результате чего получается шифрованное сообщение
Yp У2,Y/v+1. В [JUEN85] было указано несколько способов, с помощью кото-
рых шифрованный текст подобного сообщения можно реорганизовать так, чтобы
это не повлияло на хэш-код. Например, по определению режима СВС (см.
рис. 2.7 в главе 2) мы имеем
X1=IV®DK(Y1),
x,- = y;_1®dk(y,.),
X„+1=Y„®Dk(Y„+1).
Но значение Хдг+1 является значением хэш-кода:
Хдг + | = Х| © Х2 © . .. © Хдг
= (IV ® DK(Y])) ® (Yj ® DK (Y2)) ®... ® (Y;VH Ф DK (Yv)).
Поскольку слагаемые предыдущего равенства могут связываться операцией XOR
в любом порядке, хэш-код не будет меняться при изменении порядка следования
блоков шифрованного текста.
Защищенная функция хэширования SHA-1
Защищенная функция хэширования (Secure Hash Algorithm — SHA) была
разработана Национальным институтом стандартов и технологии (NIST) и опуб-
ликована в виде федерального стандарта обработки информации в 1993 году
(PUB FIPS 180). Пересмотренная версия вышла в 1995 году в виде документа
PUB FIPS 180-1, обычно эту версию обозначают аббревиатурой SHA-1.
Алгоритм получает на вход сообщение, максимальная длина которого должна
быть меньше 264 бит, и выдает на выходе 160-битовый профиль сообщения. Вводи-
мые данные обрабатываются 512-битовыми блоками. Общая схема обработки сооб-
щения показана на рис. 3.4. Процесс обработки состоит из следующих этапов.
Этап 1. Добавление битов заполнителя. Сообщение дополняется так, чтобы его
общая длина в битах была сравнима со значением 448 по модулю 512 (т.е. дли-
на = 448 mod 512). Биты заполнителя добавляются всегда, даже если сообщение уже
оказывается требуемой длины. Поэтому добавляется от 1 до 512 бит. Структура за-
полнителя следующая: первый бит равен 1, а все остальные равны 0.
80
Часть I. Криптография
Заполнитель
(от 1 до 512 бит)
Длина сообщения
L х 512 бит = N х 32 бит
--------К бит---------
Сообщение
100...О
(К)
I
---512 бит------512 бит-► ◄---512 бит-► ---512 бит-►
160-битовый
профиль
Рис. 3.4. Создание профиля сообщения с помощью SHA-1
Этап 2. Добавление значения длины. К сообщению добавляется 64-битовый
блок, интерпретируемый как 64-битовое целое число без знака (наиболее значи-
мый байт идет первым), соответствующее значению длины исходного сообщения
(перед добавлением заполнителя).
В результате выполнения первых двух этапов получается сообщение, длина
которого кратна 512 бит. На рис. 3.4 такое расширенное сообщение представлено
в виде последовательности 512-битовых блоков Yo , Yj, ...,Y;__|, так что в итоге
длина сообщения оказывается равной Lx512 бит. Это значит также, что длина
дополненного сообщения кратна длине блока, состоящего из 16 слов длиной 32
бит. Пусть М [0...А-1] обозначает последовательность слов дополненного сообще-
ния, тогда N будет кратно числу 16. Таким образом, N =Lxl6 .
Этап 3. Инициализация буфера MD. Для хранения промежуточных и ко-
нечных результатов функции хэширования используется 160-битовый буфер.
Буфер можно представить в виде пяти 32-битовых регистров (А, В, С, D, Е). Эти
регистры инициализируются следующими 32-битовыми целыми значениями (в
шестнадцатеричном представлении).
А = 67452301,
В = EFCDAB89,
С = 98BADCFE,
D = 10325476,
Е = C3D2E1F0.
Глава 3. Криптография с открытым ключом и аутентификация... 81
Этап 4. Обработка сообщения 512-битовыми блоками (блоками по 16 слов).
Основой алгоритма является модуль, называемый функцией сжатия, состоящий
из четырех раундов обработки по 20 шагов каждый. Логика модуля показана на
рис. 3.5. Все четыре раунда имеют одинаковую структуру, но в каждом исполь-
зуется своя примитивная логическая функция. Эти функции обозначены fj, f2,
f3 и f4, соответственно.
Рис. 3.5. Обработка одного 512-битового блока в SHA-1
В каждом раунде на вход подается текущий 512-битовый блок () и
160-битовое значение буфера ABCDE, и содержимое буфера обновляется. На
каждом шаге используется добавляемая к текущему значению константа Кг,
где 0 < t < 79 соответствует номеру шага для каждого из 80 шагов всех четы-
рех раундов. Но на самом деле применяются только четыре константы, и их
значения в шестнадцатеричном и десятичном представлениях показаны в
следующей таблице.
82
Часть I. Криптография
Номер шага Шестнадцатеричное представление Целая часть числа
0< t < 19 К,= 5А827999 [230xV2]
20<г<39 К; = 6ED9EBA1 [230хТЗ]
40<f <59 К; = 8F1BBCDC [230xV5]
60<t<79 К; = CA62C1D6 [230 Хл/Т0]
Выходное значение четвертого раунда (восьмидесятый шаг) добавляется к
входному значению первого раунда (CV^), в результате чего получается CV9+1.
Сложение выполняется по модулю 232 независимо для каждого из пяти слов бу-
фера с соответствующими словами CV9 .
Этап 5. Вывод. После обработки всех 512-битовых блоков на выходе L-й
стадии обработки получается 160-битовый профиль сообщения.
Алгоритм SHA-1 обладает тем свойством, что каждый бит хэш-кода зависит от
всех битов ввода. Сложное многократное использование базовых функций f в резуль-
тате дает хорошее перемешивание, а это значит, что практически невероятно, чтобы
два наудачу выбранных сообщения породили один и тот же хэш-код, даже если эти
сообщения оказываются подобными по структуре. Если SHA-1 не имеет скрытых
дефектов (которые до сих пор обнаружены не были), задача поиска двух сообщений с
одинаковыми профилями имеет сложность порядка 280 , а задача нахождения сооб-
щения с заданным профилем имеет сложность порядка 2160 операций.
Другие защищенные функции хэширования
Как и при использовании симметричных блочных шифров, разработчики за-
щищенных функций хэширования не желают отказываться от проверенной структу-
ры. Алгоритм DES базируется на структуре шифра Файстеля, и практически все по-
следующие блочные шифры повторяют эту структуру, поскольку она может быть
адаптирована, чтобы противостоять новым угрозам криптоанализа. Если для сим-
метричного блочного шифра использовать совершенно новую структуру, придется
позаботиться о том, чтобы эта структура не открыла новые направления для еще не
применявшихся атак. Точно так же наиболее важные из современных функций хэ-
ширования используют базовую структуру, схема которой изображена на рис. 3.4.
Автором этой структуры является Меркл (Merkle) [MERK79, MERK89], и называет-
ся она итерированной функцией хэширования. Мотивацией для создания такого ро-
да структур послужило наблюдение Меркла [MERK89] и Дамгарда (Damgard)
DAMG89], касающееся того, что если функция сжатия является стойкой к колли-
зиям, то не менее стойкой будет и итерированная функция. Поэтому подобная
структура может использоваться для создания защищенной функции хэширования,
допускающей ее применение к сообщениям любой длины. Таким образом, проблема
создания защищенной функции хэширования сводится к проблеме создания защи-
щенной функции сжатия, являющейся стойкой в отношении коллизий и оперирую-
щей в условиях ввода некоторой фиксированной длины. Этот подход доказал свою
действенность, и новые разработки только совершенствуют имеющуюся структуру и
увеличивают длину хэш-кода.
Глава 3. Криптография с открытым ключом и аутентификация... 83
В этом разделе мы рассмотрим две другие защищенные функции хэширова-
ния, которые вместе с SHA-1 стали достаточно популярными в коммерческих
приложениях. Их основные характеристики сравниваются в табл. 3.1.
Таблица 3.1. Сравнение защищенных функций хэширования
MD5 SHA-1 RIPEMD-160
Длина профиля 128 бит 160 бит 160 бит
Вазовая длина обра- батываемых блоков 512 бит 512 бит 512 бит
Число шагов 64 (4 раунда по 16 шагов) 80 (4 раунда по 20 шагов) 160 (5 спаренных раун- дов по 16 шагов)
Максимальная дли- на сообщения оо 2м-1 бит 2м-1 бит
Число примитивных логических функций 4 4 5
Число аддитивных констант 64 4 9
Алгоритм MD5 вычисления профиля сообщения
Алгоритм MD5 вычисления профиля сообщения (RFC 1321) был разработан
Роном Райвестом (Ron Rivest). До недавнего времени, когда буквально за не-
сколько лет существенно возросли как возможности анализа с перебором всех
вариантов, так и криптоанализа, MD5 оставался наиболее распространенным из
всех защищенных алгоритмов хэширования. Алгоритм берет в качестве входных
данных сообщение произвольной длины и выдает на выходе 128-битовое значе-
ние профиля сообщения. Вводимые данные обрабатываются последовательно
512-битовыми блоками.
В результате быстрого роста скорости работы процессоров защищенность
128-битовых хэш-кодов стала недостаточной. Можно доказать, что задача поиска
двух сообщений с одинаковыми профилями имеет сложность порядка 264 опера-
ций, а сложность задачи нахождения сообщения с заданным профилем — по-
рядка 2128 операций. Первое из этих значений слишком мало с точки зрения на-
дежной защиты. Кроме того, были разработаны сценарии целого ряда атак, де-
монстрирующих уязвимость MD5 в отношении современных методов
криптоанализа [BERS92, BOER93, ООВВЭба].
RIPEMD-160
Алгоритм RIPEMD-160 вычисления профиля сообщения [DOBB96b, BOSS97]
был разработан под эгидой Европейского проекта RIPE (RACE Integrity Primitives
Evaluation — проект RACE оценки целостности примитивов) в рамках программы
RACE (Research into Advanced Communications for Europe — программа исследова-
ний по созданию усовершенствованной системы связи для Европы) группой исследо-
вателей, которые предложили близкий к успеху сценарий атаки на MD4 и MD5.
Сначала эта группа разработала 128-битовую версию RIPEM. После завершения про-
екта RIPE X. Доббертин (Н. Dobbertin), который не был его участником, нашел ва-
риант атаки на два раунда RIPEMD, а позднее на MD4 и MD5. В этой связи группа
84
Часть I. Криптография
участников проекта RIPE решила модернизовать RIPEMD. Соответствующая работа
была выполнена ими совместно с Доббертином.
Алгоритм RIPEMD-160 в целом подобен по структуре SHA-1. Алгоритм по-
лучает на вход сообщение произвольной длины и выдает на выходе 160-битовый
профиль сообщения. Вводимые данные обрабатываются блоками по 512 бит.
НМАС
В последние годы возрос интерес к методам вычисления значений МАС на
основе криптографических хэш-кодов типа SHA-1. Объясняется это следующими
обстоятельствами.
• Криптографические функции хэширования в виде программной реализации
обычно выполняются быстрее, чем реализации симметричных блочных
шифров (например DES).
• Программные библиотеки для криптографических функций хэширования
широко доступны.
• Для криптографических функций хэширования нет ограничений на экспорт
из США или других стран, тогда как для симметричных блочных шифров
они предусмотрены (даже при использовании шифра только для вычисле-
ния значений МАС).
Функции хэширования типа SHA-1 не были разработаны для использова-
ния в качестве средства вычисления значений МАС и не могут применяться для
этого непосредственно, поскольку не зависят от секретного ключа. Был предло-
жен ряд вариантов добавления секретного ключа в уже существующие алгорит-
мы хэширования. Наибольшую поддержку получил подход, называемый НМАС
[BELL96a, BELL96b]. Алгоритм НМАС был представлен в документе RFC 2104,
принят как обязательный для реализации в протоколе IPSec и используется в
ряде других протоколов Internet, в частности, на транспортном уровне (протокол
TLS — протокол защиты транспортного уровня, призванный вскоре заменить
SSL — протокол защищенных сокетов) и для электронных транзакций (протокол
SET — протокол защищенных электронных транзакций).
Цели разработки НМАС
В документе RFC 2104 представлен следующий список целей, преследовав-
шихся при разработке алгоритма НМАС.
• Возможность использования без модификаций уже имеющихся функций хэши-
рования, в частности, функций хэширования, для которых существуют прове-
ренные на практике, открытые и широко доступные программные реализации.
• Возможность легкой замены встроенной функции хэширования более ско-
ростными или более защищенными функциями хэширования, если таковые
потребуются и будут найдены.
• Сохранение скорости работы алгоритма, близкой к скорости работы соот-
ветствующей функции хэширования, без значительного ухудшения показа-
телей скорости.
• Возможность применения ключей и простота обращения к ним.
Глава 3. Криптография с открытым ключом и аутентификация... 85
• Простота анализа стойкости механизма аутентификации при разумных
предположениях относительно используемой функции хэширования.
Первые две цели являются важными с точки зрения приемлемости НМАС.
В алгоритме НМАС функция хэширования интерпретируется как “черный
ящик”. Это имеет два преимущества. Во-первых, в качестве модуля НМАС мо-
жет использоваться уже существующая реализация функции хэширования. При
таком подходе немалая часть кода НМАС оказывается готовой к применению без
каких бы то ни было модификаций. Во-вторых, если придется когда-либо заме-
нять имеющуюся функцию хэширования в НМАС, то для этого достаточно будет
убрать имеющийся модуль функции хэширования и заменить его новым. Это
может потребоваться например в случае, если будет найдена более быстрая
функция хэширования. Но, что более важно, если стойкость встроенной функ-
ции хэширования будет скомпрометирована, надежность НМАС может быть вос-
становлена простой заменой встроенной функции хэширования.
Последняя из вышеперечисленных целей проекта фактически обеспечивает
основное преимущество НМАС по сравнению с другими схемами, основанными
на использовании хэширования. НМАС обеспечивает гарантированную защи-
щенность при условии, что встроенная функция хэширования обладает требуе-
мой криптографической стойкостью. Мы вернемся к этому вопросу позже, а сна-
чала рассмотрим структуру НМАС.
Алгоритм НМАС
На рис. 3.6 показана общая схема работы НМАС. Определим элементы схемы.
Н — встроенная функция хэширования (например SHA-1),
М — подаваемое на вход НМАС сообщение (включая биты заполнителя,
требуемые встроенной функцией хэширования),
Y; — г-й блок М, 0 < z < L-1,
L — число блоков в М,
b — число битов в блоке,
п — длина хэш-кода, генерируемого встроенной функцией хэширования,
К — секретный ключ; если длина ключа больше Ь, ключ подается на вход
функции хэширования, чтобы получить «-битовый ключ; рекоменду-
ется длина > п,
К+ — ключ К с добавленными в начало нулями, чтобы в результате длина
получилась равной b битам,
ipad — значение 00110110 (шестнадцатеричное 36), повторенное Ь/8 раз,
opad — значение 01011010 (шестнадцатеричное 5С), повторенное Ь/8 раз.
В этом случае алгоритм НМАС можно представить формулой
НМАСК = Н[(К+ © opad) || Н[(К+ © ipad) || М]].
Подробно описать алгоритм можно следующим образом.
1. К значению К слева добавляются нули, чтобы получить 6-битовую строку
К+ (например, если К имеет длину 160 бит и b - 512, то значение К будет
дополнено 44 нулевыми байтами 0x00).
86
Часть I. Криптография
2. Значение К+ связывается операцией XOR (побитовое исключающее “ИЛИ”)
с ipad, в результате чего получается 6-битовый блок S; .
3. К Sj присоединяется М.
4. К потоку, полученному в п. 3, применяется функция Н.
5. Значение К+ связывается операцией XOR с opad, в результате чего получа-
ется 6-битовый блок So.
6. Результат хэширования, полученный в п. 4, присоединяется к So.
7. К потоку, полученному в п. 6, применяется функция Н, и результат подает-
ся на выход.
Рис. 3.6. Структура НМАС
Обратите внимание на то, что связывание с ipad означает переключение по-
ловины битов К. Точно так же связывание с opad означает переключение поло-
вины битов К, но для другого набора битов. Поэтому в результате применения к
5, и So алгоритма хэширования из К получается два ключа, сгенерированных
псевдослучайным образом.
Для достаточно длинных сообщений алгоритм НМАС должен выполняться
приблизительно за время, необходимое встроенной функции хэширования. В
НМАС дополнительно требуется применить базовую функцию хэширования три
газа (для S; , So и блока, получаемого при внутреннем хэшировании).
лава 3. Криптография с открытым ключом и аутентификация... 87
3.3. ПРИНЦИПЫ КРИПТОГРАФИИ
С ОТКРЫТЫМ ключом
Шифрование с открытым ключом имеет не меньшую важность, чем тради-
ционное шифрование, и находит свое применение в сферах аутентификации со-
общений и распределения ключей. В этом разделе рассматриваются базовые по-
нятия из области шифрования с открытым ключом, а также некоторые вопросы
распределения ключей. В разделе 3.4 обсуждаются два самых важных из ис-
пользующих открытые ключи алгоритмов: RSA и алгоритм Диффи-Хеллмана. В
разделе 3.5 будут рассмотрены цифровые подписи.
Схема шифрования с открытым ключом
Криптография с открытым ключом, предложенная Диффи (Diffie) и Хелл-
маном (Hellman) в 1976 году [DIFF76], является в области криптографии первым
радикальным шагом вперед буквально за тысячелетия. С одной стороны, алго-
ритмы криптографии с открытым ключом используют математические функции,
отличные от подстановок и перестановок. Но более важно то, что методы крип-
тографии с открытым ключом являются асимметричными, т.е. предполагают
использование двух разных ключей, в отличие от методов симметричного тради-
ционного шифрования с помощью одного ключа. Как мы покажем ниже, идея
применения двух ключей вызвала глубокие изменения и в подходах к обеспече-
нию конфиденциальности, и в области распределения ключей, и в процедурах
аутентификации.
Перед тем как приступить к рассмотрению этого вопроса, мы должны
сказать несколько слов о некоторых широко распространенных заблуждени-
ях, касающихся шифрования с открытым ключом. Одним из таких заблуж-
дений является утверждение, что шифрование с открытым ключом более за-
щищено от криптоанализа, чем традиционное шифрование. Подобное заявле-
ние было сделано, например, в знаменитой статье Гарднера (Gardner)
[GARD77] из популярного журнала Scientific American. На самом же деле
защита любой схемы шифрования зависит (1) от длины ключа и (2) от объе-
ма вычислительной работы, требуемой для взлома шифра. В этом смысле
принципиального различия между традиционным шифрованием и шифрова-
нием с открытым ключом нет, и ни одна из этих схем не имеет преимущест-
ва перед другой с точки зрения криптоанализа. Вторым заблуждением явля-
ется утверждение, что шифрование с открытым ключом оказывается универ-
сальным подходом, делающим традиционное шифрование безнадежно
устаревшим'. Напротив, ввиду слишком высоких требований, предъявляемых
со стороны схем шифрования с открытым ключом к вычислительным ресур-
сам, отказ от схем традиционного шифрования кажется весьма маловероят-
ным. Наконец, считается, что распределение ключей при шифровании с от-
крытым ключом является тривиальной задачей по сравнению с достаточно
запутанной процедурой квитирования (подтверждения установления связи),
необходимой при использовании традиционного шифрования. На самом деле
в случае шифрования с открытым ключом для этого необходим специальный
протокол, нередко предполагающий существование некоторого центрального
агента, а применяемые при этом процедуры не являются ни более простыми,
88
Часть I. Криптография
ни более эффективными, чем те, которые требуются для традиционного
шифрования.
Схема шифрования с открытым ключом складывается из следующих ком-
понентов (рис. 3.7, а).
• Открытый текст. Это текст сообщения или данные, подаваемые на вход ал-
горитма.
• Алгоритм шифрования. Алгоритм, выполняющий определенное преобразо-
вание открытого текста.
• Открытый и личный ключи. Пара ключей, выбираемых таким образом,
чтобы тогда, когда один из них применяется для шифрования, второй мож-
но было бы использовать для дешифрования. Конкретное преобразование,
выполняемое алгоритмом шифрования, зависит от открытого или личного
ключа, используемого на входе алгоритма.
« Шифрованный текст. “Перемешанный” текст сообщения, получаемый на
выходе алгоритма. Зависит от открытого текста и ключа. Для одного и того
же сообщения два разных ключа в результате дадут разные шифрованные
тексты.
• Алгоритм дешифрования. Алгоритм, с помощью которого с использованием
соответствующего ключа обрабатывается шифрованный текст, чтобы в ре-
зультате получился открытый текст.
Как видно из названий, открытый ключ пары делается доступным для
использования другими, а личный ключ остается известным только владель-
Криптографические алгоритмы общего назначения используют один из
тих ключей для шифрования, а другой, связанный с первым, — для де-
шифрования.
Главными из выполняемых при этом шагов, являются следующие.
1. Каждый пользователь генерирует пару ключей, которые предполагается ис-
пользовать для шифрования и дешифрования сообщений.
2. Каждый пользователь публикует один из ключей, размещая этот ключ в
открытом для всех реестре или доступном другим файле. Это и есть откры-
тый ключ. Второй ключ, соответствующий открытому, остается в личном
владении и должен сохраняться в секрете.
3. Собираясь послать Алисе сообщение, Боб шифрует его, используя открытый
ключ Алисы.
4. Алиса, получив сообщение, дешифрует его с помощью своего личного клю-
ча. Другой получатель не сможет дешифровать сообщение, поскольку лич-
ный ключ Алисы знает только Алиса.
В рамках этого подхода все участники имеют доступ к открытым клю-
ам, а личные ключи генерируются на месте каждым участником для себя и
ш этому их никогда не приходится распределять. До тех пор пока системе
дается сохранять свой личный ключ в секрете, поступающие сообщения
азываются защищенными. В любой момент система может изменить свой
ачный ключ и опубликовать соответствующий ему открытый ключ, заме-
шющий старый открытый ключ.
:ава 3. Криптография с открытым ключом и аутентификация... 89
а) шифрование
б) аутентификация
Рис. 3.7. Криптография с открытым ключом
Ключи, используемые в схемах традиционного шифрования, называют сек-
ретными ключами. Пара ключей, используемых в схемах шифрования с откры-
тым ключом, называются, соответственно, открытым ключом и личным клю-
чом. Личный ключ, конечно же, тоже должен храниться в секрете, но называет-
ся личным, а не секретным во избежание путаницы с ключом, используемым в
схеме традиционного шифрования.
Применение криптосистем с открытым ключом
Прежде чем перейти к следующим вопросам, необходимо разъяснить
аспект криптосистем с открытым ключом, который в противном случае ь
90
Часть I. Криптография
породить недоразумения. Криптосистемы с открытым ключом характеризуются
использованием криптографического алгоритма с двумя ключами, один из кото-
рых остается в личном пользовании, а второй открыт для всех. В зависимости от
приложения отправитель использует либо свой личный ключ, либо открытый
ключ получателя, либо оба эти ключа, если требуется выполнить какую-то спе-
циальную криптографическую функцию. В самых широких пределах использо-
вание криптосистем с открытым ключом можно отнести к трем категориям.
• Шифрование/дешифрование. Отправитель шифрует сообщение с использо-
ванием открытого ключа получателя.
• Цифровая подпись. Отправитель “подписывает” сообщение с помощью сво-
его личного ключа. Подпись получается в результате применения крипто-
графического алгоритма к сообщению или к небольшому блоку данных, яв-
ляющемуся функцией сообщения.
• Обмен ключами. Две стороны взаимодействуют, чтобы обменяться сеансо-
вым ключом. При этом возможны различные подходы, предполагающие
применение личных ключей одной или обеих сторон.
Одни алгоритмы подходят для всех трех категорий применения, тогда как
другие предназначены только для одной или двух из этих категорий. Для алго-
ритмов, рассматриваемых в этой главе (алгоритмов RSA и Диффи-Хеллмана),
возможности их применения указаны в табл. 3.2. В этой же таблице приведены
данные, касающиеся DSS (Digital Signature Standard — стандарт цифровой под-
писи) и криптографии на основе использования эллиптических кривых, которые
также упоминаются в данной главе.
Таблица 3.2. Применение криптосистем с открытым ключом
Алгоритм Шифрование/дешифрование Цифровая подпись Обмен ключами
RSA Да Да Да
Диффи-Хеллмана Нет Нет Да
DSS Нет Да Нет
Эллиптические Да Да Да
кривые
Условия применения методов криптографии с открытым
ключом
Криптосистема, схема которой показана на рис. 3.7, строится на основе крипто-
графического алгоритма, использующего два связанных ключа. Диффи и Хеллман
предположили без доказательства, что такие алгоритмы существуют. Однако они
указали условия, которым должны удовлетворять такие алгоритмы [DIFF76].
1. Для стороны В процесс генерирования пары ключей (открытый ключ KUb ,
личный ключ KRb) не должен вызывать вычислительных трудностей.
2. Для отправителя А не должен вызывать вычислительных трудностей про-
цесс создания шифрованного текста при наличии открытого ключа и сооб-
щения М, которое требуется зашифровать:
С = Екиь(М).
Глава 3. Криптография с открытым ключом и аутентификация... 91
3. Для получателя В не должен вызывать вычислительных трудностей процесс
восстановления оригинального сообщения путем дешифрования полученно-
го шифрованного текста с помощью личного ключа:
^ = ^KRb(C) = DKRb[EKUb(M)].
4. Для противника должно оказаться нереальным с точки зрения вычисли-
тельных возможностей восстановление личного ключа KRb по имеющемуся
открытому ключу KUb .
5. Для противника должно оказаться нереальным с точки зрения вычисли-
тельных возможностей восстановление оригинального сообщения М по
имеющимся открытому ключу KUb и шифрованному тексту С.
К этим требованиям можно добавить еще одно, которое, хотя и представля-
ется полезным, все же не является необходимым для всех приложений, реали-
зующих криптосистемы с открытым ключом.
6. Для шифрования можно использовать любой из двух ключей пары, а дру-
гой следует применять для дешифрования:
м - DKRb [Е киь (М)] = Dкиь [Еккь (М)].
3.4. АЛГОРИТМЫ КРИПТОГРАФИИ
С ОТКРЫТЫМ КЛЮЧОМ
Двумя наиболее популярными алгоритмами криптографических схем с откры-
тым ключом являются алгоритмы RSA и Диффи-Хеллмана. Мы рассмотрим их дос-
таточно подробно, а в конце раздела кратко представим еще два алгоритма.
Алгоритм RSA
Одну из первых криптографических схем с открытым ключом предложили
в 1977 году Рон Райвест (Ron Rivest), Ад и Шамир (Adi Shamir) и Лен Адлеман
(Len Adleman) из МТИ, а соответствующая публикация появилась в 1978 году
[RIVE78], Схема Райвеста-Шамира-Адлемана (RSA) с тех пор получила самое
широкое признание и реализована практически во всех приложениях шифрова-
ния с открытым ключом. RSA представляет собой блочный шифр, в котором от-
крытый и шифрованный текст представляются целыми числами из диапазона от
О до п - 1 для некоторого п.
Шифрование и дешифрование для блока открытого текста М и блока шиф-
рованного текста С можно представить в виде следующих формул:
С = Ме mod п,
М = Cd mod п = (Me)d mod п = Med mod n.
Как отправитель, так и получатель должны знать значения п и е, но только
получателю известно значение d. Таким образом, данная схема является алго-
ритмом шифрования с открытым ключом KU = {e, п} и личным ключом
92
Часть I. Криптография
KR={c/,«}. Чтобы этот алгоритм мог использоваться для шифрования с откры-
тым ключом, должны выполняться следующие условия.
1. Должны существовать такие значения е, d и п, при которых М. ed = М mod п
для всех М < п.
2. Должны относительно легко вычисляться Ме и С для всех значений М < п.
3. Должно быть практически невозможно определить d по имеющимся е и п.
Первые два требования удовлетворить легко. Третье условие может быть
выполнено для некоторых достаточно больших значений е и п.
Резюме алгоритма RSA представлено на рис. 3.8. Выбираются два простых чис-
та р и q, и вычисляется их произведение п, которое будет служить модулем сравне-
ния при шифровании и дешифровании. Затем рассматривается величина ф(п), назы-
ваемая функцией Эйлера (или тотиентом), значение которой равно числу положи-
-льных целых чисел, не превышающих п и взаимно простых с п. После этого
выбирается целое значение е, взаимно простое с ©(/г) (это значит, что наибольшим
. 5щим делителем чисел е и ф(п) является 1). Наконец, вычисляется значение d, яв-
ляющееся мультипликативным обратным значения е по модулю ф(п). Можно дока-
: ать, что тогда d и е удовлетворяют требуемым условиям.
Вычисление ключей
Выбор р, q
Вычисление n = р х q
Вычисление $(n):-(p-l)(q-l)
Выбор целого е
Вычисление d
Открытый ключ
Личный ключ
р и q должны быть простыми
gcd($(n), е)=1; 1 < е < ф(п)
d=e-' mod ф(п)
KU=(e,n)
KR-{d,n}
Шифрование
Открытый текст:
Шифрованный текст:
Men
С = Me(mod п)
Дешифрование
Шифрованный текст: С
Открытый текст: M = Cti(modn)
Рис. 3.8. Алгоритм RSA
ва 3. Криптография с открытым ключом и аутентификация... 93
Предположим, что пользователь А опубликовал свой открытый ключ и те-
перь пользователь В собирается переслать ему сообщение М. Пользователь В вы-
числяет С = Ме (mod и) и пересылает С. Получив этот шифрованный текст, поль-
зователь А дешифрует его, вычисляя М = Си (mod п).
Соответствующий пример показан на рис. 3.9. В этом примере ключи вы-
числяются следующим образом.
1. Выбираются два простых числа, р = 7 и q = 17.
2. Вычисляется п = pq = 7 х 17 = 119.
3. Вычисляется ф(п) = (р -l)(g -1) = 96.
4. Выбирается е, взаимно простое с 0(и) = 96 и меньше, чем ф(п); в данном
случае е = 5.
5. Определяется такое d, что de = 1 mod 96 и d < 96. Соответствующим значением
будет d ~ 77, так как 77 х 5 = 385 = 4 х 96 + 1.
Шифрование Дешифрование
Рис. 3.9. Пример использования алгоритма RSA
В результате получаются открытый ключ KU = {5,119} и личный ключ
KR = {77,119}. В данном примере показано использование этих ключей с вводи-
мым открытым текстом М= 19. При шифровании 19 возводится в пятую степень,
что в результате дает 2476099. В результате деления на 119 определяется остаток,
равный 66. Следовательно, 19J = 66 mod 119, и поэтому шифрованным текстом бу-
дет 66. При дешифровании выясняется, что 66" =19 mod 119 .
На сегодня известны два подхода, в рамках которых можно осуществить
взлом алгоритма RSA. Первый подход заключается в переборе всех возможных
вариантов личных ключей. Поэтому чем больше битов содержат представления е
и d, тем более защищенным оказывается алгоритм. Однако вычисления, выпол-
няемые и при генерировании ключа, и при шифровании/дешифровании, оказы-
ваются достаточно сложными, поэтому, чем больше длина ключа, тем медленнее
будет работать система.
В большинстве случаев обсуждение вопросов криптоанализа шифра RSA каса-
ется задачи разложения значения /1 на два его простых множителя. Для большие
значений п, имеющих большие простые множители, эта задача оказывается доста-
точно сложной, но не настолько, насколько необходимо для криптографии. Порази
тельной иллюстрацией этого может служить следующая история. В 1977 году тр!
изобретателя алгоритма RSA отважились предложить читателям популярного жур
нала Scientific American раскрыть шифрованное сообщение, которое они поместили J
разделе “Математические игры” Мартина Гарднера (Martin Gardner). За расшифров
94
Часть I. КриптографИ5
:-:у этого сообщения они предложили награду в 100 долларов. По их оценкам, задача
не могла быть решена ранее, чем приблизительно через 40 квадрильонов лет. Но в
апреле 1994 года группа исследователей, использовавшая для решения задачи более
1600 компьютеров в Internet, потребовала выплаты призовой суммы после всего
зосьми месяцев совместной работы [LEUT94], В задаче был использован открытый
ключ, состоящий из 129 десятичных знаков (т.е. имеющий длину 428 бит). Этот ре-
зультат никак не характеризует стойкость RSA, а только говорит о том, что следует
использовать более длинные ключи. На сегодня считается, что ключи длиной 1024
бит (около 300 десятичных знаков) обеспечивают достаточную стойкость практиче-
ски для любого типа приложений.
Обмен ключами по схеме Диффи-Хеллмана
Первый из опубликованных алгоритмов на основе открытых ключей поя-
вился в работе Диффи и Хеллмана, в которой было определено само понятие
криптографии с открытым ключом [DIFF76]. Обычно этот алгоритм называют
эбменом ключами по схеме Диффи-Хеллмана. Данная технология обмена клю-
чами реализована в целом ряде коммерческих продуктов.
Цель этой схемы — предоставить двум пользователям защищенную воз-
можность обменяться ключами, которые они могут впоследствии использовать
для шифрования сообщений. Сам по себе алгоритм ограничивается процедурой
обмена ключами.
Эффективность алгоритма Диффи-Хеллмана опирается на трудность вычисле-
ния дискретных логарифмов. Формально дискретный логарифм можно определить
следующим образом. Сначала определяется первообразный корень простого числа р
как число, степени которого порождают все целые числа от 1 до р-l. Это значит,
что если а является первообразным корнем простого числа р, то все числа
a mod р , a2 mod р , ..., ар~х mod р
должны быть разными и представлять все целые числа от 1 до р - 1 в некоторой
перестановке.
Для любого целого числа b и любого первообразного корня а простого числа
? однозначно определяется показатель степени i, при котором
b = a'modp, где 0<z<(p-l).
Этот показатель степени обычно называется дискретным логарифмом, или ин-
дексом b по основанию а, рассматриваемому по модулю р. Это значение записы-
вается в форме inda p(b).
Теперь мы можем описать обмен ключами по схеме Диффи-Хеллмана, иллюст-
рацией которой служит рис. 3.10. В этой схеме имеются два открытых для всех чис-
та: простое число q и целое число а, являющееся первообразным корнем q. Предпо-
ложим, что пользователи А и В намерены обменяться ключами. Пользователь А вы-
тирает случайное целое число ХА<д и вычисляет Ул = а*А mod q. Аналогично
пользователь В независимо выбирает случайное целое число Хв < q и вычисляет
в = аХв mod q Каждая сторона сохраняет значение X в тайне, а значение Y делает
:вободно доступным другой стороне. Пользователь А вычисляет ключ по формуле
Глава 3. Криптография с открытым ключом и аутентификация... 95
К = (Гв)Уа mod 7 . а пользователь В— по формуле К = (УА)Хв mod 7 . Эти две формулы
при вычислении дают одинаковые результаты:
К = (Ув)*лтОа<7
= (аХв mod <?)Ха mod q
= (ссХв)Ха mod q (по правилам арифметики в классах вычетов)
= аЛ'вХ'Л mod q
= (<хХа)Хв mod q
= (аХд mod q)Xe mod q
= (УА)Хвтоб<?.
Итак, обе стороны обменялись секретным ключом. Поскольку при этом ХА
и Хв были только в личном пользовании и поэтому сохранились в тайне, про-
тивнику придется работать только с q, а, гА и гв . Таким образом, ему придет-
ся вычислять дискретный логарифм, чтобы определить ключ. Например, чтобы
определить ключ пользователя В, противнику нужно вычислить
*в =ind«,9(TB).
После этого он сможет вычислить ключ К точно так же, как это делает пользо-
ватель В.
Защищенность обмена ключами по схеме Диффи-Хеллмана опирается фак-
тически на то, что в то время, как степени по модулю некоторого простого числа
вычисляются относительно легко, вычислять дискретные логарифмы оказывает-
ся очень трудно. Для больших простых чисел последнее считается задачей прак-
тически неразрешимой.
Вот пример, взятый из [WELS88]. Обмен ключами строится на использова-
нии простого числа <7 = 71 и его первообразного корня а =7. Пользователи А и В
выбирают секретные ключи ХА =5 и Хв =12 , соответственно. Каждый вычисля-
ет свой открытый ключ:
УА = 75 =51 mod 71,
Ув = 712 = 4 mod 71.
После того как пользователи обменяются открытыми ключами, каждый из них
сможет вычислить общий секретный ключ:
К = (Ув)Ха mod71 = 45 =30 mod71,
К = (УА)Хв mod71 = 5112 =30 mod 71.
Имея {51,4}, противнику не удастся с легкостью вычислить 30.
На рис. 3.11 представлен простой протокол, в котором используются вы-
числения по схеме Диффи-Хеллмана. Предположим, что пользователь А собира-
ется установить связь с пользователем В и применить секретный ключ для шиф-
рования сообщений, передаваемых по такой связи. Пользователь А может гене-
рировать одноразовое секретное значение ХА , вычислить значение уА и
96
Часть I. Криптография
отослать последнее пользователю В. В ответ пользователь В генерирует секретное
значение Хв , вычисляет Ув и посылает ув пользователю А. Оба пользователя
могут теперь вычислить общий ключ. Необходимые открытые значения q и а
должны быть известны заранее. Пользователь А может также выбрать эти зна-
чения по своему усмотрению и включить их в первое сообщение.
Глобальные открытые элементы
q Простое число
а а < q и а — первообразный корень q
Вычисление ключа пользователем А
Выбор секретного Хд XA<q
Вычисление открытого Уд YA = aXAmodq
Вычисление ключа пользователем В
Выбор секретного Xg Xg<q
Вычисление открытого Yg Yg = ахв mod q
Вычисление секретного ключа пользователем А
K=(Yg)x-Amodq
Вычисление секретного ключа пользователем В
К " (Уд)Х,! mod q
Рис. 3.10. Алгоритм обмена ключами по схеме Диффи-Хеллмана
В качестве примера другой возможности использования алгоритма Диффи-
Селлмана рассмотрим некоторую группу пользователей (например, всех пользовате-
лей локальной сети) и предположим, что каждый из этих пользователей должен сге-
7лава 3. Криптография с открытым ключом и аутентификация... 97
нерировать секретное значение лА для долгосрочного применения и вычислить от-
крытое значение УА . Все полученные таким образом открытые значения вместе с
глобальными открытыми значениями q и а сохраняются централизованно в некото-
ром каталоге. В любой момент пользователь В может получить доступ к открытому
значению пользователя А, вычислить секретный ключ и использовать его для пере-
сылки шифрованного сообщения пользователю А. Если централизованно хранящий-
ся каталог надежен, то эта форма связи обеспечивает как конфиденциальность, так и
определенную степень аутентификации. Поскольку только пользователи А и В могут
определить ключ, другой пользователь не сможет прочитать сообщение
(конфиденциальность). Получатель А знает, что только пользователь В мог создать
сообщение, используя этот ключ (аутентификация). Однако такая схема не защище-
на от атак воспроизведения сообщений.
Пользователь А Пользователь В
Рис. 3.11. Обмен ключами по схеме Диффи-Хеллмана
Другие алгоритмы криптографии с открытым ключом
Коммерческое признание получили еще два алгоритма, предполагающие
использование открытых ключей, — DSS и криптография на основе эллиптиче-
ских кривых.
Стандарт цифровой подписи (DSS)
Национальный институт стандартов и технологии (NIST) опубликовал фед
ральный стандарт обработки информации FIPS PUB 186, известный также кг
DSS (Digital Signature Standard — стандарт цифровой подписи). Стандарт Df
основан на алгоритме хэширования SHA-1 и представляет собой новую технол
гию использования цифровой подписи — алгоритм DSA (Digital Signature Alg
rithm — алгоритм цифровой подписи). Стандарт DSS был предложен в 1991 г.,
его исправленная версия — в 1993 г. в ответ на возникшие сомнения в надежи
сти соответствующей схемы. В 1996 году в него были внесены незначительна
изменения. В DSS используется алгоритм, призванный обеспечить только фуз
цию цифровой подписи. В отличие от RSA, данный алгоритм не может испо.
зоваться для шифрования или обмена ключами.
98
Часть I. Криптограф!
Криптография эллиптических кривых
Большинство продуктов и стандартов, в которых для шифрования и цифровых
подписей применяется метод криптографии с открытым ключом, базируется на ал-
горитме RSA. Число битов ключа, необходимое для надежной защиты RSA, за по-
следние годы резко увеличилось, что обусловило соответствующий рост нагрузки на
системы, в которых выполняются приложения, использующие RSA. Это породило
множество проблем, особенно для узлов, специализирующихся на электронной ком-
мерции, где требуется защита большого числа транзакций. Совсем недавно появился
подход, который может конкурировать с RSA — это криптография на основе эллип-
тических кривых. Уже сейчас предпринимаются попытки стандартизации этого под-
хода, что, например, нашло отражение в стандарте IEEE Р1363, регулирующем не-
которые вопросы криптографии с открытым ключом.
Привлекательность подхода на основе эллиптических кривых в сравнении с
RSA заключается в том, что с помощью эллиптических кривых обеспечивается
эквивалентная защита при очень небольшом числе разрядов, вследствие чего
уменьшается загрузка процессора. В то же время, хотя теория криптографии эл-
липтических кривых у всех на слуху уже в течение достаточно долгого времени,
только недавно начали появляться продукты, представляющие интерес для
криптоанализа на предмет наличия соответствующих слабых мест. Таким обра-
зом, степень доверия к методам криптографии эллиптических кривых еще не
так высока, как степень доверия к RSA.
Математическое объяснение методов криптографии эллиптических кривых
выходит за рамки этой книги, поскольку объяснить их значительно труднее, чем
описать RSA или алгоритм Диффи-Хеллмана. Отметим только, что соответст-
вующий подход основан на использовании свойств математических объектов, из-
вестных под названием эллиптических кривых.
3.5. ЦИФРОВЫЕ ПОДПИСИ
Шифрование с открытым ключом можно использовать и по-другому, как
показано на рис. 3.7, б. Предположим, что Боб хотел бы переслать Алисе сооб-
щение, содержимое которого он не считает секретным, но желает, чтобы Алиса
была уверена в том, что сообщение пришло именно от него. В этом случае Боб
использует свой личный ключ для шифрования сообщения. Когда Алиса полу-
чит шифрованный текст, она выяснит, что его можно дешифровать с помощью
открытого ключа Боба, а это докажет, что сообщение могло быть зашифровано
только Бобом. Никто другой не имеет личного ключа Боба, поэтому никто дру-
гой не мог создать шифрованный текст, дешифруемый открытым ключом Боба.
В данном случае все шифрованное сообщение выступает в роли цифровой подпи-
си. Кроме того, невозможно также изменить сообщение, не имея в своем распо-
ряжении личного ключа Боба, поэтому сообщение оказывается аутентичным с
точки зрения как достоверности источника, так и гарантии целостности данных.
В схеме, о которой идет речь, шифруется все сообщение, и это, хотя и
идентифицирует отправителя и подтверждает целостность содержимого, требует
от системы достаточно много ресурсов. Каждый документ, чтобы его можно бы-
ло использовать, должен храниться в виде открытого текста. Еще один экземп-
ляр документа должен храниться в виде шифрованного текста, чтобы в случае
Глава 3. Криптография с открытым ключом и аутентификация... 99
спора можно было выяснить источник и восстановить содержимое оригинала.
Поэтому более эффективным подходом, позволяющим достичь тот же результат,
оказывается шифрование небольшого блока данных, являющегося функцией до-
кумента. Такой блок данных, называемый аутентификатором, должен не да-
вать возможности изменить документ так, чтобы при этом не изменился бы ау-
тентификатор. Если аутентификатор будет зашифрован с использованием лично-
го ключа отправителя, он будет служить подписью, удостоверяющей источник,
содержимое и последовательность отправки сообщений. В качестве подходящей
функции документа может выступать защищенный хэш-код SHA-1. Соответст-
вующий сценарий показан на рис. 3.2, б.
Важно подчеркнуть, что только что описанный процесс шифрования не
обеспечивает конфиденциальности. Это означает, что пересылаемому таким об-
разом сообщению гарантирована защита от изменения, но не от перехвата. Это
очевидно в том случае, когда для создания подписи используется только часть
сообщения, поскольку тогда остаток сообщения передается открытым текстом.
Но даже в полностью зашифрованном сообщении конфиденциальность не обес-
печивается, поскольку любой сторонний наблюдатель может дешифровать пере-
даваемое сообщение, используя для этого открытый ключ отправителя.
3.6. УПРАВЛЕНИЕ КЛЮЧАМИ
Одной из главных сфер применения схемы шифрования с открытым клю-
чом является решение проблемы распределения ключей. В этой сфере различают
две области использования методов шифрования с открытым ключом:
• распределение открытых ключей;
• использование шифрования с открытым ключом для распределения секрет-
ных ключей.
Мы рассмотрим каждую из этих областей использования данной схемы шифро-
вания по очереди.
Цифровые сертификаты
Главной особенностью шифрования с открытым ключом является тот
факт, что открытый ключ открыт для всех. Таким образом, если имеется не-
который общепринятый алгоритм шифрования с открытым ключом
(например RSA), то любая из сторон может послать свой открытый ключ
любой другой стороне или открыть этот ключ всем, опубликовав его. Этот
подход, конечно, удобен, но он имеет большой недостаток: публикацию мо-
жет фальсифицировать кто угодно. Это значит, что некто может объявить
себя стороной А и разослать другим сторонам или опубликовать свой откры-
тый ключ. До того, как пользователь А обнаружит подлог и предупредит об
опасности других, фальсификатор сможет читать весь шифрованный поток
данных, направляемый стороне А, и использовать фальсифицированные
ключи для аутентификации своих сообщений.
Проблема решается с помощью сертификатов открытых ключей. По су-
ществу, сертификат состоит из открытого ключа и идентификатора владель-
ца этого ключа, а весь блок подписывается надежной третьей стороной.
1ЛЛ
Часть I. Коиптог афия
Обычно третьей стороной является уполномоченный центр сертификации
(Certificate Authority — СА), пользующийся доверием со стороны сообщества
пользователей — это может быть, например, правительственное агентство
или финансовое учреждение. Пользователь может доставить свой открытый
ключ в уполномоченный центр некоторым защищенным образом и получить
соответствующий сертификат. Затем он может опубликовать полученный
сертификат, и, если открытый ключ данного пользователя кому-либо потре-
буется, последний может получить сертификат и убедиться в его подлинно-
сти, проверив присоединенную подпись надежного источника. Схема всего
процесса показана на рис. 3.12.
Неподписанный сертификат:
содержит идентификатор
пользователя и открытый
Подписанный сертификат:
получатель может проверить подпись
с помощью открытого ключа
центра сертификации
Рис. 3.12. Использование сертификатов открытых ключей
Универсальное распространение получила схема создания сертификатов от-
крытых ключей, основанная на стандарте Х.509. Сертификаты Х.509 использу-
ются в большинстве приложений сетевой защиты, включая IPSec, SSL (протокол
защищенных сокетов), SET (протокол защищенных электронных транзакций), а
также S/MIME (защищенные многоцелевые расширения электронной почты в
Internet), которые будут обсуждаться во второй части книги. Протокол Х.509
подробно рассматривается в главе 4.
Глава 3. Криптография с открытым ключом и аутентификация... 101
Распределение секретных ключей по схеме с открытым
ключом
В схемах традиционного шифрования основным требованием, обеспечиваю-
щим защиту связи двух сторон, является наличие у этих двух сторон общего
секретного ключа. Предположим, что перед Бобом поставлена задача создать
приложение, обеспечивающее ему возможность защищенного обмена электрон-
ными сообщениями с любой из сторон, имеющей доступ к Internet или некото-
рой другой совместно используемой сети. Предположим, что для защиты Боб
решил использовать шифрование на основе традиционной схемы. Но при ис-
пользовании традиционного шифрования Боб и его корреспондент, скажем Али-
са, обязаны найти способ обменяться секретным ключом, который должен оста-
ваться в секрете для всех, кроме них. Как им это сделать? Если Алиса является
сотрудницей Боба, работающей в соседней комнате, то Боб может выбрать ключ,
записать его на листе бумаги или сохранить на дискете и вручить соответствую-
щий носитель информации Алисе. Но если Алиса находится в другой части кон-
тинента или мира, то что делать Бобу в таком случае? Он может зашифровать
ключ, используя методы традиционного шифрования, и переслать его Алисе по
электронной почте, но это значит, что Боб и Алиса должны применить общий
секретный ключ, чтобы зашифровать новый секретный ключ. К тому же и перед
Бобом, и перед всеми остальными, кому придется использовать новый пакет
электронной почты Боба, подобная проблема будет возникать с каждым новым
корреспондентом: любая пара корреспондентов должна использовать свой уни-
кальный секретный ключ.
Одним из решений в данном случае является использование обмена ключа-
ми по методу Диффи-Хеллмана, и это решение действительно широко распро-
странено. Однако недостатком этого метода является то, что в своем самом про-
стом виде алгоритм Диффи-Хеллмана не обеспечивает аутентификацию двух со-
общающихся сторон.
Серьезной альтернативой является использование сертификатов открытых
ключей. Собираясь наладить связь с Алисой, Боб может сделать следующее.
1. Подготовить сообщение.
2. Зашифровать сообщение, используя схему традиционного шифрования и
одноразовый сеансовый ключ.
3. Зашифровать сеансовый ключ, используя схему шифрования с открытым
ключом и открытый ключ Алисы.
4. Прикрепить шифрованный сеансовый ключ к сообщению и переслать его
Алисе.
Только Алиса сможет дешифровать сеансовый ключ и восстановить сообще-
ние в исходной форме. Если Боб получил открытый ключ Алисы из сертификата
открытого ключа, то он может быть уверен, что этот ключ действительно явля-
ется ключом Алисы.
102
Часть I. Криптография
3.7. РЕКОМЕНДУЕМЫЕ ИСТОЧНИКИ
ДОПОЛНИТЕЛЬНОЙ ИНФОРМАЦИИ
Книги, рекомендованные в главе 2, кроме вопросов традиционного шифрования
охватывают и вопросы шифрования с открытым ключом. В [DIFF88] подробно опи-
саны попытки создания защищенных криптографических алгоритмов с двумя клю-
чами и постепенная эволюция протоколов, основанных на таких алгоритмах. Хоро-
шим обзором по криптографии с открытым ключом является [SALO96]. В [CORM90]
вы найдете сжатые, но полные и четкие резюме алгоритмов, касающихся оценки
производительности, верификации и криптоанализа RSA.
CORM90 Cormen, Т., Leiserson, С., and Rivest, R. Introduction to Algorithms.
Cambridge, MA: MIT Press, 1990. <
DIFF88 Diffie, W. “The First Ten Years of Public-Key Cryptography.” Proceedings
of the IEEE, May 1988. Имеется также в [SIMM92].
SALO96 Salomaa, A. Public-Key Cryptography. New York: Springer-Verlag, 1996. j
SIMM92 Simmons, G., ed. Contemporary Cryptology: The Science of Information ;
Integrity. Piscataway, NJ: IEEE Press, 1992.
3.8. ЗАДАЧИ
3.1. Одна из наиболее распространенных схем вычисления значений МАС, называе-
мая алгоритмом аутентификации данных, опирается на использование DES.
Описание этого алгоритма существует и в виде публикации FIPS (PUB
FIPS 113), и в виде стандарта ANSI (Х9.17). Алгоритм можно определить как
шифрование DES в режиме сцепления шифрованных блоков (СВС) с нулевым
вектором инициализации (см. рис. 2.7 в главе 2). Данные (сообщение, запись,
файл или программа), которым требуется аутентификация, представляются в
виде последовательности 64-битовых блоков ?! , Р2 , ..., Р v . При необходимости
последний блок дополняется справа нулями, чтобы образовался полный 64-
битовый блок. Значение МАС представляет собой либо весь блок шифрованного
текста CN , либо крайние слева М битов этого блока, где 16 <М < 64 . Докажите,
что тот же результат может быть получен при использовании режима шифро-
ванной обратной связи (CFB).
3.2. Рассмотрим 32-битовую функцию хэширования, представляющую собой конка-
тенацию двух 16-битовых функций, XOR и RXOR, определенных в разделе 3.1
как “две простые функции хэширования”.
а. Дает ли такая контрольная сумма возможность обнаружить все ошибки, ха-
рактеризующиеся нечетным числом ошибочных битов? Поясните свой ответ.
б. Позволяет ли эта контрольная сумма обнаружить все ошибки, характери-
зующиеся четным числом ошибочных битов? Если нет, опишите структуру
ошибок, которые не будут выявляться такой контрольной суммой.
в. Оцените эффективность данной функции при использовании ее в качестве
функции хэширования для аутентификации сообщений.
3.3. Функцию хэширования можно использовать и для того, чтобы создать блочный
шифр со структурой, подобной DES. Но, поскольку функция хэширования яв-
Глава 3, Криптография с открытым ключом и аутентификация... 103
ляется односторонней, а блочный шифр должен быть обратимым (чтобы его
можно было дешифровать), то как это можно сделать?
3.4. Еще до появления конкретных использующих открытые ключи схем (таких как
RSA) было получено доказательство того, что шифрование с открытым ключом тео-
ретически возможно. Рассмотрим функции = г2 > ^з(хз>Уз)= гз »
где все значения являются целыми числами и 1 < xt, yt . Функция f[ может
быть представлена вектором Ml длины N, в котором /с-й элемент представляет значе-
ние fj(fc). Точно так же f2 и f3 могут быть представлены соответственно матрица-
ми М2 и М3 размера N х N. Целью в данном случае является представление процес-
са шифрования/дешифрования таблицами поиска с очень большими значениями №
Такие таблицы должны быть невообразимо огромными, но, в принципе, возможны-
ми. Схема работает следующим образом. С помощью случайной перестановки всех
целых чисел от 1 до N создается Ml (т.е. каждое целое должно быть представлено в
Ml только один раз). М2 строится так, чтобы каждая строка содержала случайную
перестановку первых N целых чисел. Наконец, М3 заполняется так, чтобы удовле-
творялось следующее условие:
f3(f2(f1(fc),p),<:) = р для всех к и р таких, что l<k,p<N.
Другими словами,
1. Ml получает на вход к и дает на выходе х.
2. М2 получает на вход х и р и дает на выходе z.
3. М3 получает на вход z и к и дает на выходе р.
Эти три таблицы, однажды созданные, открыты для всех.
а. Должно быть ясно, что М3 можно построить так, чтобы удовлетворялось преды-
дущее условие. Для примера заполните М3 в следующем простом случае.
Соглашения. В Ml элемент с номером i соответствует к = /. В М2 строка с номе-
ром i соответствует х = i, а столбец с номером j — р = j. В М3 строка с номером i
соответствует z = /, а столбец с номером j соответствует к = j.
б. Опишите схему применения этих таблиц при шифровании и дешифровании
сообщений в случае обмена данными между двумя сторонами.
в. Докажите, что такая схема является защищенной.
3.5. Опишите шифрование и дешифрование RSA подобно тому, как это сделано на
рис. 3.12, для следующих значений параметров.
а. р = 3',д= ll,d=7;M = 5.
б. p-5,q- 11,е = 3;М = 9.
в. р = 7; q = 11, е = 17; М = 8.
104
Часть I. Криптография
г. р = 11; 9 = 13,е= 11;М = 7.
д. р= 17, <? = 31, е = 7; М = 2.
Указание. Дешифрование здесь является не столь сложным, как вы думае-
те. Используйте некоторую хитрость.
3.6. В криптосистеме с открытым ключом, использующей RSA, вы перехватили шифро-
ванный текст С = 10, пересылаемый пользователю, открытым ключом которого яв-
ляется е = 5, п = 35. Что в данном случае является открытым текстом М?
3.7. В использующей RSA системе открытым ключом некоторого пользователя яв-
ляется е = 31, п = 3599. Что будет личным ключом этого пользователя?
3.8. Предположим, имеется набор блоков, зашифрованных с помощью алгоритма
RSA, но нет соответствующего им личного ключа. Пусть п = pq, е является от-
крытым ключом. Предположим также, что кто-то утверждает, что ему извест-
но, что один из блоков открытого текста и п имеют общий делитель. Дает ли это
какую-либо реальную помощь в данном случае?
3.9. Покажите, как можно представить алгоритм RSA с помощью матриц Ml, М2,
М3 из задачи 3.4.
3.10. Рассмотрите следующую схему.
1. Выбирается нечетное число Е.
2. Выбираются два простых числа Р n Q так, чтобы (Р - 1)(2 - 1) -1 делилось на Е.
3. Значение Р умножается на Q, чтобы в результате получить N.
. т, п (Р-1)(2-1)(Е-1) + 1
Е
Является ли эта схема эквивалентной RSA? Обоснуйте свой ответ.
3.11. Используем алгоритм RSA с известным ключом для построения односторонней
функции хэширования. По следующей схеме выполним обработку сообщения,
складывающегося из последовательности блоков: шифруется первый блок, с
помощью операции XOR результат объединяется со вторым блоком и шифрует-
ся снова и т.д. Докажите, что эта схема недостаточно защищена, решив сле-
дующую задачу. Пусть имеется сообщение, состоящее из двух блоков Bl, В2, и
его хэш-код
RS АН(В 1, В2) = RS A(RS А(В 1) Ф В2).
Для произвольного блока С1 найдите С2, для которого выполняется равенст-
во RSAH(C1,C2) = RSAH(B1, В2).
3.12. Рассмотрите схему Диффи-Хеллмана с общим простым числом q = 11 и первооб-
разным корнем а = 2.
а. Если пользователь А имеет открытый ключ YA = 9 , то каким будет личный
ключ ХА пользователя А?
б. Если пользователь В имеет открытый ключ YB = 3 , то каким будет их общий
секретный ключ К?
Глава 3. Криптография с открытым ключом и аутентификация... 105
ДОПОЛНЕНИЕ 3.1. ПРОСТЫЕ ЧИСЛА
И АРИФМЕТИКА В КЛАССАХ ВЫЧЕТОВ
В этом дополнении мы представляем два понятия, используемые в данной
главе, — простые числа и арифметику в классах вычетов.
Простые и взаимно простые числа
В этом разделе, если не отмечено особо, мы будем иметь дело с неотрица-
тельными целыми числами. Рассмотрение отрицательных целых чисел практи-
чески не меняет представленные здесь рассуждения.
Делители
Говорят, что отличное от нуля число b делит а, если а = mb рлм некоторого
т, где а, b и т являются целыми числами. Таким образом, b делит а, если при
делении не получается остатка. Для обозначения того факта, что b делит а, часто
используется запись Ь\а . Если Ь\а , то b называют делителем а. Например, по-
ложительными делителями числа 24 являются числа 1, 2, 3, 4, 6, 8, 12 и 24.
Имеют место следующие утверждения.
• Если а 11, то а = ±1.
• Если Ь\а и а\Ь , то а - ±Ь.
• Любое отличное от нуля число b делит 0.
• Если b\g и b\h , то b\(mg + nh) для произвольных целых т и п.
Чтобы убедиться в истинности последнего утверждения, обратите внимание на
следующее:
• если b\ g , то g имеет вид g=bxgx для некоторого целого gj,
• если b\h , то h имеет вид g -byfi-t для некоторого целого hx,
поэтому
mg + nh = mbg{ + nbh^ = bx (mg{ + п/ц'),
следовательно, b делит mg + nh.
Простые числа
Целое число р> 1 называется простым, если его делителями являются толь-
ко числа ±1 и ±р. Простые числа играют основную роль в теории чисел и их
свойства лежат в основе методов, обсуждаемых в данной главе.
Любое целое число а > 1 может быть разложено на множители и единствен-
ным способом представлено в виде
с^р^-.р?,
где рх< р2<-.< pt являются простыми числами и каждое а(>0. Например,
91 = 7 х 13, а 11011 = 7х112Х13 .
Для дальнейшего обсуждения будет полезно упомянуть следующее, немного
отличное от приведенного выше представление числа. Если через Р обозначить
106
Часть I. Криптография
множество всех простых чисел, то любое положительное целое число можно
единственным способом представить в виде
а = PJ рПр , где все ар>0.
р
В этой формуле выражение справа от знака равенства означает произведение по
всем возможным простым числам р. При этом большинство значений показателя
ар оказываются равными 0.
Значение любого положительного целого числа может быть однозначно за-
дано простым перечислением всех ненулевых показателей в предыдущей форму-
ле. Например, целое число 12 можно представить как {а2=2, а3=1}, а целое
число 18 — как {а2=1, а3 = 2}. Умножение двух чисел эквивалентно сложению
значений соответствующих показателей:
к = пт кр= тр + пр для всех р.
Что же тогда означает а | b ? Любое целое число вида рК может делиться
только на целое число, которое является степенью того же простого числа р с
показателем, не превышающим к, т.е. на pJ с j<k . Таким образом,
а\Ь —> ар<Ьр для всех р.
Взаимно простые числа
Мы будем использовать запись нод(а, Ь) для обозначения наибольшего об-
щего делителя чисел а и Ь. Говорят, что положительное целое число с является
наибольшим общим делителем чисел а и Ь, если
• число с является делителем и а, и Ь;
• любой делитель а и b является делителем с.
Эквивалентным этому оказывается следующее определение.
нод(а,b) = max [Л такие, что к\а и к\Ь].
Поскольку требуется, чтобы наибольший общий делитель был положительным,
получаем следующие равенства: нод(а, Ь~) = нод(а, -Ь) = нод(-а, Ь) = нод(-а, -Ь). Вооб-
ще, нод(а, Ь) = нод(| а |, | b |). Например, нод(60, 24) = нод(60,-24) = 12. Кроме того, по-
?:ольку все ненулевые целые числа делят 0, имеет место равенство нод(п, 0) = |п|.
Легко определить наибольший общий делитель двух положительных целых
лсел, если эти числа представлены в виде произведения простых множителей.
Например,
300 = 22хЗ'х52,
18 = 2'хЗ2,
нод(18,300) = 21х31х5° = 6.
: общем случае
к = нол.(а, b) —> кр= min(ap, bp) для всех р.
пава 3. Криптография с открытым ключом и аутентификация... 107
Определение простых множителей больших чисел является непростой зада-
чей, так что представленное выше соотношение не дает непосредственной прак-
тической возможности вычислить наибольший общий делитель двух чисел.
Целые числа а и b являются взаимно простыми, если они не имеют общих
простых делителей, т.е. если их единственным общим делителем является 1.
Другими словами, а и b являются взаимно простыми, если нод(а, b~)= 1. Напри-
мер, числа 8 и 15 являются взаимно простыми, поскольку делителями числа 8
являются 1, 2, 4 и 8, а делителями числа 15 — 1, 3, 5 и 15, так что 1 оказыва-
ется единственным числом, присутствующим в обоих списках.
Арифметика в классах вычетов
Для любого положительного целого числа п и любого целого а при делении
а на п мы получим некоторое целое частное q и остаток г, удовлетворяющие со-
отношению
a = qn + r, 0<r<n; q=[a/nj,
где [xj обозначает наибольшее целое число, не превышающее х. Остаток г обыч-
но называют вычетом.
Если а является целым, ап — положительным целым, то amodn определя-
ется как остаток от деления а на п. Таким образом, для любого целого числа а
можно записать
a = |_n/njxn + (a mod п).
Говорят, что два целых числа а и b являются сравнимыми по модулю п, ес-
ли (a mod п) = (Ь mod п). Это записывается так: a = b mod п . Например, 73 = 4 mod
23, а 21 = -9 mod 10. Обратите внимание на то, что если a = 0modn , то п\а .
Операция сравнения по модулю имеет следующие свойства.
1. a =b mod п , когда п | (а -Ь).
2. Из (a mod п) = (b mod п) следует а = b mod п .
3. Из a=b mod п следует b = a mod п .
4. Из a=b mod п и b = с mod п следует а = с mod п .
Чтобы убедиться в истинности первого из этих свойств, обратите внимание на
то, что из соотношения п\(а-Ь) следует, что (а - Ь)= кп для некоторого к. Поэтому
а = b + кп. Таким образом, (a mod п) = (остаток от деления b + кп на п) = (остаток от
деления b на п) = (b mod п). Остальные свойства доказываются так же легко.
Сравнение по модулю п отображает множество всех целых чисел во множе-
ство {0, 1, (п- 1)}. При этом возникает вопрос: можно ли определить арифме-
тические операции в рамках данного множества? Оказывается, можно, и соот-
ветствующий набор операций называется арифметикой в классах вычетов.
Операции арифметики в классах вычетов обладают следующими свойствами.
1. [(a mod п) + (b mod и)] mod п = (а + b) mod п .
2. [(а mod п) - (b mod п)] mod п = (а -b) mod п .
3. [(а mod п) х (b mod п)] mod п = (a xb) mod п .
108
Часть I. Криптография
Докажем, например, что выполняется первое из этих свойств. Пусть
(a mod п) = га и (а mod п) = гь . Тогда а = ra + jn для некоторого целого числа j и
b = гь + кп для некоторого целого числа к. Поэтому
(а + b) mod п = (ra + jn + rb + кп) mod п
= (ra +rb+ (J + mod п
= (ra + rb) mod «
= [(a mod п) + (b mod и)] mod п.
Остальные свойства доказываются так же легко.
Глава 3. Криптография с открытым ключом и аутентификация... 109
This page intentionally left blank
Приложения
сетевой защиты
Во второй части книги будут рассмотрены важнейшие
средства сетевой защиты и соответствующие приложения,
которые могут использоваться в рамках отдельной сети,
корпоративной сетевой структуры или Internet.
Глава 4. Приложения аутентификации
В главе 4 описаны два наиболее важных и популяр-
ных на сегодняшний день стандарта аутентификации.
Kerberos представляет собой протокол аутентификации,
опирающийся на средства традиционного шифрования,
получивший широкую поддержку и используемый во
многих системах. Х.509 определяет алгоритм аутенти-
фикации и процедуру сертификации. Процедура серти-
фикации дает пользователям возможность получать сер-
тификаты открытых ключей, что обеспечивает сообще-
ству пользователей средство проверки подлинности
открытых ключей. Эта процедура используется в качест-
ве строительного блока для целого ряда приложений.
Глава 5. Защита электронной почты
Самым распространенным распределенным приложе-
нием является электронная почта, поэтому растет потреб-
ность в средствах аутентификации и обеспечения конфи-
денциальности в рамках электронной почты. В главе 5 рас-
смотрены два подхода, которые, скорее всего, будут
доминировать в области защиты электронной почты в бли-
жайшем будущем. Первый подход использует систему PGP
(Pretty Good Privacy — достаточно надежная секретность),
представляющую собой популярную схему, не являющуюся
собственностью какой-либо частной организации или госу-
дарственной структуры. Поэтому эта схема подходит как
для индивидуального пользования, так и для применения в
сетях организаций. Второй схемой является S/MIME
(Secure/Multipurpose Internet Mail Extensions — защищен-
ные многоцелевые расширения электронной почты в сети
Internet), которая была разработана специально для того,
чтобы играть роль стандарта Internet.
Глава 6. Защита IP
Протокол IP (Internet Protocol — протокол межсетевого взаимодействия)
является центральным компонентом Internet и большинства частных сетей. Со-
ответственно и защита на уровне IP является очень важным элементом любой
предполагающей межсетевое взаимодействие схемы защиты. В главе 6 рассмат-
ривается схема защиты IP, разработанная для работы как с используемой сего-
дня версией IP, так и с разрабатываемой версией IP следующего поколения, из-
вестной под названием IPv6.
Глава 7. Защита Web
Растущая популярность World Wide Web (WWW — всемирная паутина, со-
брание гипертекстовых и иных документов, доступных по всему миру через сеть
Internet) как средства ведения электронного бизнеса и как средства распростра-
нения информации требует создания очень надежных рубежей защиты Web. В
главе 7 предлагается обзор этой новой, но весьма важной сферы защиты, вклю-
чающий обсуждение двух соответствующих стандартов: SSL (Secure Sockets
Layer — протокол защищенных сокетов) и SET (Secure Electronic Transactions —•
протокол защищенных электронных транзакций).
Глава 8. Защита средств сетевого управления
С ростом популярности систем сетевого управления, с помощью которых можно
управлять разнородными сетями, растет спрос на соответствующие средства защиты.
В главе 8 основное внимание уделяется самой распространенной схеме управле-
ния — SNMP (Simple Network Management Protocol — простой протокол сетевого
управления). Версия 1 протокола SNMP имеет только элементарные средства аутен-
тификации, построенные на использовании паролей. SNMPv2 имеет более широкие
возможности, a SNMPv3 предлагает вполне развитые средства защиты, обеспечи-
вающие конфиденциальность и аутентификацию, которые можно использовать в со-
четании с возможностями SNMPvl или SNMPv2.
112
Часть II. Приложения сетевой защиты
4
ГЛАВА
Приложения
аутентификации
4.1. Система Kerberos
4.2. Сервис аутентификации Х.509
4.3. Рекомендуемые источники дополнительной
информации
4.4. Задачи
Дополнение 4.1. Технология шифрования Kerberos
В этой главе рассматриваются две схемы аутентификации, предназначен-
ные для поддержки аутентификации и цифровых подписей на приклад-
ном уровне.
Сначала мы изучим одну из первых и наиболее распространенных схем, извест-
ную под названием Kerberos. Затем будет описан сервис аутентификации Х.509. Этот
стандарт является не только важной составляющей службы каталогов, которую он
поддерживает, но и основой строительного блока, используемого в рамках других
стандартов, в частности S/MIME, речь о котором пойдет в главе 5.
4.1. СИСТЕМА KERBEROS
Система Kerberos1 является службой аутентификации, разработанной в
рамках проекта Athena в Массачусетсском технологическом институте (МТИ).
Проблема, которую призвана решить система Kerberos, состоит в следующем.
Предположим, что имеется открытая распределенная среда, в которой пользова-
тели со своих рабочих станций должны иметь возможность доступа к сервисам,
предоставляемым серверами сети. Желательно, чтобы к серверам могли полу-
чать доступ только зарегистрированные пользователи и серверы могли аутенти-
фицировать запросы к сервисам. В такой среде сами рабочие станции не могут
идентифицировать пользователей по следующим причинам.
• Пользователь может получить доступ к рабочей станции и выдать себя за
другого пользователя этой рабочей станции.
• Пользователь может изменить сетевой адрес рабочей станции, чтобы запро-
сы, посылаемые с измененной рабочей станции, казались исходящими от
другой рабочей станции.
• Пользователь может перехватить пересылаемые сообщения и воспроизвести
их впоследствии, чтобы получить доступ к серверу или внести искажения в
поток данных.
В любом из этих случаев неуполномоченный пользователь может получить
доступ к службам и данным, на который у него нет прав. Вместо построения
сложных протоколов аутентификации на каждом сервере система Kerberos пред-
лагает использовать центральный сервер аутентификации для идентификации
пользователей для серверов и серверов для пользователей. В отличие от других
схем аутентификации, описываемых в этой книге, Kerberos использует исклю-
чительно традиционное шифрование, а не шифрование с открытым ключом.
П опулярны две версии Kerberos. Все еще широко распространена версия 4
[MILL88, STEI88]. В версии 5 [KOHL94] были исправлены некоторые недостатки *
1иВ греческой мифологии это многоголовый пес (обычно трехголовый), часто с хво-
стом змеи, охраняющий вход в царство мертвых Аида”, — утверждается в Словаре
терминов и символов искусства Джеймса Холла (Dictionary of Subjects and Symbols in
Art, James Hall, Harper & Row, 1979). Точно так же, как греческий Kerberos (Кербер, или
Цербер) имеет три головы, современная система Kerberos должна была иметь три ком-
понента защиты шлюза сети: аутентификацию, учет (использования ресурсов) и ау-
дит. Последние две “головы" системы так и не были реализованы.
114 Часть II. Приложения сетевой защиты
защиты версии 4, и эта версия имеет статус проекта стандарта Internet
(RFC 1510).2
В следующем разделе представлен краткий обзор целей, положенных в ос-
нову разработки системы Kerberos. После этого ввиду сложности системы
Kerberos дается описание протокола аутентификации, используемого в версии 4.
Это позволит нам понять сущность стратегии Kerberos без учета некоторых дета-
лей, необходимых для противостояния весьма хитроумным угрозам защиты. За-
тем будет рассмотрена версия 5.
Цели разработки
Если группа пользователей обеспечена отдельными персональными компью-
терами, которые не подключены к сети, то ресурсы и файлы каждого пользова-
теля могут быть защищены путем физической защиты каждого персонального
компьютера. Но когда пользователи обслуживаются централизованной системой
с разделением времени, защиту должна обеспечить операционная система с раз-
делением времени. Операционная система может вводить в действие политики
контроля доступа, основанные на идентификации пользователей и использова-
нии процедур входа в систему для идентифицированных пользователей.
В настоящее время указанные схемы нельзя назвать типичными. Чаще ис-
пользуется распределенная архитектура, включающая выделенные рабочие
станции пользователей (клиенты) и распределенные или централизованные сер-
веры. В такой среде можно использовать следующие три стратегии защиты.
1. Возложить задачу аутентификации пользователей на индивидуальные рабо-
чие станции-клиенты, а от серверов потребовать реализацию соответствую-
щей политики защиты на основании идентификатора пользователя (ID).
2. Требовать, чтобы клиенты при обращении к серверам проходили процедуру ау-
тентификации, а идентификацию пользователей доверить системе клиента.
3. Требовать, чтобы пользователи предъявляли идентифицирующие их данные
при каждом вызове сервиса, а серверы предъявляли идентифицирующие их
данные клиентам.
В закрытой и не слишком обширной среде, где все системы принадлежат
эдной организации, подходящей может оказаться первая или вторая из этих
этратегий защиты.3 Но в открытых средах, где поддерживаются сетевые соеди-
нения с другими системами, необходимо использовать третий подход, чтобы за-
щитить и информацию пользователя, и ресурсы, размещенные на сервере. Сис-
тема Kerberos предлагает именно третий подход, поддерживая распределенную
архитектуру клиент/сервер при использовании одного или нескольких серверов
Kerberos, обеспечивающих аутентификацию.
В первом из опубликованных сообщений о системе Kerberos [STEI88] были
перечислены следующие требования к ней.
2 Версии 1-3 создавались разработчиками для внутреннего использования. Поэто-
•у версию 4 можно назвать “оригинальной” версией системы Kerberos.
3 Тем не менее, даже в закрытой среде остается угроза нарушения защиты со
-.ороны неудовлетворенного чем-либо служащего.
'лава 4. Приложения аутентификации 115
• Защита. Противник, перехватывающий сообщения в сети, не должен получить
информацию, необходимую для имитации другого пользователя. Другими сло-
вами, система Kerberos должна быть достаточно сильной, чтобы потенциальный
противник не имел оснований считать ее слабым звеном сети.
® Надежность. Для всех сервисов, использующих для контроля доступа
Kerberos, недоступность системы Kerberos означает недоступность соответ-
ствующего сервиса. Поэтому система Kerberos должна быть достаточно на-
дежной и использовать распределенную серверную архитектуру, где одна
система способна заменить другую.
• Прозрачность. В идеале пользователь не должен замечать работу процедуры
аутентификации, кроме тех случаев, когда от него требуется ввести пароль.
• Масштабируемость. Система должна поддерживать большое число клиентов
и серверов. Это предполагает модульную распределенную архитектуру.
Kerberos представляет собой сервис аутентификации, выполняемый надеж-
ной третьей стороной с помощью протокола, в основе которого лежит схема
Нидхэма-Шредера [NEED 78]. Надежность в данном случае означает, что клиен-
ты и серверы доверяют системе Kerberos посредничество в осуществлении их
взаимной аутентификации. Если предположить, что протокол Kerberos не со-
держит ошибок реализации, сервис аутентификации оказывается защищенным,
если только защищен сам сервер Kerberos.4
Kerberos версии 4
В Kerberos версии 4 для аутентификации применяется достаточно проверенный
протокол, использующий DES. Рассматривая этот протокол в целом, понять необхо-
димость многих из содержащихся в нем элементов совсем непросто. Поэтому мы
воспользуемся стратегией Билла Брайента (Bill Bryant) [BRYA88] и пред тем, как
перейти к описанию реального протокола, рассмотрим несколько гипотетических
диалогов. Каждый последующий диалог будет сложнее предыдущего ввиду добавле-
ния элементов защиты от угроз, не учтенных предыдущей схемой.
Рассмотрев сам протокол, мы обсудим некоторые другие аспекты
Kerberos версии 4.
4 Защищенность сервера Kerberos не предполагается автоматически, а должна
обеспечиваться со всемм предосторожностями (например, с помощью размещения его в
отдельном закрытом помещении). В этой связи не мешает вспомнить судьбу греческого
Кербера, которого должен был привести Геракл по приказу Эврисфея, чтобы совершить
одиннадцатый подвиг: “Геракл увидел огромного пса на цепи и обхватил своими руками
его шею. Три головы пса пытались укусить Геракла, а хвост Кербера обвил тело героя.
Но Геракл все сильнее сжимал псу горло, пока полузадушенный пес не упал в беспамят-
стве. Эврисфей очень удивился, увидев Геракла живым, возвращающимся с огромным и
страшным трехголовым псом с капающей из пастей слюной. Перепуганный Эврисфей
спрятался за большой бронзовой дверью, оставив лишь маленькую щель" (из Краткого
словаря греческой и римской мифологии Майкла Стэплтона (Hamlyn Concise Dictionary
of Greek and Roman Mythology, Michael Stapleton, Hamlyn, 1982)).
116
Часть II. Приложения сетевой защиты
Простой диалог аутентификации
В незащищенной сетевой среде любой клиент может обратиться к сервису
любого сервера. При этом очевидным риском является возможность со стороны
клиента имитировать другое лицо. Противник может выдать себя за другого
клиента, чтобы получить необоснованные привилегии на сервере. Для противо-
стояния такой угрозе серверы должны иметь возможность идентифицировать за-
прашивающих услуги клиентов. Это может потребоваться для любого сервера
при любом взаимодействии клиента и сервера, и в открытой среде для каждого
сервера это означает немалую дополнительную нагрузку.
Альтернативой этому является использование сервера аутентификации, ко-
торому известны пароли всех пользователей и который хранит эти пароли в цен-
трализованной базе данных. Кроме того, для обмена данными между сервером
аутентификации и любым другим сервером используется секретный ключ, уни-
кальный для каждого из таких серверов. Секретные ключи предполагается рас-
пределять физически или некоторым другим надежно защищенным способом.
Рассмотрим следующий гипотетический диалог.
Д) С—>AS: IDCI|PCI|IDV ,
>2) AS—>С: Мандат,
-3) С—>V: IDC ||Мандат,
Мандат = ЕКу [IDC || ADC || IDV],
где
С — клиент,
AS — сервер аутентификации,
V — сервер,
IDC — идентификатор пользователя системы С,
IDV — идентификатор V,
Рс — пароль пользователя системы С,
ADC — сетевой адрес С,
Kv — секретный ключ шифрования, используемый совместно AS и V,
|| — конкатенация.
3 этом сценарии пользователь входит в систему рабочей станции и запрашивает
доступ к серверу V. Модуль клиента С на рабочей станции пользователя запра-
шивает пароль пользователя, а затем посылает сообщение серверу AS, вклю-
чающее идентификатор пользователя, идентификатор сервера и пароль пользо-
зателя. Система AS использует свою базу данных, чтобы проверить, предоставил
чи пользователь пароль, соответствующий данному идентификатору, и разрешен
чи этому пользователю доступ к серверу V. Если проверка обоих параметров за-
вершается успешно, сервер AS считает пользователя идентифицированным и
должен убедить в этом сервер. Для этого сервер AS создает мандат, содержащий
идентификатор пользователя и его сетевой адрес, а также идентификатор серве-
ра. Мандат шифруется секретным ключом, общим для сервера AS и сервера V.
Мандат отправляется обратно системе С. Поскольку мандат шифруется, его не
может изменить ни клиент С, ни противник.
С этим мандатом С может теперь обратиться к V за сервисом. Для этого С
досылает серверу V сообщение, содержащее идентификатор С и полученный
Глава 4. Приложения аутентификации 117
мандат. Система V дешифрует мандат и убеждается, что идентификатор пользо-
вателя в мандате совпадает с незашифрованным идентификатором пользователя
в сообщении. Если эти идентификаторы совпадают, сервер считает пользователя
идентифицированным и предоставляет требуемый сервис.
В сообщении (3) существенным оказывается каждый элемент. Мандат шиф-
руется, чтобы сделать невозможными модификацию и фальсификацию. Иденти-
фикатор сервера (EDV ) включается в мандат, чтобы сервер мог проверить, что
мандат дешифрован должным образом. Идентификатор EDC включается в ман-
дат для того, чтобы показать, что этот мандат был выдан по запросу С. Наконец,
сетевой адрес ADC присутствует в мандате для того, чтобы противостоять сле-
дующей угрозе. Противник может перехватить мандат, пересылаемый сообщени-
ем (2), а затем, используя имя IDC, передать сообщение вида (3) с другой рабо-
чей станции. Сервер при этом получит правильный мандат, в котором совпадут
идентификаторы пользователя, и поэтому разрешит доступ этому пользователю с
другой рабочей станции. Чтобы предотвратить возможность такой атаки, сервер
AS включает в мандат сетевой адрес, с которого пришел исходный запрос. Те-
перь мандат будет действителен, только если он был отправлен с той рабочей
станции, с которой мандат был изначально запрошен.
Более защищенный диалог аутентификации
Предыдущий сценарий справляется с некоторыми проблемами аутентифи-
кации в открытой сетевой среде, но решенными оказываются не все. Из нере-
шенных проблем можно выделить следующие. Во-первых, желательно миними-
зировать число запросов пароля у пользователя. Предположим, что каждый
мандат может применяться только один раз. Если пользователь С входит в сис-
тему рабочей станции утром с целью проверки своей почты на почтовом сервере,
С должен предъявить пароль, чтобы получить мандат для работы с почтовым
сервером. Если С потребуется проверить почту еще несколько раз в течение дня,
каждая попытка потребует повторного ввода пароля. Можно упростить процеду-
ру, предложив мандаты многократного использования. Рабочая станция может
хранить мандат почтового сервера в течение всего времени одного сеанса связи
после первого ввода пароля и использовать этот пароль от имени пользователя
при повторных попытках доступа к почтовому серверу.
Однако и в рамках этой схемы пользователю придется получить новый
мандат при обращении к новой службе сервера. Если пользователю потребуется
доступ к серверу печати, почтовому, файловому серверу и так далее, при первом
доступе к каждой службе будет требоваться новый мандат, поэтому пользовате-
лю снова придется вводить пароль.
Второй проблемой является то, что предыдущий сценарий предполагает пе-
редачу пароля в виде открытого текста (сообщение 1). Перехватчик может полу-
чить пароль, а с ним — возможность использовать любую службу, доступ к ко-
торой разрешен “жертве”.
Чтобы решить эти проблемы, рассмотрим схему, позволяющую избежать
пересылки паролей в открытом виде. В рамках этой схемы используется новый
сервер, называемый сервером TGS (Ticket-Granting Server — сервер выдачи ман-
датов). Соответствующий новый, но все еще гипотетический сценарий будет
иметь следующий вид.
118
Часть II. Приложения сетевой защиты
Выполняется один раз в ходе сеанса доступа:
(1) С—>AS: IDc||IDtgs
(2) AS—>С: ЕКс [Мандат^]
Выполняется один раз для каждого сервиса:
(3) С -> TGS: Юс || IDV || Мандат,^
(4) TGS—>С: Мандату
Выполняется один раз для каждого сеанса использования сервиса:
(5) С—>V: Юс || Мандату
Мандат^ =EKtgJIDc || ADC || IDtgs || TSj ||CpoKj]
Мандату = EKy [IDC || ADC || IDV || TS2 || Срок2]
Этот новый сервер (TGS) выдает мандаты пользователям, которые были
идентифицированы сервером аутентификации (AS). Таким образом, пользователь
сначала запрашивает мандат на получение мандата (Мандат( ) у сервера аутен-
тификации AS. Этот мандат сохраняется модулем клиента в системе рабочей
:танции пользователя. Каждый раз, когда пользователю требуется новый сервис,
?:лиент обращается к серверу TGS и использует этот мандат для аутентифика-
ции. В ответ TGS выдает мандат на получение конкретного сервиса. Клиент со-
храняет мандат на получение сервиса и использует его для аутентификации сво-
-70 пользователя сервером всякий раз, когда запрашивается данный сервис. Да-
вайте рассмотрим детали этой схемы.
1. Клиент от имени пользователя запрашивает мандат на получение мандата,
посылая серверу аутентификации AS идентификатор пользователя вместе с
идентификатором TGS, что означает запрос на использование сервиса TGS.
2. Сервер аутентификации AS в ответ посылает мандат, шифрованный клю-
чом, который генерируется на основе пароля пользователя. Когда ответ дос-
тавляется клиенту, клиент запрашивает у пользователя пароль, затем гене-
рирует ключ и пытается дешифровать поступившее сообщение. Если был
введен соответствующий пароль, мандат восстанавливается успешно.
Поскольку пароль должен знать только соответствующий пользователь,
- лько он и сможет восстановить мандат. Так пароль используется для получе-
:я удостоверений от Kerberos без пересылки самого пароля в открытом виде,
м мандат при этом состоит из идентификатора и сетевого адреса пользователя,
. также идентификатора TGS. Это соответствует первому сценарию. Идея заклю-
’ -тся в том, что клиент использует этот мандат при запросах мандатов много-
тного доступа к службам. Итак, мандат на получение мандата должен пред-
: тагать многократное применение. Однако желательно, чтобы противник не
I . 7.т возможности перехватить такой мандат и использовать его. Рассмотрим
-дующий сценарий. Противник перехватывает мандат и ждет, когда пользова-
~ ь со своей рабочей станцией выйдет из сети. Противник может либо получить
1д туп к соответствующей рабочей станции, либо соответствующим образом на-
I :ить свою рабочую станцию — назначить ей сетевой адрес, совпадающий с
I ;зым адресом жертвы. Затем противник может применить перехваченный
L, -дат и обмануть TGS. Чтобы исключить такую возможность, в мандат вклю-
t ':я штамп даты-времени (указывающий дату и время выдачи мандата), а
за 4. Приложения аутентификации
119
также информация о сроке действия мандата (например, восемь часов). Таким
образом, клиент теперь имеет мандат многократного использования и возмож-
ность не запрашивать пароль пользователя при каждом новом запросе сервиса.
Наконец, обратите внимание на то, что мандат на получение мандата шифруется
секретным ключом, известным только AS и TGS, что предотвращает возмож-
ность несанкционированного изменения мандата. Мандат повторно шифруется
ключом, зависящим от пароля пользователя, что гарантирует возможность вос-
становления мандата только соответствующим пользователем, а это, соответст-
венно, обеспечивает аутентификацию.
Теперь, когда клиент имеет мандат на получение мандата, доступ к любому
серверу может быть открыт в результате выполнения следующих двух шагов.
3. Клиент от имени пользователя запрашивает мандат на получение сервиса.
Для этого клиент отправляет серверу TGS сообщение, содержащее иденти-
фикатор пользователя, идентификатор требуемого сервиса и мандат на по-
лучение мандата.
4. Сервер TGS дешифрует поступивший мандат и проверяет правильность де-
шифрования по наличию своего идентификатора. Затем проверяется, что
срок действия мандата не истек. После этого с поступившей информацией
сравниваются идентификатор пользователя и сетевой адрес, чтобы выпол-
нить аутентификацию пользователя. Если пользователю разрешен доступ к
серверу V, сервер TGS выдает мандат на получение требуемого сервиса.
Мандат на получение сервиса имеет ту же структуру, что и мандат на полу-
чение мандата. Действительно, поскольку TGS является сервером, аутентифика-
ция клиента для TGS и аутентификация клиента для сервера приложений могут
выполняться по одной и той же схеме. Такой мандат тоже содержит метку даты-
времени и информацию о сроке действия. Если пользователю снова потребуется
тот же сервис, клиент может использовать ранее полученный мандат и не беспо-
коить пользователя из-за пароля. Обратите внимание на то, что мандат шифру-
ется секретным ключом (Kv), известным только TGS и соответствующему серве-
ру, что обеспечивает защиту от несанкционированного изменения мандата.
Имея мандат, клиент может получить соответствующий сервис, выполнив
следующие действия.
5. Клиент от имени пользователя запрашивает сервис. Для этого он передает
серверу сообщение, содержащее идентификатор пользователя и мандат на
получение соответствующего сервиса. Сервер выполняет аутентификацию на
основе содержимого этого мандата.
Этот новый сценарий удовлетворяет двум следующим требованиям: только
один запрос пароля пользователя за сеанс и защита пароля пользователя.
Диалог аутентификации версии 4
Хотя предыдущий сценарий усовершенствует защиту по сравнению с пер-
вым, остаются нерешенными еще две проблемы. Сутью первой проблемы являет-
ся срок действия, связываемый с мандатом на получение мандата. Если этот
срок оказывается слишком коротким (минуты), то вскоре пароль будет запрошен
у пользователя снова. Если срок будет слишком длинным (часы), то противник
120
Часть II. Приложения сетевой защиты
получит больше возможностей для проведения атак воспроизведения сообщений.
Противник может, наблюдая за потоком данных в сети, перехватить экземпляр
мандата на получение мандата, дождаться выхода из сети законного пользовате-
ля, фальсифицировать его сетевой адрес и послать серверу TGS сообщение, ука-
занное в п. 3. Это откроет противнику путь к ресурсам и файлам, доступным со-
ответствующему законному пользователю.
Аналогично, перехватив мандат на получение сервиса и используя его до
истечения срока действия этого мандата, противник получит доступ к соответст-
вующей службе.
Таким образом, мы должны сформулировать следующее дополнительное
требование. Сетевая служба (TGS или сервер приложений) должна иметь воз-
можность убедиться в том, что пользователь, применяющий мандат, является
пользователем, которому этот мандат был выдан.
Вторая проблема заключается в том, что может возникать необходи-
мость идентификации серверов для пользователей. Без такой идентификации
противник может обойти конфигурацию и направить сообщение серверу в
другую точку сети. Фальшивый сервер при этом получит возможность дейст-
вовать от имени реального, перехватывать любую информацию, идущую от
пользователя, и, например, отказывать пользователю в доступе к службам,
на которые тот имеет право.
Мы рассмотрим эти проблемы по порядку, обратившись к табл. 4.1, в кото-
рой представлено описание реального протокола Kerberos.
Сначала рассмотрим проблему перехвата мандатов на получение мандата и не-
обходимость гарантии того, что предъявивший мандат объект является клиентом,
которому этот мандат был выдан. Угроза здесь заключается в том, что противник
может похитить мандат и использовать его до истечения срока действия этого ман-
дата. Чтобы разобраться с проблемой, предположим, что AS каким-то защищенным
способом передает некоторую секретную информацию как клиенту, так и TGS. Тогда
клиент может идентифицировать себя для TGS, предъявив (снова некоторым защи-
щенным способом) расшифровку этой секретной информации. Эффективным в этом
случае оказывается применение в качестве секретной информации ключа шифрова-
ния — в системе Kerberos он называется сеансовым ключом.
Таблица 4.1. Обмен сообщениями по протоколу Kerberos версии 4
а) обмен службы аутентификации: получение мандата на получение мандата
1) С —»AS: IDC || IDtgs || TSj
2) AS —» С: EKc(Kc tgs || IDtgs || TS2 || Срок, || Мандат^,.]
Мандат^ = EKtgs [Кс tgs || IDC || ADC || IDtgs || TS2 || Срок2]
б) обмен службы выдачи мандатов: получение мандата на получение сервиса
3) С —> TGS : IDV || Мандат^ || Аутентификаторс
4) TGS —»С: ЕКс tgs[Kc>v IIIDV II TS4 || Мандату]
Мандатtgs = EKtgs [Kc>tgs || IDC || ADC || IDtgs || TS, || Срок2]
Мандату = ЕКу [К<- v || IDC || ADC || IDV || TS4 || Срок4]
Аутентификаторс = ЕКс [IDC || ADC || TS3]
. лава 4. Приложения аутентификации
121
Окончание табл. 4.1
в) обмен аутентификации клиента/сервера: получение сервиса
(5) С—>К: Мандату II Аутентификаторс
(6) К—>С: EKcv(TS5+1] (для взаимной аутентификации)
Мандату = ЕКу [Kc>v || IDC || ADC || IDV || TS4 || Срок4]
Аутентификаторс = ЕКс [1DC || ADC || TS5]
В табл. 4.1, а показан сценарий доставки сеансового ключа. Как и прежде,
клиент посылает серверу аутентификации (AS) сообщение с запросом о разрешении
доступа к серверу TGS. Сервер AS отвечает содержащим мандат сообщением, которое
зашифровано ключом, создаваемым на основе пароля пользователя (Кс). Это шиф-
рованное сообщение содержит также экземпляр сеансового ключа Кс tgs, где индексы
указывают на то, что это сеансовый ключ для С и TGS. Поскольку этот сеансовый
ключ находится внутри сообщения, зашифрованного с помощью Кс, только клиент
пользователя сможет прочесть его. Тот же сеансовый ключ включается и в мандат,
который может быть прочитан только TGS. Таким образом осуществляется защи-
щенная передача сеансового ключа системам С и TGS.
Прежде чем продолжить изучение схемы, обратите внимание на то, что в
первой фазе диалога было добавлено несколько дополнительных элементов. Со-
общение (1) включает теперь штамп даты-времени, чтобы сервер AS имел воз-
можность проверить, что данное сообщение соответствует текущему времени.
Сообщение (2) включает некоторые элементы мандата в форме, понятной систе-
ме С. Они позволяют системе С выяснить срок действия полученного Мандата и
убедиться в том, что мандат предназначен для TGS.
Вооружившись мандатом и сеансовым ключом, С теперь имеет возмож-
ность обратиться к TGS. Как и прежде, С посылает TGS сообщение, вклю-
чающее мандат и идентификатор требуемого сервиса (сообщение (3) в
табл. 4.1, б). Кроме того, С посылает аутентификатор, включающий иденти-
фикатор пользователя, адрес пользователя и штамп даты-времени. В отличие
от мандата, предполагающего многократное использование, аутентификатор
предлагается использовать только один раз, и срок его действия весьма огра-
ничен. Сервер TGS может дешифровать мандат с помощью ключа, исполь-
зуемого совместно с сервером AS. Мандат указывает на то, что сеансовый
ключ KCtos пользователю С был доставлен. По сути, мандат говорит:
“Любого, кто использует KCtt,s, следует принимать за С”. Система TGS с по-
мощью сеансового ключа дешифрует аутентификатор. Теперь TGS может
сравнить имя и сетевой адрес, содержащиеся в аутентификаторе, с соответст-
вующими элементами мандата и с сетевым адресом поступившего сообщения.
Если все оказывается в полном соответствии, TGS заключает, что отправите-
лем мандата является истинный владелец мандата. Аутентификатор как бы
заявляет: “Со времени TS3 будет использоваться KCt„s”. Обратите внимание
на то, что мандат никого не идентифицирует, а обеспечивает способ защи-
щенного распределения ключей. Задачу аутентификации клиента выполняет
аутентификатор. Поскольку аутентификатор может использоваться только
один раз и имеет короткий срок действия, устраняется угроза того, что про-
122
Часть II. Приложения сетевой защиты
тивник, похитивший и мандат, и аутентификатор, сможет с успехом предъя-
вить их позже.
Ответ от TGS в виде сообщения (4) по форме соответствует сообщению (2).
Сообщение шифруется сеансовым ключом, используемым TGS совместно с С, и
включает сеансовый ключ, который должен применяться сервером V совместно с
С, идентификатор V и штамп даты-времени мандата. Сам мандат тоже содержит
этот сеансовый ключ.
Теперь С имеет мандат многократного использования для доступа к соответ-
ствующей службе V. Когда С предъявляет этот мандат, как показано в сообще-
нии (5), С посылает вместе с ним аутентификатор. Сервер может дешифровать
мандат, восстановить сеансовый ключ и дешифровать аутентификатор.
Если требуется взаимная аутентификация, сервер может ответить так, как
предлагается в сообщении (6) из табл. 4.1. Сервер возвращает значение штампа
даты-времени из аутентификатора, увеличенное на 1 и зашифрованное сеансо-
вым ключом. Система С может дешифровать это сообщение и проверить увели-
ченное значение штампа даты-времени. Поскольку сообщение было зашифровано
сеансовым ключом, С убеждается в том, что оно могло быть создано только сер-
вером V. Содержимое сообщения убеждает С в том, что данное сообщение не яв-
ляется воспроизведением старого ответа.
В результате клиент и сервер получают общий секретный ключ. Этот ключ
можно использовать для шифрования будущих сообщений между ними или для
обмена новыми сеансовыми ключами.
В табл. 4.2 объясняется назначение каждого из элементов протокола
Kerberos, а на рис. 4.1 показана упрощенная схема всего процесса.
Таблица 4.2. Назначение элементов протокола Kerberos версии 4
а) обмен службы аутентификации
Сообщение (1) Клиент запрашивает мандат на получение мандата
IDC: Идентифицирует пользователя клиента для системы AS
IDtgs : Информирует AS о том, что пользователь запрашивает доступ к TGS
TSj: Позволяет AS проверить синхронизацию часов пользователя с часами AS
Сообщение (2) AS выдает в ответ мандат на получение мандата
ЕКс : Шифрование, основанное на пароле пользователя, защищающее содер- жимое сообщения (2) и позволяющее AS и клиенту проверить пароль
Кс, tgs : Экземпляр сеансового ключа для клиента, созданный AS с целью защи- ты обмена данными между клиентом и сервером при отсутствии общего
постоянного ключа
IDtgs : Указывает на то, что мандат предназначен для TGS
TS2: Информирует клиента о времени выдачи мандата
Срок2: Информирует клиента о сроке действия мандата
Мандат,^ : Мандат, который должен использоваться клиентом для доступа к TGS
Глава 4. Приложения аутентификации
123
Продолжение табл. 4.2
б) обмен службы выдачи мандатов
Сообщение (3) IDV : Мандат, s: Клиент запрашивает мандат на получение сервиса Информирует AS о том, что пользователь запрашивает доступ к серверу V Убеждает TGS в том, что пользователь был идентифицирован сервером аутентификации AS
Аутентификаторс : Генерируется клиентом для подтверждения мандата
Сообщение (4) Ек : KC.lgs TGS выдает в ответ мандат на получение сервиса Шифрование ключом, используемым совместно С и TGS, защищающее содержимое сообщения (4)
KC,v : Экземпляр сеансового ключа для клиента, созданный TGS с целью пре- доставления возможности защищенного обмена данными между клиен- том и сервером при отсутствии общего постоянного ключа
IDV: TS4: Подтверждает, что мандат предназначен для сервера V Информирует клиента о времени выдачи мандата
Мандату : Мандат, который должен использовать клиент для доступа к V
Мандат,^ Допускает многократное использование, чтобы пользователю не прихо- дилось вводить пароль повторно
Ек : K-tgs Мандат шифруется ключом, известным только AS и TGS, чтобы исклю- чить возможность несанкционированной модификации мандата
Kc,tgs : Экземпляр сеансового ключа для TGS, с помощью которого можно дешиф- ровать аутентификатор, решающий задачу аутентификации мандата
IDC: ADC : Указывает истинного владельца мандата Предотвращает возможность использования мандата с рабочей станции, отличной от той, с которой мандат был запрошен
IDtgs : TS2: Срок 2 : Убеждает сервер в том, что мандат был дешифрован правильно Информирует TGS о времени выдачи мандата Делает бесполезным воспроизведение мандата после истечения срока его действия
Аутентификаторс Убеждает TGS в том, что предъявителем мандата является клиент,
EKc.,ss : которому мандат был выдан; имеет очень ограниченный срок действия, исключающий эффективность атак воспроизведения Удостоверение шифруется ключом, известным только клиенту и TGS, чтобы исключить возможность несанкционированной модификации
IDC: Должен совпадать с идентификатором, включенным в мандат, чтобы аутентифицировать мандат
ADC: Должен совпадать с адресом, включенным в мандат, чтобы аутентифи- цировать мандат
TS2 : Информирует TGS о времени создания аутентификатора
124
Часть II. Приложения сетевой защиты
Окончание табл. 4.2
в) обмен аутентификации клиента/сервера
Сообщение (5) Клиент запрашивает сервис
Мандату : Убеждает сервер в том, что пользователь был идентифицирован серве-
ром аутентификации AS
Аутентификаторс : Генерируется клиентом для подтверждения мандата
Сообщение (6) Необязательная аутентификация сервера для клиента
ЕКс v : Убеждает С в том, что отправителем сообщения является V
TS5 + I : Убеждает С в том, что сообщение не является воспроизведением старого
ответа
Мандат^ Допускает многократное использование, чтобы пользователю не прихо-
дилось запрашивать у TGS новый мандат при каждом обращении к од-
ному и тому же серверу
ЕКу : Мандат шифруется ключом, известным только TGS и серверу, чтобы
исключить возможность несанкционированной модификации
Кс v : Экземпляр сеансового ключа для клиента, с помощью которого можно де-
шифровать аутентификатор, решающий задачу аутентификации мандата
IDC : Указывает истинного владельца мандата
ADC : Предотвращает возможность использования мандата с рабочей станции,
отличной от той, с которой мандат был запрошен
IDV : Убеждает сервер в том, что мандат был дешифрован правильно
TS4 : Информирует сервер о времени выдачи мандата
Срок4 : Делает бесполезным воспроизведение мандата после истечения срока его
действия
Аутентификаторс Убеждает сервер в том, что предъявителем мандата является кли-
ент, которому мандат был выдан; имеет очень ограниченный срок дей-
ствия, исключающий эффективность атак воспроизведения
EK(_v : Аутентификатор шифруется ключом, известным только клиенту и серверу,
чтобы исключить возможность несанкционированной модификации
IDC : Должен совпадать с идентификатором, включенным в мандат, чтобы
аутентифицировать мандат
ADC : Должен совпадать с адресом, включенным в мандат, чтобы аутентифи-
цировать мандат
TS5 :Информирует сервер о времени создания аутентификатора
Области Kerberos и их взаимодействие
Полномасштабная среда Kerberos, состоящая из сервера Kerberos и ряда
клиентов и серверов приложений, должна удовлетворять следующим условиям.
1. Сервер Kerberos должен иметь в своей базе данных идентификаторы (UID) и
соответствующие хэшированные пароли всех пользователей. Все пользова-
тели регистрируются сервером Kerberos.
Глава 4. Приложения аутентификации
125
2. Сервер Kerberos и каждый взаимодействующий с ним сервер должны со-
вместно использовать свой уникальный секретный ключ. Все серверы реги-
стрируются сервером Kerberos.
2. Система AS проверяет права доступа пользователя
с помощью своей базы данных, создает мандат
на получение мандата и сеансовый ключ.
Результат шифруется с помощью ключа, генерируемого
на основе пароля пользователя
Kerberos
пользователя
Один раз
для каждого
1. Пользователь входит
в систему рабочей станции
и запрашивает
сервис
л ключ
Мандат
Один раз для
каждого типа
сервиса
3. Рабочая станция
запрашивает
v пользователя пароль
и использует
этот пароль для
дешифрования
пришедшего сообщения,
затем
отсылает серверу TGS
мандат и аутентификатор,
содержащий имя
пользователя, сетевой
адрес и время
Один раз для
каждого сеанса
использования
сервиса
Сервер
выдачи
мандатов (TGS)
5. Рабочая станция
посылает серверу мандат
и аутентификатор
6. Сервер проверяет соответствие
мандата и аутентификатора, после чего
разрешает использование сервиса.
Если требуется взаимная аутентификация,
сервер возвращает аутентификатор
Сервер
аутентификации
(AS)
4. TGS дешифрует мандат и аутентификатор,
проверяет запрос, а затем создаст мандат
на доступ к запрошенному серверу
Рис. 4.1. Схема работы системы Kerberos
В терминологии Kerberos такая среда называется областью (realm). Сети
клиентов и серверов разных административных подразделений организации
обычно образуют разные области. Это значит, что наличие пользователей и
серверов, зарегистрированных в одном административном домене и управ-
ляемых сервером Kerberos из другого домена, практически неприемлемо или
противоречит административной политике. Однако пользователям одной об-
ласти может понадобиться доступ к серверам других областей, и некоторые
серверы могут быть готовы обеспечить сервис пользователям из других об-
ластей при условии, что эти пользователи могут быть идентифицированы.
Система Kerberos обеспечивает механизм поддержки такой “межобластной”
аутентификации. Чтобы обеспечить поддержку аутентификации для двух облас-
тей, добавляется еще одно, третье требование.
3. Сервер Kerberos каждой из взаимодействующих областей должен использо-
вать с сервером другой области общий секретный ключ. Два сервера
Kerberos регистрируются один в другом.
126
Часть II. Приложения сетевой защиты
Такая схема требует, чтобы сервер Kerberos одной области доверял аутен-
тификацию своих пользователей серверу Kerberos другой области. Кроме того,
серверы второй области также должны быть готовы доверять серверу Kerberos
первой области.
При таких условиях можно предложить следующую схему (рис. 4.2). Для
получения сервиса на сервере из другой области пользователь нуждается в ман-
дате доступа к этому серверу. Клиент пользователя сначала следует обычной
процедуре получения доступа к локальному TGS, а затем запрашивает мандат
доступа к удаленному TGS (TGS из другой области). После этого клиент может
обратиться к удаленному TGS за мандатом на получение сервиса от нужного сер-
вера в области удаленного TGS.
Рис. 4.2. Запрос на получение сервиса из другой области
В схеме, показанной на рис. 4.2, происходит обмен следующими сообще-
ниями (сравните с табл. 4.1).
Глава 4. Приложения аутентификации
127
(1) C-^AS: IDC ||IDtgs UTSi
(2) AS—>C: EKc[Kc>tgs||IDtgs||TS2||CpoK2|| Мандат^]
(3) C -> TGS : IDtgsrem II Мандат,^ || Аутентификаторс
(4) TGS C : EKc tgs[Kc,tgsrem || IDtgsrem || TS4 || Мандат^]
(5) C -4 TGSrem : IDVrem || MaHflartgsrem || Аутентификаторс
(6) TGS—>C: EKctgsrem[Kc,Vrem!| rovrem IITS5 II МандатVrem]
(7) C—>Vrem: МандатVrem || Аутентификаторс
Мандат, предъявляемый удаленному серверу (Vrem), указывает область, в кото-
рой пользователь изначально был аутентифицирован. Сервер решает, следует ли
удовлетворить удаленный запрос.
Проблемой, связанной с предлагаемым выше подходом, является то, что он
не слишком эффективен в случае большого числа областей. Если число областей
равно N, то для того, чтобы каждая из областей Kerberos могла взаимодейство-
вать с любой другой, потребуется N(N - 1)/2 защищенных обменов ключами.
Kerberos версии 5
Версия 5 системы Kerberos описывается в документе RFC 1510 и содержит
целый ряд усовершенствований по сравнению с версией 4 [KOHL94]. Сначала мы
укажем отличия версии 5 от версии 4, а затем рассмотрим протокол версии 5.
Сравнение версий 4 и 5
Версия 5 системы Kerberos разрабатывалась для устранения ограничений
версии 4 в двух сферах: в сфере ограничений среды и в сфере технических не-
достатков. Мы рассмотрим предлагаемые версией 5 усовершенствования в каж-
дой из этих сфер.5
Версия 4 Kerberos разрабатывалась в рамках проекта Athena, и поэтому не
вполне отвечает требованиям универсального использования. Эта версия имеет
следующие ограничения среды.
1. Зависимость от системы шифрования. Версия 4 требует применения
DES. Поэтому приходится учитывать как экспортные ограничения на
DES, так и сомнения в надежности этого алгоритма. В версии 5 к шиф-
рованному тексту присоединяется идентификатор типа шифрования, по-
этому может использоваться любая схема шифрования. Присоединяются
также ключи шифрования с указанием длины, что позволяет применять
одни и те же ключи в различных алгоритмах, а также указывать вари-
анты одного алгоритма.
2. Зависимость от протокола Internet. Версия 4 требует использования адре-
сации IP. Другие типы адресов, например, сетевые адреса ISO, не распозна-
ются. В версии 5 сетевые адреса сопровождаются метками типа и длины,
что позволяет использовать сетевые адреса любых типов.
5 Следующее обсуждение проводится по схеме, предложенной в [KOHL94],
128
Часть II. Приложения сетевой защиты
3. Порядок байтов сообщения. В версии 4 отправитель сообщения используе
порядок байтов по своему усмотрению, а соответствующая метка, присоед!
няемая к сообщению, указывает на то, какой по значимости байт размещг
ется по младшему адресу — наименее или наиболее значимый. Эта техник
работает, но не следует принятым соглашениям. В версии 5 структура с(
общений определяется в соответствии со стандартами ASN.l (Abstrac
Syntax Notation One — абстрактная синтаксическая нотация версии 1)
BER (Basic Encoding Rules — базовые правила кодировки), что обеспечивае
однозначный порядок следования байтов.
4. Срок действия мандата. Сроки действия мандатов в версии 4 представляют
ся 8-битовыми значениями в единицах, соответствующих пяти минутам
Максимальный срок действия мандата, выраженный таким образом, оказь
вается равным 28х5 = 1280 минутам, что лишь немногим более 21 часа. Дл
некоторых приложений это может быть недостаточным (например, при дли
тельных процессах моделирования, требующих действия удостоверени
Kerberos в течение всего времени выполнения расчетов). В версии 5 манде
ты включают явное указание моментов начала и окончания действия мак
дата, что позволяет указывать любые сроки действия.
5. Передача сертификатов аутентификации. В версии 4 сертификат, выдав
ный одному клиенту, нельзя передать другому узлу, чтобы тот же сертифи
кат мог использовать другой клиент. Это давало бы возможность клиенту
получившему доступ к серверу, поручить этому серверу доступ к другом
серверу от имени данного клиента. Например, клиент может запросить дос
туп к серверу печати, которому затем необходимо будет получить доступ ]
файлу клиента на файловом сервере, воспользовавшись сертификатами кли
ента. Версия 5 обеспечивает такую возможность.
6. Аутентификация в удаленной области. В версии 4 взаимодействие между 1
областями требует, как уже упоминалось выше, порядка № сеансов взаи
модействия Kerberos-Kerberos. В версии 5, как будет показано ниже, ис
пользуется метод, при котором требуется меньше сеансов взаимодействия.
Помимо этих ограничений среды, в самом протоколе версии 4 имеются тех
иические недостатки. Большинство этих недостатков было перечислено :
[BELL90], и в версии 5 предпринята попытка их устранения. Недостатки заклю
чаются в следующем.
1. Двойное шифрование. Обратите внимание на то, что, как видно из табл. 4/
(сообщения 2 и 4), мандаты, выдаваемые клиентам, шифруются дважды —
один раз секретным ключом сервера назначения, а затем секретным клю
чом, известным клиенту. Второе шифрование не является необходимым, i
потому ведет к напрасному расходованию вычислительных ресурсов.
2. Шифрование в режиме РСВС. Шифрование в версии 4 использует нестан
дартный режим DES, называемый режимом РСВС (Propagating Cipher Bloc!
Chaining — режим распространения сцепления шифрованных блоков).6 Бы
ло доказано, что этот режим уязвим в отношении атак перестановки блокоз
шифрованного текста [KOHL89]. Режим РСВС должен был как часть стра
6 Этот режим описывается в дополнении 4.1.
Глава 4. Приложения аутентификации 12£
тегии шифрования обеспечить проверку целостности. В версии 5 предусмот-
рены непосредственные механизмы гарантии целостности, что делает воз-
можным использование стандартного режима СВС.
3. Сеансовые ключи. Каждый мандат включает сеансовый ключ, используе-
мый клиентом для шифрования аутентификатора, направляемого соответ-
ствующему сервису. Этот же сеансовый ключ может впоследствии исполь-
зоваться клиентом и сервером для защиты сообщений, пересылаемых в ходе
сеанса. Однако, поскольку один и тот же мандат для получения соответст-
вующего сервиса может использоваться повторно, существует риск, что
противник предъявит клиенту или серверу воспроизведенные сообщения
старого сеанса. В версии 5 для клиента и сервера существует возможность
договориться о сеансовом подключе, который будет действителен только
для одного соединения. Для нового соединения клиент должен будет ис-
пользовать новый сеансовый подключ.
4. Атаки иа пароль. Обе версии уязвимы в отношении атак на пароль. Сооб-
щение клиенту от системы AS включает данные, зашифрованные с помо-
щью ключа, генерируемого на основе пароля клиента.7 Противник может
перехватить это сообщение и попытаться дешифровать его, используя раз-
ные пароли. Есди в результате попыток дешифрования получится сообще-
ние правильного вида, то противник узнает пароль клиента и сможет впо-
следствии использовать его, чтобы получать сертификаты аутентификации
от Kerberos. Этот тип атаки на пароль описан в главе 9, там же приводятся
соответствующие контрмеры. Версия 5 предлагает механизм, называемый
предварительной аутентификацией, который затрудняет атаки на пароль,
но не исключает полностью их возможность.
Диалог аутентификации версии 5
В табл. 4.3 представлен базовый диалог версии 5. Понять его проще всего в
сравнении с диалогом версии 4 (см. табл. 4.1).
Таблица 4.3. Обмен сообщениями по протоколу Kerberos версии 5
а) обмен службы аутентификации: получение мандата на получение мандата
(1) С—» AS : Опции|| 1DC ||Областьс || IDtgs ||ГраницыВремени|| Оказия!
(2) AS-» С:
Областьс || IDC || Мандат,^ || ЕКс [Кс tgs || ГраницыВремени || ОказиЯ[ || Область^ || IDtgs]
Мандат^ = ЕК] s [Флаги || KCtgs || Областьс || IDC || ADC || ГраницыВремени]
б) обмен службы выдачи мандатов: получение мандата на получение сервиса
(3) С —» TGS : Опции || IDV || ГраницыВремени || Оказия2 || Мандатtgs || Аутентификаторс
(4) TGS —> С:
7 Отображение паролей в ключи шифрования описывается в дополнении 4.1.
130
Часть II. Приложения сетевой защиты
Окончание табл. 4.
Областьс || IDC || Мандату || ЕК(, [Кс у II ГраницыВремени || Оказия2 || Областьу || IDV ]
Мандат^ = Ек [Флаги || KCitgs II Областьс || IDC || ADC || ГраницыВремени]
Мандату = ЕКу [Флаги || Kcv || Областьс || IDC || ADC || ГраницыВремени]
Аутентификаторс = EKci [IDC || Областьс || TSJ
в) обмен аутентификации клиента/сервера: получение сервиса
(5) С —» К : Опции || Мандату || Аутентификаторе
(6) К —> С: ЕК(_ v [TS2 II Подключ || ПорядковыйНомер]
Мандату = ЕКу [Флаги || Kcv || Областьс || IDC || ADC || ГраницыВремени]
Аутентификаторс = ЕКс [IDC II Областьс IITS2 || Подключ || ПорядковыйНомер]
Сначала рассмотрим обмен службы аутентификации. Сообщение (1) пред
ставляет собой запрос клиентом мандата на получение мандата. Как и прежде
этот запрос включает идентификаторы пользователя и TGS. Но здесь добавляют
ся следующие новые элементы.
• Область. Указывает область пользователя.
• Опции. Служат для запроса установки определенных флагов в возвращае
мом мандате, как объясняется ниже.
• Границы времени. Используются клиентом, чтобы запросить в мандате еле
дующие установки времени:
• from — желательное время начала действия мандата,
• till — время окончания действия данного мандата,
• rtime — крайний срок для возобновления действия мандата.
• Оказии. Случайное значение, которое должно повториться в сообщении (2) ]
гарантировать, что ответ является новым, а не воспроизведен противником Л
Сообщение (2) возвращает мандат на получение мандата, информацию, иденти
фицирующую клиента, и некоторый блок данных, зашифрованный ключом шифре
вания, сгенерированным на основе пароля пользователя. Этот блок включает сеансо
вый ключ, который должен использоваться клиентом при обмене с TGS, границ!
времени, указанные в сообщении (1), оказию из сообщения (1) и информацию, идеи
тифицирующую TGS. Сам мандат включает сеансовый ключ, информацию, иденти
фицирующую клиента, затребованные значения границ времени и флаги, указы
8 Для лучшего понимания употребляемого здесь термина “оказия” (в оригинальном ш
дании книги используется слово попсе) читателю будут полезны следующие толкования сс
ответствующего английского слова. Nonce — данный случай, данное время. Nonce word -
слово, используемое или вводимое в оборот именно для данного конкретного случая. (ПеревО!
соответствующих статей из American Heritage Dictionary of the English Language, 3rd ed.)
Глава 4. Приложения аутентификации
131
вающие состояние мандата и требуемых опций. Использование этих флагов обеспе-
чивает версии 5 новые важные возможности. Пока мы отложим обсуждение этих
флагов и сосредоточим внимание на общей структуре протокола версии 5.
Сравним обмен службы выдачи мандатов версий 4 и 5. В обеих версиях со-
общение (3) включает аутентификатор, мандат и имя запрашиваемого сервиса.
Но, кроме того, версия 5 предусматривает включение в сообщение значений гра-
ниц времени, опций для мандата и оказии, назначение которых аналогично на-
значению соответствующих элементов сообщения (1). Аутентификатор здесь, по
существу, тот же, что и используемый в версии 4.
Сообщение (4) имеет ту же структуру, что и сообщение (2), и возвращает
мандат плюс информацию, необходимую клиенту, причем последняя шифруется
сеансовым ключом, применяемым теперь совместно клиентом и TGS.
Наконец, ряд новых элементов используется в версии 5 для обмена аутен-
тификации клиента/сервера. В сообщении (5) клиент имеет возможность запро-
сить в виде опции взаимную аутентификацию. Аутентификатор включает не-
сколько новых полей следующего вида.
• Подключ. Определяет выбираемый клиентом ключ шифрования для защи-
ты данного конкретного сеанса работы с приложением. Если это поле не ис-
пользовано, будет применяться сеансовый ключ мандата (Kc v).
• Порядковый номер. Необязательное поле, указывающее начальный порядковый
номер, который должен применяться сервером для нумерации сообщений, по-
сылаемых клиенту в ходе данного сеанса. Нумерацию сообщений можно ис-
пользовать для того, чтобы вовремя обнаружить атаку воспроизведения.
Если необходима взаимная аутентификация, сервер отвечает сообщением
(6). Это сообщение включает штамп даты-времени из аутентификатора. Вспом-
ните, что в версии 4 значение штампа даты-времени увеличивалось на единицу.
В версии 5 это не требуется, поскольку сам формат сообщений не позволяет про-
тивнику создать сообщение типа (6) без знания соответствующих ключей шиф-
рования. Значение подключа, если оно задается, отменяет значение поля под-
ключа сообщения (5), если там соответствующее значение было задано. Необяза-
тельное поле порядкового номера указывает начальный порядковый номер,
который должен использовать для сообщений клиент.
Флаги мандата
Поле флагов, включаемое в мандаты в версии 5, обеспечивает по сравнению
с версией 4 поддержку расширенных возможностей. В табл. 4.4 перечислены
флаги, которые могут включаться в мандат.
Таблица 4.4. Флаги Kerberos версии 5
INITIAL Мандат был выдан при использовании протокола AS, а не на основе мандата на выдачу мандата
PRE-AUTHENT В ходе начальной аутентификации клиент был аутентифицирован центром распределения ключей до того, как был выдан мандат
HW-AUTHENT Протокол, используемый для начальной аутентификации, требовал наличия аппаратных средств, которые, как предполагается, имеются только у указанного клиента
132
Часть II. Приложения сетевой защиты
Окончание табл. 4.4
RENEWABLE Сообщает TGS о том, что данный мандат может использоваться для получения нового мандата, срок действия которого истекает позже
MAY-POSTDATE Сообщает TGS о том, что на основании данного мандата на выдачу мандата может быть выдан мандат с возможностью отсрочки
POSTDATED Указывает на то, что этот мандат отсрочен; конечный сервер может проверить значение поля authtime, чтобы выяснить, когда была вы- полнена исходная аутентификация
INVALID Мандат недействителен и должен быть подтвержден TGS перед ис- пользованием
PROXIABLE Сообщает TGS о том, что на основании предъявленного мандата мо- жет быть выдан новый мандат с другим сетевым адресом
PROXY Указывает на то, что мандат предъявляется агентом, представляю- щим другую систему
FORWARDABLE Сообщает TGS о том, что на основании данного мандата на получение мандата может быть выдан новый мандат на получение мандата с другим сетевым адресом
FORWARDED Указывает на то, что мандат был передан или выдан на основании результатов аутентификации, выполненной с использованием пере- данного мандата на получение мандата
Флаг INITIAL указывает на то, что этот мандат был выдан сервером аутен-
тификации AS, а не сервером выдачи мандатов TGS. Запрашивая мандат у TGS,
клиент предъявляет мандат на получение мандата, полученный от AS. В вер-
сии 4 это было единственным способом получить мандат доступа к сервису. В
версии 5 для клиента предусмотрена возможность получить мандат доступа к
сервису непосредственно от AS. Это удобно, поскольку, например, сервер изме-
нения пароля получает возможность выяснить, какой пароль клиента проверял-
ся перед данным.
Флаг PRE-AUTHENT, если он установлен, указывает на то, что сервер AS по
получении исходного запроса (сообщение 1) перед выдачей мандата аутентифи-
цировал клиента. Точная форма этой предварительной аутентификации остается
неопределенной. Например, реализация версии 5 Массачусетсского технологиче-
ского института по умолчанию предполагает предварительную аутентификацию
с помощью шифрованного штампа даты-времени. Когда пользователю требуется
мандат, ему необходимо послать серверу аутентификации AS блок предваритель-
ной аутентификации, содержащий случайное значение, номер версии и штамп
даты-времени, шифрованные с помощью ключа, генерируемого на основе пароля
клиента. Сервер аутентификации AS, дешифровав блок, не отправит мандат на
получение мандата, если обнаружит, что штамп даты-времени в блоке предвари-
тельной аутентификации выходит за рамки допустимого отклонения по времени
(т.е. за допустимые рамки дрейфа часов и сетевых задержек). Другой возможно-
стью является применение смарт-карт, генерирующих постоянно меняющиеся
пароли, включаемые в сообщения предварительной аутентификации. Генерируе-
мые смарт-картой пароли могут основываться на пароле пользователя, но преоб-
разовываться картой так, что практически не будут отличаться от случайных.
Глава 4. Приложения аутентификации
133
Такой механизм предотвращает возможность проведения атак, основанных на
угадывании легких паролей. О применении смарт-карт или других подобных
устройств сообщается с помощью флага HW-AUTHENT.
Если мандат имеет долгий срок действия, противник получает потенциаль-
ную возможность похитить такой мандат и использовать его на протяжении дос-
таточно длительного времени. Если с целью защиты от этой угрозы для манда-
тов установить короткие сроки действия, то существенно увеличится нагрузка на
систему из-за необходимости частого получения новых мандатов. В случае ман-
дата на получение мандата клиенту приходится либо хранить секретный ключ
пользователя, что, очевидно, рискованно, либо постоянно запрашивать у пользо-
вателя пароль. Компромиссная схема предполагает использование возобновляе-
мых мандатов. Мандат с установленным флагом RENEWABLE включает два зна-
чения срока действия: один для данного конкретного мандата и один — для
крайнего срока окончания его действия. Клиент может возобновить действие
мандата, предъявив его на рассмотрение TGS и запросив новое время для срока
окончания действия. Если запрошенное новое время не выходит за рамки край-
него срока действия, TGS может выдать новый мандат с новым временем сеанса
и более поздним временем окончания действия. Преимущество этой схемы в
том, что TGS может отказаться обновить мандат, объявленный похищенным.
Клиент может потребовать, чтобы сервер аутентификации AS выдал мандат
на выдачу мандата с установленным флагом MAY-POSTDATE. Клиент может за-
тем использовать такой мандат для того, чтобы запросить от TGS мандат с фла-
гами POSTDATED и INVALID. Впоследствии клиент может предъявить отсрочен-
ный мандат для подтверждения его действительности. Эта схема применяется
при выполнении длинных пакетных заданий на сервере, который периодически
требует предъявления мандата. Клиент может получить нужное число мандатов
для соответствующего сеанса сразу, но с распределенными значениями времени.
Все мандаты, кроме первого, изначально недействительны. Когда в ходе выпол-
нения работы наступает момент предъявления нового мандата, клиент может
получить подтверждение действительности соответствующего мандата. При та-
ком подходе клиенту нет необходимости повторно использовать мандат на полу-
чение мандата, чтобы получить мандат на предоставление сервиса.
В версии 5 для сервера существует возможность действовать в качестве
агента (proxy) от имени клиента, по сути используя сертификаты и привилегии
клиента для запросов сервиса с другого сервера. Если клиент предполагает ис-
пользование такого механизма, запрашивается мандат с установленным флагом
PROXIABLE. Когда такой мандат предъявляется на рассмотрение TGS, сервер TGS
разрешает выдачу мандата на получение сервиса с другим сетевым адресом, и
для такого мандата устанавливается флаг PROXY. Приложение, получающее та-
кой мандат, может либо принять его, либо потребовать выполнения дополни-
тельной процедуры аутентификации для контрольной проверки.9
Концепция применения агента является частным случаем более общей про-
цедуры передачи полномочий. Если мандат имеет установленный флаг
FORWARDABLE, то сервер TGS может выдать подателю запроса мандат на полу-
чение мандата с другим сетевым адресом и установленным флагом FORWARDED.
9 Некоторые возможности применения этой схемы описаны в [NEUM93].
134
Часть II. Приложения сетевой защиты
Такой мандат может быть затем предъявлен удаленному TGS. Это позволяет
клиенту получить доступ к серверу из другой области без того, чтобы каждая
система Kerberos хранила секретные ключи для серверов Kerberos любой другой
области. Например, области могут быть выстроены по иерархии. Тогда клиент
сможет подняться по дереву к общей вершине, а потом спуститься вниз, чтобы
достичь области назначения. Каждый шаг на этом пути должен включать пере-
дачу мандата на получение мандата следующему серверу TGS цепочки.
4.2. СЛУЖБА АУТЕНТИФИКАЦИИ Х.509
Рекомендации Х.509 Международного союза телекоммуникаций (International
Telecommunication Union — ITU) являются частью рекомендаций серии Х.500, опре-
деляющей стандарт службы каталогов. Вообще говоря, каталог представляет собой
сервер или распределенную систему серверов, поддерживающих базу данных с ин-
формацией о пользователях. Эта информация отражает соответствие имен пользова-
телей и их сетевых адресов, а также другие атрибуты пользователей.
Документ Х.509 определяет каркас схемы предоставления услуг аутенти-
фикации каталогом Х.500 своим пользователям. Этот каталог может служить
хранилищем сертификатов открытых ключей. Каждый сертификат содержит от-
крытый ключ пользователя и подписывается личным ключом надежного центра
сертификации. Кроме того, Х.509 определяет альтернативные протоколы аутен-
тификации, построенные на использовании сертификатов открытых ключей.
Стандарт Х.509 оказывается важным, поскольку структура сертификатов и
протоколов аутентификации, определяемых в Х.509, может использоваться в
самых разных ситуациях. Например, формат сертификата Х.509 принят в про-
токолах S/MIME (см. главу 5), IP Security (см. главу 6), а также SSL/TLS и SET
(см. главу 7).
Стандарт Х.509 появился в 1988 году. Позже он был пересмотрен и в нем
были исправлены некоторые недостатки защиты, что было отражено в [IANS90]
и [MITC90]; исправленные рекомендации были опубликованы в 1993 году. Про-
ект третьей версии появился в 1995 году.
Рекомендации Х.509 базируются на использовании методов криптографии с
открытым ключом и цифровых подписей. Стандарт не вынуждает использовать
конкретный алгоритм, хотя и рекомендует применять RSA. Схема цифровой
подписи предполагает использование функции хэширования. Опять же, стандарт
не навязывает использование какого-либо конкретного алгоритма хэширования.
Рекомендации 1988 года включали описание рекомендуемого алгоритма хэши-
рования, но впоследствии выяснилось, что этот алгоритм ненадежен, и поэтому
в рекомендации 1993 года он не вошел.
Сертификаты
Главным элементом схемы Х.509 являются сертификаты открытых ключей,
связываемые с каждым пользователем. Предполагается, что эти сертификаты
выдаются некоторым надежным центром сертификации (Certification
Authority — СА) и размещаются в соответствующем каталоге либо этим цен-
тром, либо пользователем. Сервер каталогов непосредственно не отвечает за соз-
дание открытых ключей или функции сертификации; а просто предоставляет
легко доступный пользователям источник сертификатов.
Глава 4. Приложения аутентификации
135
На рис. 4.3 показан общий формат сертификата, который включает сле-
дующие элементы.
• Версия. Указывает версию формата сертификата; по умолчанию выбирается
версия 1. Если указан уникальный идентификатор инициатора (Initiator
Unique Identifier) или уникальный идентификатор субъекта (Subject Unique
Identifier), то значением версии должно быть 2. Если имеется одно или не-
сколько расширений, должна быть указана версия 3.
• Порядковый номер. Целое значение, уникальное в рамках данного центра
сертификации, однозначно связываемое с данным сертификатом.
• Идентификатор алгоритма подписи. Идентифицирует алгоритм, используе-
мый для создания подписи сертификата, вместе со всеми необходимыми па-
раметрами. Поскольку эта информация дублируется в поле подписи в конце
сертификата, данное поле оказывается не слишком полезным.
• Имя объекта, выдавшего сертификат. Имя по стандарту Х.500 центра сер-
тификации, создавшего и подписавшего сертификат.
• Срок действия. Включает две даты: начала и окончания действия сертификата.
• Имя субъекта. Имя пользователя, которому соответствует сертификат, т.е.
данный сертификат удостоверяет открытый ключ субъекта, владеющего со-
ответствующим личным ключом.
• Информация об открытом ключе субъекта. Открытый ключ субъекта плюс
идентификатор алгоритма, с которым должен использоваться этот ключ, а
также все необходимые параметры.
• Уникальный идентификатор объекта, выдавшего сертификат. Необязательная
строка битов, однозначно идентифицирующая центр сертификации, выдавший
сертификат, в случае, когда имя Х.500 использовалось для разных объектов.
• Уникальный идентификатор субъекта. Необязательная строка битов, одно-
значно идентифицирующая субъекта в случае, когда имя Х.500 использова-
лось для разных объектов.
• Расширения. Одно или несколько полей расширения. Расширения были до-
бавлены в версии 3 и рассматриваются в этом разделе ниже.
• Подпись. Охватывает все остальные поля сертификата, содержит их хэш-
код, зашифрованный с помощью личного ключа центра сертификации.
Кроме того, это поле включает идентификатор алгоритма подписи.
Поля уникальных идентификаторов были включены в версию 2, чтобы
обеспечить возможность многократного применения имен субъекта и/или объек-
та, выдавшего сертификат. Эти поля используются редко.
Для определения сертификата соответствующий стандарт использует сле-
дующую формулу:
СА « А » = СА {V, SN, Al, СА, ТА, А, Ар) ,
где
Y « X » — удостоверение пользователя X, выданное центром сертификации Y,
Y{I}— подпись для I, создаваемая объектом Y. Она состоит из I и добав-
ленного шифрованного хэш-кода.
136
Часть II. Приложения сетевой защиты
Версия
Идентификатор
алгоритма
подписи
Алгоритм
Параметры
Номер сертификата
Имя объекта,
выдавшего сертификат
Идентификатор
алгоритма
подписи
Срок
действия
Алгоритм
Параметры
Имя объекта,
выдавшего сертификат
Не ранее
Не позже
я
S
а.
<U
И
Й5
Отозванный
сертификат
Дата этого обновления
Дата следующего
обновления
ТТомёрТертификатТ1
_ пользователе
Дата отзыва
§
Имя субъекта
я
S
Информация
об открытом
ключе
субъекта
Подпись
Алгоритмы
Параметры
Ключ
Уникальный идентификатор
объекта, выдавшего
сертификат
Уникальный
идентификатор субъекта
Расширения
Алгоритмы
Параметры
Зашифровано
<U
s
S
о
£ О.
си
а
Отозванный
сертификат
Подпись
Номер сертификата
пользователя_ _
Дата отзыва
Алгоритмы
Параметры
Зашифровано
б) список отзыва
сертификатов
а) сертификат Х.509
Рис. 4.3. Форматы Х.509
Центр сертификации подписывает сертификат с помощью своего секретного
(личного) ключа. Зная соответствующий открытый ключ, пользователь может
удостовериться, что подписанный центром сертификации сертификат является
действительным. Такая схема использования цифровой подписи является ти-
пичной (см. рис. 3.2, б в главе 3).
Получение сертификата пользователя
Сертификат пользователя, генерируемый центром сертификации, имеет сле-
дующие характеристики.
• Любой пользователь, имеющий открытый ключ центра сертификации, мо-
жет восстановить сертифицированный открытый ключ пользователя.
• Никто, кроме уполномоченного центра, не может изменить сертификат без
того, чтобы это было обнаружено.
Поскольку сертификаты фальсифицировать невозможно, их можно размес-
тить в каталоге без применения специальных средств защиты.
Если все пользователи используют один центр сертификации, это означает
общее доверие данному центру сертификации. Тогда сертификаты пользователей
могут размещаться в одном каталоге, доступном всем. Кроме того, любой поль-
зователь может передать свой сертификат другому пользователю непосредствен-
но. В любом случае, если В имеет сертификат А, то В может быть уверен в том,
Глава 4. Приложения аутентификации
137
что сообщения, которые он шифрует открытым ключом А, будут защищены от
прочтения, а сообщения, подписанные личным ключом А, — от фальсификации.
В большом сообществе пользователей обращение всех пользователей к од-
ному и тому же центру сертификации может оказаться практически неприемле-
мым. Поскольку сертификаты подписываются центром сертификации, каждый
пользователь должен иметь собственный экземпляр открытого ключа центра
сертификации, чтобы проверять подписи. Этот открытый ключ должен быть
доставлен каждому пользователю абсолютно защищенным способом
(обеспечивающим целостность и аутентичность), чтобы пользователь имел пол-
ную уверенность в поступающих сертификатах. Таким образом, при большом
числе пользователей может оказаться более удобным иметь ряд центров серти-
фикации, каждый из которых должен будет защищенным способом доставить
открытый ключ некоторой части пользователей.
Теперь предположим, что А получает сертификат от уполномоченного цен-
тра сертификации Xj , а В — от Х2 . Если пользователю А не был предоставлен
открытый ключ Х2, то сертификат В, выданный центром сертификации Х2,
окажется для А бесполезным. Пользователь А сможет прочитать сертификат В,
но не сможет проверить подпись. Однако, если два центра сертификации по ка-
кой-то защищенной схеме обменялись своими открытыми ключами, то следую-
щая процедура открывает для А возможность получить открытый ключ В.
1. Пользователь А получает из каталога сертификат Х2 , подписанный X!.
Поскольку А с уверенностью знает открытый ключ X! , из полученного сер-
тификата пользователь А сможет извлечь открытый ключ Х2 и проверить
его с помощью подпись, которая была создана X! для этого сертификата.
2. Затем А снова обращается к каталогу и получает сертификат В, подписанный
Х2. Поскольку теперь пользователь А имеет экземпляр открытого ключа Х2 ,
пользователь А может проверить подпись и получить открытый ключ В.
В данном случае пользователь А использовал цепочку сертификатов, чтобы
получить открытый ключ пользователя В. В обозначениях Х.509 эта цепочка за-
писывается в виде
X, «Х2 »Х, «в».
Точно так же В может получить открытый ключ А, но по обратной цепочке:
Х2«Х1»Х1«А».
Эта схема не ограничивается случаем цепочки, состоящей из двух сертифи-
катов. В цепочке может участвовать любое число центров сертификации. Цепоч-
ка из N элементов будет иметь следующий вид:
Х1«Х2»Х2«Х3» ... Хд,«В».
В этом случае пара центров сертификации в каждом звене (Х;, Х(+!) должна иметь
уже готовые сертификаты друг для друга.
Все сертификаты центров сертификации должны размещаться в каталоге, а
пользователю необходимо знать, как они связаны, чтобы проследовать по подхо-
дящему маршруту к нужному сертификату открытого ключа другого пользова-
138
Часть II. Приложения сетевой защиты
теля. Стандарт Х.509 предлагает, чтобы центры сертификации подчинялись та-
кой иерархии, при которой путь оказывается прямолинейным.
На рис. 4.4, взятом из документации Х.509, показан пример такой иерар-
хии. Соединенные окружности обозначают иерархически связанные центры сер-
тификации, а в указанных рядом прямоугольных блоках приводятся сертифика-
ты, имеющиеся в каталоге соответствующего центра сертификации. Каталог
центра сертификации включает два типа сертификатов.
• Прямые сертификаты. Сертификаты X, выданные другими центрами сер-
тификации.
• Возвратные сертификаты. Сертификаты, выданные X для сертификации
других центров сертификации.
Рис. 4.4. Иерархия Х.509: гипотетический пример
В данном примере пользователь А может запросить следующие сертифика-
ты из каталога, чтобы построить сертификационный маршрут к В:
Х« W» W« V» V«Y» Y«Z»Z«B» .
Получив эти сертификаты, пользователь А сможет развернуть сертификаты
по маршруту один за другим и восстановить надежный экземпляр открытого
ключа В. Используя этот открытый ключ, А сможет посылать В шифрованные
сообщения. Если же А понадобится получать шифрованные сообщения от В или
Глава 4. Приложения аутентификации
139
же подписывать сообщения, посылаемые адресату В, то В потребуется открытый
ключ А, который может быть получен по следующей цепочке сертификатов:
Z « Y » Y « V » V « W » W « X » X « А » .
Пользователь В может получить этот набор сертификатов из каталога, или
А может включить такой набор сертификатов в свое исходное сообщение для В.
Отзыв сертификатов
Напомним, что каждый сертификат, подобно кредитной карточке, включает
информацию о сроке его действия (см. рис. 4.3). Обычно новый сертификат вы-
дается незадолго до окончания срока действия старого. Но в некоторых ситуаци-
ях желательно иметь возможность отменить действие сертификата до того, как
срок его действия истечет, например, по одной из следующих причин.
1. Секретный ключ пользователя оказывается скомпрометированным.
2. Пользователь больше не сертифицируется данным центром сертификации.
3. Сертификат данного центра сертификации оказывается скомпрометированным.
Каждый центр сертификации должен поддерживать список, в котором ука-
зываются все отозванные, но не исчерпавшие срок своего действия сертификаты,
выданные данным центром сертификации, включая как сертификаты, выданные
пользователям, так и сертификаты, выданные другим центрам сертификации.
Эти списки должны размещаться и в каталоге.
Любой список отозванных сертификатов (Certificate Revocation List — CRL),
размещаемый в каталоге, подписывается центром сертификации и включает имя
центра сертификации, дату создания списка, дату выхода следующей версии CRL
и соответствующую запись для каждого отозванного сертификата (см. рис. 4.3, б).
Любая такая запись складывается из порядкового номера сертификата и даты от-
зыва этого сертификата. Поскольку порядковые номера сертификатов уникальны
внутри данного центра сертификации, порядкового номера оказывается достаточно
для того, чтобы распознать сертификат.
Получая сертификат в сообщении, пользователь должен выяснить, не был
ли этот сертификат отозван. Он может проверять это по каталогу каждый раз,
когда получает сертификат. Чтобы избежать задержек (и возможных дополни-
тельных расходов), связанных с поиском информации в каталоге, вполне веро-
ятно, что пользователь предпочтет использовать локальный кэш для хранения
сертификатов и списков отозванных сертификатов.
Процедуры аутентификации
Стандарт Х.509 включает также три альтернативные процедуры аутенти-
фикации, которые предлагается использовать в самых разных приложениях. Эти
процедуры используют подписи, построенные по схеме с открытым ключом.
Предполагается, что каждая из двух сторон знает открытый ключ другой из со-
ответствующего сертификата, полученного либо из каталога, либо из исходного
сообщения стороны, инициировавшей обмен.
Схемы всех трех процедур показаны на рис. 4.5.
140
Часть II. Приложения сетевой защиты
1-аИа> ГА’В» sgnData, Е Kub [КаьП
б) двухшаговая аутентификация
в) трехшаговая аутентификация
Рис. 4.5. Процедуры аутентификации Х.509
Одношаговая аутентификация
Одношаговая аутентификация предполагает передачу одного сообщения от
одного пользователя (А) другому (В), которое устанавливает следующее.
1. Аутентичность А и то, что сообщение было создано А.
2. Что сообщение предназначалось для В.
3. Целостность и оригинальность сообщения (что оно не посылается второй раз).
Заметим, что данная процедура устанавливает только аутентичность источника,
но не аутентичность получателя.
Как минимум, сообщение должно включать штамп даты-времени tA , ока-
зию гА и идентификатор В и должно быть подписано с использованием откры-
того ключа А. Штамп даты-времени складывается из необязательно указываемо-
го времени выдачи и времени окончания срока действия. Это устраняет возмож-
Глава 4. Приложения аутентификации
141
ность необоснованной задержки сообщения. Оказию можно использовать для то-
го, чтобы обнаружить атаку воспроизведения. Значение для оказии должно быть
уникальным на протяжении всего срока действия сообщения. Например, В мо-
жет сохранять значения оказии до истечения срока их действия и отвергать лю-
бые новые сообщения с повторяющимися значениями оказии.
В рамках только аутентификации сообщение может использоваться просто
для того, чтобы предъявить сертификаты стороне В. Но сообщение может вклю-
чать еще и сопровождающую информацию. Эта информация (sgnData) содержится
в области действия подписи, что гарантирует ее достоверность и целостность.
Такое сообщение можно также использовать для того, чтобы переправить В се-
ансовый ключ, зашифрованный открытым ключом В.
Двухшаговая аутентификация
Помимо трех указанных выше элементов аутентификации, двухшаговая ау-
тентификация гарантирует следующее.
1. Аутентичность В и то, что ответное сообщение было создано В.
2. Что соответствующее сообщение предназначалось для А.
3. Целостность и оригинальность ответа.
Двухшаговая аутентификация, таким образом, позволяет обеим взаимодейст-
вующим сторонам проверить аутентичность друг друга.
Ответное сообщение включает оказию А, подтверждающую ответ. Оно так-
же включает штамп даты-времени и оказию, генерируемую стороной В. Как уже
отмечалось выше, сообщение может включать подписанную дополнительную
информацию и сеансовый ключ, зашифрованные открытым ключом А.
Трехшаговая аутентификация
При трехшаговой аутентификации требуется переслать от А к В еще одно
сообщение, которое должно содержать подписанную копию оказии гв. Такая
форма сообщения выбирается потому, что проверять штамп даты-времени необ-
ходимости нет: обе оказии возвращаются назад другой стороной, а поэтому каж-
дая из сторон имеет возможность обнаружить по значению возвращаемой оказии
признаки атаки воспроизведения. Такой подход требуется тогда, когда синхро-
низация часов невозможна.
Версия 3 стандарта Х.509
Формат Х.509 версии 2, как показал опыт последних лет, не дает исчерпы-
вающих рекомендаций во всех необходимых случаях. В [FORD95] представлен
следующий список требований, не удовлетворяемых версией 2.
1. Формат поля субъекта не является оптимальным для сопровождения ин-
формации, идентифицирующей владельца ключа для пользователя откры-
того ключа. Имена Х.509 могут быть относительно короткими и не содер-
жать некоторых деталей идентификации, которые могут понадобиться
пользователю.
142
Часть II. Приложения сетевой защиты
2. Формат поля субъекта также не подходит для многих приложений, которые
обычно распознают объекты по адресу электронной почты, URL или неко-
торому другому связанному с Internet идентификатору.
3. Существует необходимость указывать информацию, характеризующую по-
литику защиты. Это позволит приложению или функции защиты, например
IPSec, связать сертификат Х.509 с применяемой политикой защиты.
4. Имеется необходимость ограничить ущерб, который может быть нанесен из-
за ошибочных или злонамеренных действий центра сертификации, путем
установки ограничений на область применимости конкретного сертификата.
5. Важно иметь возможность распознавать разные ключи, применяемые одним
и тем же владельцем в разное время. Эта возможность предполагает управ-
ление жизненным циклом ключей и, в частности, возможность изменять
пары ключей для пользователей и центров сертификации на регулярной ос-
нове или при особых обстоятельствах.
Разработчики стандарта сочли, что в данном случае требуется не простое добав-
ление полей к имеющемуся формату, а более гибкий подход. В результате формат
версии 3 включает ряд необязательных расширений, которые могут быть добавлены
к формату версии 2. Каждое расширение состоит из идентификатора расширения,
индикатора критичности и значения расширения. Индикатор критичности показы-
вает, может ли расппгрение быть безопасно игнорировано. Если этот индикатор име-
ет значение TRUE и используемая система не распознает расширение, данная систе-
ма должна считать такой сертификат недействительным.
Расширения сертификата можно разделить на три главные категории: ин-
формация о ключах и политиках, атрибуты субъекта и центра сертификации,
ограничения маршрута сертификации.
Информация о ключах и политиках
Соответствующие расширения содержат дополнительную информацию о клю-
чах субъекта и центра сертификации, а также индикаторы политики сертификации.
Политика сертификации представляет собой именованное множество правил, опре-
деляющих применимость сертификата в конкретных средах и/или классах прило-
жений с общими требованиями защиты. Например, политика может быть предна-
значена для аутентификации электронного обмена данными (Electronic Data Inter-
change — EDI) при торговле с заданным диапазоном цен товаров.
Эта область сертификата включает следующее.
• Идентификатор ключа центра сертификации. Идентифицирует открытый
ключ, используемый для проверки подписи данного сертификата или спи-
ска отозванных сертификатов. Позволяет различать разные ключи одного
центра сертификации. Это поле используется при обновлении пары ключей
центра сертификации.
• Идентификатор ключа субъекта. Идентифицирует открытый ключ, тре-
бующий сертификации, что полезно при обновлении пар ключей субъекта.
Субъект может иметь несколько пар ключей и, соответственно, несколько
разных сертификатов для различных целей (например, для цифровых под-
писей и шифрования).
Глава 4. Приложения аутентификации
143
• Использование ключа. Указывает ограничения и политики, при которых
может использоваться данный сертифицированный открытый ключ. Может
быть указано следующее: цифровая подпись, невозможность отказа от ав-
торства, шифрование ключей, шифрование данных, соглашения о ключах,
верификация подписи центра сертификации в сертификатах, верификация
подписи центра сертификации в списках отозванных сертификатов.
• Срок использования личного ключа. Указывает срок, в течение которого
должен использоваться личный ключ, соответствующей данному открытому
ключу. Обычно для личного ключа срок его действия отличается от срока
действия открытого ключа. Например, для ключей цифровых подписей
время применения личного ключа для подписи обычно меньше времени
действия открытого ключа для проверки подписи.
• Политики сертификации. Сертификаты могут использоваться в среде, пред-
полагающей возможность применения различных политик сертификации.
Данное расширение предлагает список политик, распознаваемых сертифи-
катом, а также дополнительную уточняющую информацию.
• Отображения политик. Используется только в сертификатах центров серти-
фикации, выданных другим центрам сертификации. Отображение политик
позволяет центру сертификации выяснить, является ли одна или несколько
таких политик эквивалентными другой политике, используемой в домене
центра сертификации, выступающего в качестве субъекта сертификации.
Субъект сертификации и атрибуты центра сертификации
Соответствующие расширения поддерживают альтернативные имена в альтер-
нативных форматах для указания субъекта сертификации и центра выдачи серти-
фикатов. Расширения могут также содержать дополнительную информацию о субъ-
екте сертификации, обеспечивая уверенность пользователя сертификата в том, что
субъект сертификации является именно тем лицом или объектом, на который ука-
зывает сертификат. Например, речь может идти о почтовом адресе, занимаемой
должности в корпорации или фотографическом изображении.
Поля расширения в этой области включают следующее.
• Альтернативное имя субъекта. Содержит одно или несколько альтернатив-
ных имен в любой из множества допустимых форм. Это поле оказывается
важным для некоторых приложений, например электронной почты, элек-
тронного обмена данными и IPSec, которые могут поддерживать свои собст-
венные форматы имен.
• Альтернативное имя центра сертификации. Содержит одно или несколько
альтернативных имен в любой из множества допустимых форм.
• Атрибуты каталога субъекта. Содержит значения любых атрибутов катало-
га Х.500, необходимых субъекту данного сертификата.
Ограничения маршрута сертификации
Соответствующие расширения позволяют указать в сертификатах, выдавае-
мых центрами сертификации другим центрам сертификации, целый ряд специ-
фикаций. Можно указать ограничения на типы сертификатов, которые могут
144
Часть II. Приложения сетевой защиты
выдаваться центру-субъекту, или на то, что допускается дальше в цепочке сер-
тификатов.
Поля расширения в этой области включают следующее.
• Основные ограничения. Указывают, может ли субъект выступать в качестве
центра сертификации. Если да, то могут быть заданы ограничения на длину
маршрута сертификации.
• Ограничения имен. Указывают пространство имен, в рамках которого
должны находиться все имена субъектов в последующих сертификатах
маршрута сертификации.
• Ограничения политик. Задают ограничения, которые может требовать явно
указанная политика идентификации сертификатов или блокировать ото-
бражение политик для оставшейся части маршрута сертификации.
4.3. РЕКОМЕНДУЕМЫЕ ИСТОЧНИКИ
ДОПОЛНИТЕЛЬНОЙ ИНФОРМАЦИИ
Принципы работы Kerboros проще всего представлены в [BRAY88]. Одним
из лучших описаний Kerberos является также [KOHL94].
: BRYA88 Bryant, W. Designing an Authentication System: A Dialogue in Four Scenes.
Project Athena document, February 1988. Доступно по адресу
http://web.mit.edu/kerberos/www/dialogue.html.
KOHL94 Kohl, J., Nemnan, B., Ts’o, T. “The Evolution of the Kerberos
Authentication Service.” Cm. Brazier, F., Johansen, D. Distributed Open Systems.
Los Alamitos, CA: IEEE Computer Society Press, 1994. Доступно по адресу1
http://web.mit.edu/kerberos/www/papers.html.
k Рекомендуемые Web-узлы
йШ • Узел Kerberos Массачусетсского технологического институ-
та (MIT). Информация о Kerberos, включая FAQ, статьи и
I документы, ссылки на узлы соответствующих коммерческих
версий продукта.
• Страница Kerberos USC/ISI. Другой хороший источник мате-
риалов о Kerberos.
• Рабочая группа по разработке инфраструктуры открытых
ключей. Основанные на использовании X.509v3 стандарты
группы разработки IETF (Internet Engineering Task Force —
проблемная группа проектирования Internet).
• Verisign. Ведущий коммерческий поставщик продуктов
Х.509, узел которого предлагает Белую книгу и другие цен-
ные материалы.
Глава 4. Приложения аутентификации
145
4.4. ЗАДАЧИ
4.1. Докажите, что в режиме РСВС (см. рис. 4.7) случайная ошибка в одном блоке шиф-
рованного текста распространится на все последующие блоки открытого текста.
4.2. Предположим, что в режиме РСВС блоки С, и С;+1 при передаче сообщения
поменялись местами. Докажите, что это повлияет только на дешифрованные
блоки Д и Д+1, но не на последующие блоки.
4.3. Оригинальная процедура трехшаговой аутентификации Х.509, показанная на
рис. 4.5, в, имеет недостаток с точки зрения защиты. Суть протокола заключа-
ется в следующем.
А-эВ: A{tA,rA,B},
В—эА: В{tB, гв, А, гА},
А—эВ: А{гв}.
В документе Х.509 говорится о том, что контрольные штампы даты-времени tA
и tB для процедуры трехшаговой аутентификации необязательны. Но рассмот-
рим следующий пример. Предположим, что А и В уже использовали указанный
выше протокол в каком-то предыдущем случае и противник С перехватил три
соответствующих сообщения. Предположим также, что штампы даты-времени
не использовались и были установлены равными 0. Наконец, допустим, что С
намерен вступить в контакт с В, выступая от имени А. Тогда С сначала посыла-
ет В первое из перехваченных сообщений.
С-эВ: А{0, гА,В}.
Пользователь В, считая, что отправителем сообщения является А, отвечает на
самом деле С:
В—эС: В{О,г;,А,га}.
Тем временем С каким-то образом заставляет А начать процесс аутентификации.
В результате А посылает С сообщение вида
А—эС: А{0, гА,В}
Противник С отвечает А, используя оказию, полученную им от В:
С—эА: С{0, гв, А, гА}.
Сторона А отвечает сообщением
А—эС : А{гв}.
Именно это требуется С для того, чтобы убедить В, что последний говорит с А,
так что теперь С остается только воспроизвести поступившее сообщение для В.
С-эВ: А{гв}.
Таким образом, В будет считать, что он говорит с А, тогда как на самом деле он
будет говорить с С. Предложите простое решение этой проблемы, не предпола-
гающее использования штампов даты-времени.
4.4. Версия Х.509 от 1988 года предлагает список свойств, удовлетворение которых
должно гарантировать защищенность ключей RSA с учетом известной сложно-
сти задачи разложения больших чисел на множители. Соответствующее рас-
146
Часть II. Приложения сетевой защиты
смотрение заканчивается ограничениями на открытые значения показателя и
модуля сравнения п.
Должно выполняться неравенство е > log2(«), чтобы не было возможности восстано-
вить открытый текст сообщения путем вычисления корня порядка е по модулю п.
Само ограничение является корректным, но вот аргумент, выдвигаемый в качестве
обоснования ограничения, некорректен. В чем заключается некорректность предло-
женного обоснования и какова истинная причина ввода такого ограничения?
ДОПОЛНЕНИЕ 4.1. МЕТОДЫ ШИФРОВАНИЯ
KERBEROS
Kerberos включает библиотеку методов шифрования для поддержки раз-
личных связанных с шифрованием операций.
Преобразование паролей в ключи
В системе Kerberos для паролей должны использоваться только символы,
которые можно представить в 7-битовом формате ASCII. Такой пароль произ-
вольной длины конвертируется в ключ шифрования, сохраняемый в базе данных
Kerberos. Схема соответствующей процедуры показана на рис. 4.6.
Сначала строка символов (s) переводится в такую строку битов (Ь), что пер-
вый символ сохраняется в первых 7 битах, второй — во вторых 7 битах и т.д.
Это можно представить в следующем виде.
Ь[0] = бит 0 символа s[0],
b[6] = бит 6 символа s[0],
b[7] = бит 0 символа s[l],
b[7;+;n] = бит т символа s[i], 0<m<6.
Затем эта строка битов сжимается, как гармошка, в строку из 56 бит с
применением операции побитового ИЛИ (XOR). Например, если битовая строка
имеет длину 59, то
Ь[55] = Ь[55] ® Ь[56],
Ь[54] = Ь[54] Ф Ь[57],
Ь[53] = Ь[53] Ф Ь[58],
Ь[52] = Ь[52] ф Ь[59],
b[51] = Ь[51] Ф Ь[6О],
Ь[50] = Ь[50] Ф Ь[61],
Ь[49] = Ь[49] Ф Ь[62].
Так создается 56-битовый ключ DES. Чтобы привести его в соответствие с ожи-
даемым 64-битовым форматом ключа, полученная строка рассматривается как
последовательность из восьми 7-битовых блоков и отображается в восемь 8-
битовых блоков, в результате чего формируется входной ключ Kpw .
Глава 4. Приложения аутентификации 147
Пароль из
7-битовых
символов ASCII
(п символов)
Сжатый поток
битов
(7хпбит)
а) конвертирование пароля в поток битов
s[8]-s[15] sfn - 8]-s[n - 1]
выходной ключ
К€
в) вычисление контрольной суммы для пароля в режиме СВС
Рис. 4.6. Генерирование ключа шифрования из пароля
Наконец, оригинальный пароль шифруется в режиме СВС (режим сцепле-
ния шифрованных блоков) DES с использованием ключа Kpw . Последний 64-
битовый блок, возвращаемый в результате этого процесса, называется кон-
трольной суммой СВС, и именно он считается в данном случае выходным клю-
чом, ассоциированным с данным паролем.
Весь алгоритм в целом может рассматриваться как хэш-функция, отобра-
жающая произвольный пароль в 64-битовый хэш-код.
Режим распространения сцепления шифрованных блоков
Как говорилось в главе 2, в режиме СВС DES ввод алгоритма DES на каждой
стадии шифрования получается в результате связывания операцией XOR текущего
блока открытого текста и предыдущего блока шифрованного текста с использова-
148
Часть II. Приложения сетевой защиты
нием одного и того же ключа шифрования для всех блоков (см. рис. 2.7). Пре-
имущество этого режима по сравнению с режимом ЕСВ (режим электронной шиф-
ровальной книги), при котором каждый блок открытого текста шифруется незави-
симо, состоит в том, что в режиме СВС один и тот же повторяющийся блок откры-
того текста порождает разные блоки шифрованного текста.
Режим СВС характеризуется тем, что если при передаче блока шифрованно-
го текста С( происходит ошибка, эта ошибка распространяется на дешифрован-
ные блоки открытого текста р; и р;+|.
Версия 4 Kerberos использует расширение режима СВС, называемое режи-
мом распространения СВС (режим РСВС) [MEYE82], Этот режим характеризует-
ся тем, что ошибка в одном блоке шифрованного текста распространяется на все
последующие дешифрованные блоки сообщения, что превращает все эти блоки в
бесполезные. Таким образом, одновременно решается задача шифрования дан-
ных и обеспечивается их целостность.
Схема режима РСВС показана на рис. 4.7. В этой схеме ввод алгоритма
шифрования получается связыванием операцией XOR текущего блока открытого
текста, предыдущего блока шифрованного текста и предыдущего блока открыто-
го текста:
Сп = EK[Cn_!
Время = 1 Время = 2
(б) дешифрование
Рис. 4.7. Режим распространения сцепления шифрованных блоков (режим РСВС)
Глава 4. Приложения аутентификации
149
При дешифровании каждый блок шифрованного текста обрабатывается ал-
горитмом дешифрования. Затем вывод связывается операцией XOR с предыду-
щим блоком шифрованного текста и предыдущим блоком открытого текста.
Можно показать, что эта схема работает следующим образом:
DK[CJ = DK[EK[C,|4 © Р„_, © PJ]
= С„ч © Р,,-! © Р„ ,
С„ч Ф Рл_, © DK[C„] = Р„.
150
Часть II. Приложения сетевой защиты
ГЛАВА
5
Защита
электронной
почты
5.1. PGP
5.2. S/MIME
5.3. Рекомендуемые источники дополнительной
информации
5.4. Задачи
Дополнение 5.1. Сжатие данных с помощью ZIP
Дополнение 5.2. Преобразование в 64-символьный
формат
Дополнение 5.3. Генерирование случайных чисел PGP
Практически в любой распределенной среде электронная почта является
наиболее часто используемым сетевым приложением. Она также пред-
ставляет единственное распределенное приложение, которое широко
применяется на всех платформах любой архитектуры. Пользователи надеют-
ся иметь и действительно имеют возможность посылать почту другим поль-
зователям, с которыми они общаются непосредственно или через Internet,
используя для этого самые разные операционные системы и пакеты комму-
никационных программ.
С ростом зависимости от электронной почты возрастают требования к
средствам аутентификации и обеспечения конфиденциальности электронной
почты. Здесь особое место занимают две схемы, которые, скорее всего, в
ближайшие несколько лет будут удовлетворять требованиям большинства
пользователей: это Pretty Good Privacy (PGP) и S/MIME. Обе схемы рассмат-
риваются в следующих разделах.
5.1. PGP
Система PGP (Pretty Good Privacy — достаточно надежная секретность)
представляет собой весьма замечательное явление. В значительной степени яв-
ляясь плодом усилий одного человека, Фила Зиммермана (Phil Zimmermann),
PGP обеспечивает конфиденциальность и сервис аутентификации, которые мож-
но использовать для электронной почты и приложений хранения файлов. По
существу, Зиммерман сделал следующее.
1. Выбрал в качестве строительных блоков лучшие из доступных криптогра-
фических алгоритмов.
2. Интегрировал эти алгоритмы в одном универсальном приложении, незави-
симом от процессора и операционной системы и построенном на использо-
вании небольшого числа простых команд.
3. Объявил пакет, включающий документацию и исходный текст программы,
свободно доступным через Internet, электронные доски объявлений и ком-
мерческие сети типа CompuServe.
4. Заключил соглашение с некоторой компанией (бывшей Viacrypt, теперь
Network Associates) о разработке и поддержке недорогой коммерческой вер-
сии PGP, полностью совместимой с бесплатной.
Система PGP быстро получила признание и стала весьма популярной. Среди
причин популярности PGP можно назвать следующие.
1. Она широко доступна в версиях, выполняемых на множестве платформ,
включая DOS/Windows, UNIX, Macintosh и многие другие. Кроме того, су-
ществует коммерческая версия, предназначенная для пользователей, пред-
почитающих иметь поддержку производителя.
2. Система PGP основана на алгоритмах, которые выдержали проверку прак-
тикой и считаются исключительно надежными. В частности, в пакет вклю-
чены алгоритмы шифрования с открытым ключом RSA, DSS и алгоритм
Диффи-Хеллмана, алгоритмы традиционного шифрования CAST-128, IDEA
и TDEA, а также алгоритм хэширования SHA-1.
152
Часть II. Приложения сетевой защиты
3. Система PGP имеет очень широкую область применения — от корпораций,
которые хотят иметь стандартизованную схему шифрования файлов и со-
общений, до простых пользователей, которые нуждаются в защите своей
электронной переписки.
4. Система PGP не была разработана правительственной или какой-то другой
официальной организацией, и поэтому неподконтрольна им. Вследствие
этого PGP имеет дополнительную привлекательность для людей с инстинк-
тивным недоверием к “аппарату”.
Сначала мы рассмотрим общие принципы работы PGP, затем выясним, как
создаются и хранятся криптографические ключи, а в заключение обсудим жиз-
ненно важный вопрос управления открытыми ключами.
Обозначения
Большинство обозначений, используемых в этой главе, встречались вам
раньше, но некоторые обозначения являются новыми. Привести список обозна-
чений лучше в самом начале рассмотрения.
Ks — сеансовый ключ, используемый в схеме традиционного шифрования,
KRa — личный ключ пользователя А, используемый в схеме шифрования с от-
крытым ключом,
KUa — открытый ключ пользователя А, используемый в схеме шифрования с
открытым ключом,
ЕР — шифрование в схеме с открытым ключом,
DP — дешифрование в схеме с открытым ключом,
ЕС — шифрование в схеме традиционного шифрования,
DC — дешифрование в схеме традиционного шифрования,
Н — функция хэширования,
|| — конкатенация,
Z — сжатие с помощью алгоритма ZIP,
R64 — преобразование в 64-символьный формат ASCII.
В документации PGP часто используется термин секретный ключ, озна-
чающий ключ, составляющий пару с открытым ключом в схеме шифрования с
открытым ключом. Поскольку существует возможность перепутать такой ключ с
секретным ключом, используемым для традиционного шифрования, мы будем
применять термин личный ключ.
Описание работы системы
Функциональные возможности PGP, если не рассматривать управление
ключами, складываются из пяти сервисов: аутентификации, обеспечения
конфиденциальности, сжатия, совместимости на уровне электронной почты и
сегментации (табл. 5.1). Мы рассмотрим каждый из перечисленных сервисов
по очереди.
Глава 5. Защита электронной почты
153
Таблица 5.1. Краткая характеристика функций PGP
Функция Используемые алгоритмы Описание
Цифровая под- пись DSS/SHA или RSA/SHA С помощью SHA-1 создается хэш-код (профиль) сообщения. Профиль сообщения шифруется лич- ным ключом отправителя с помощью DSS или RSA и включается в сообщение
Шифрование со- общения CAST либо IDEA, либо “тройной” DES с тремя ключами и алгоритмом Диффи-Хеллмана или RSA Сообщение шифруется с помощью CAST-128 или IDEA, или 3DES с одноразовым сеансовым клю- чом, генерируемым отправителем. Сеансовый ключ шифруется с помощью алгоритма Диффи- Хеллмана или RSA с использованием открытого ключа получателя и включается в сообщение
Сжатие ZIP Сообщение можно сжать для хранения или пере- дачи, используя ZIP
Совместимость на уровне элек- тронной почты Преобразование в 64-символьный формат Чтобы обеспечить прозрачность для всех приложе- ний электронной почты, шифрованное сообщение можно превратить в строку ASCII, используя пре- образование в 64-символьный формат
Сегментация — Чтобы соотвествовать ограничениям максимально- го размера сообщений, PGP выполняет сегмента- цию и обратную сборку сообщения
Аутентификация
На рис. 5.1, а показана схема сервиса цифровой подписи, предлагаемая
PGP. Эта схема соответствует схеме цифровой подписи, рассмотренной в главе 3
и показанной на рис. 3.2, б. При этом выполняется следующая последователь-
ность действий.
1. Отправитель создает сообщение.
2. С помощью алгоритма SHA-1 получается 160-битовый хэш-код сообщения.
3. Полученный хэш-код шифруется алгоритмом RSA с использованием лично-
го ключа отправителя, и результат добавляется в начало сообщения.
4. Получатель использует RSA с открытым ключом отправителя, чтобы де-
шифровать хэш-код.
5. Получатель генерирует новый хэш-код полученного сообщения и сравнивает
его с дешифрованным хэш-кодом. Если хэш-коды совпадают, сообщение
считается подлинным.
Комбинация SHA-1 и RSA обеспечивает эффективность схемы цифровой
подписи. Ввиду надежности RSA получатель уверен в том, что данную подпись
мог создать только владелец соответствующего секретного ключа. Надежность
SHA-1 дает получателю уверенность в том, что никто другой не мог создать дру-
гое сообщение с соответствующим хэш-кодом и, следовательно, с подписью из
оригинального сообщения.
154
Часть II. Приложения сетевой защиты
в) конфиденциальность и аутентификация
Рис. 5.1. Криптографические функции PGP
Подписи могут также генерироваться с помощью комбинации DSS/SHA-1.
Хотя подписи обычно присоединяются к сообщениям или файлам, для ко-
торых они создаются, дело не всегда обстоит так: поддерживаются и отделенные
подписи. Такая подпись может храниться и передаваться отдельно от самого со-
общения. Это оказывается полезным в целом ряде случаев. Пользователь может
поддерживать специальный журнал подписей всех посылаемых и получаемых
им сообщений. Отделенная подпись исполняемой программы поможет обнару-
жить заражение программы вирусом. Наконец такие подписи могут использо-
ваться тогда, когда подписывать документ (например конктракт) должна не одна
сторона, а несколько. Подпись каждой из сторон оказывается независимой и,
следовательно, применимой только к данному документу. Иначе подписи долж-
ны быть вложенными, т.е. вторая сторона подписывала бы документ вместе с
подписью первой стороны и т.д.
Конфиденциальность
Другим сервисом, предлагаемым PGP, является конфиденциальность, обес-
печиваемая шифрованием сообщений, передаваемых или хранимых в виде фай-
лов. В обоих случаях можно использовать традиционное шифрование на основе
алгоритма CAST-128. Альтернативой является применение алгоритмов IDEA или
TDEA. При этом используется режим обратной связи шифрованных 64-битовых
блоков (режим CFB).
Глава 5. Защита электронной почты
155
Как всегда, необходимо решать проблему распределения ключей. В PGP
каждый ключ схемы традиционного шифрования применяется только один раз.
Это значит, что для каждого сообщения генерируется новый ключ в виде слу-
чайного 128-битового числа. Таким образом, хотя в документации такой ключ
называется сеансовым, на самом деле он является одноразовым. Поскольку
ключ задействуется только один раз, он присоединяется к сообщению и переда-
ется вместе с ним. Чтобы защитить ключ, он шифруется с помощью открытого
ключа получателя. Соответствующая схема, показанная на рис. 5.1, б, может
быть описана следующим образом.
1. Отправитель генерирует сообщение и случайное 128-битовое число, которое
выступает в качестве сеансового ключа только для этого сообщения.
2. Сообщение шифруется с помощью алгоритма CAST-128 (или IDEA, или
TDEA) и данного сеансового ключа.
3. Сеансовый ключ шифруется с помощью алгоритма RSA и открытого ключа
получателя и присоединяется к началу сообщения.
4. Получатель использует RSA с личным ключом, чтобы дешифровать и тем
самым восстановить сеансовый ключ.
5. Сеансовый ключ применяется для дешифрования сообщения.
Чтобы обеспечить альтернативу использованию RSA при шифровании клю-
ча, в PGP предлагается параметр Diffie-Hellman (алгоритм Диффи-Хеллмана).
Как уже отмечалось в главе 3, алгоритм Диффи-Хеллмана является алгоритмом
обмена ключами. На самом деле в PGP используется алгоритм Эль-Гамаля
(ElGamal) — вариант алгоритма Диффи-Хеллмана, предлагающий возможности
шифрования/дешифрования.
В связи с этим можно сделать несколько замечаний. Во-первых, чтобы
уменьшить время шифрования, преимущество отдается комбинации традицион-
ного шифрования и шифрования с открытым ключом, а не простому использо-
ванию RSA или алгоритма Эль-Гамаля, когда сообщение шифруется непосредст-
венно: CAST-128 и другие алгоритмы традиционной схемы шифрования значи-
тельно быстрее, чем RSA или алгоритм Эль-Гамаля. Во-вторых, использование
алгоритмов схемы шифрования с открытым ключом решает проблему распреде-
ления сеансовых ключей, поскольку только для получателя оказывается воз-
можным восстановить сеансовый ключ, присоединенный к сообщению. Каждое
сообщение является одиночным независимым событием со своим собственным
ключом. Наконец, использование одноразовых ключей в традиционной схеме
шифрования еще более усиливает и без того достаточно надежный алгоритм тра-
диционного шифрования. Только небольшой объем открытого текста шифруется
с использованием одного ключа, и между ключами нет никакой связи. Таким
образом, вся схема оказывается защищенной в той мере, в какой защищен алго-
ритм схемы шифрования с открытым ключом. Поэтому PGP предлагает пользо-
вателю выбор для длины ключа от 768 до 3072 бит (длина ключа DSS для под-
писей ограничивается величиной в 1024 бит).
Конфиденциальность и аутентификация
Как показано на рис. 5.1, в, для одного сообщения можно использовать два
сервиса. Сначала для сообщения в виде открытого текста генерируется подпись,
156
Часть II. Приложения сетевой защиты
которая добавляется в начало сообщения. Затем открытый текст сообщения и
подпись шифруются с помощью алгоритма CAST-128 (или IDEA, или TDEA), а
сеансовый ключ шифруется с помощью RSA (или алгоритма Эль-Гамаля). Такая
схема предпочтительнее обратной, т.е. схемы, при которой сначала шифруется
сообщение, а затем для него генерируется подпись. В общем случае оказывается
более удобным хранить подпись с открытым текстом сообщения. К тому же, с
точки зрения возможностей верификации третьей стороной, если сначала гене-
рируется подпись, третьей стороне для проверки подписи не нужно знать ключ
традиционного шифрования.
Короче говоря, при использовании двух сервисов отправитель сначала под-
писывает сообщение с помощью собственного личного ключа, затем шифрует со-
общение с помощью сеансового ключа и наконец шифрует сеансовый ключ с по-
мощью открытого ключа получателя.
Сжатие
По умолчанию PGP сжимает сообщение после создания подписи, но перед
шифрованием. Это оказывается разумным с точки зрения уменьшения объема дан-
ных как при передаче электронной почты, так и при хранении в виде файлов.
Очень важным оказывается выбор точки применения алгоритма сжатия,
обозначенного на рис. 5.1 как Z при сжатии и как Z*1 при распаковке данных.
1. Подпись генерируется до сжатия по следующим причинам.
• Предпочтительнее подписывать несжатое сообщение, чтобы в будущем
иметь возможность хранить сообщение в несжатом в^де вместе с подпи-
сью. Если подписать сжатый документ, то для проверки необходимо бу-
дет либо хранить сжатую версию сообщения, либо сжимать сообщение
для каждой верификации.
• Даже при возможности динамически повторно сжимать сообщение для
верификации такой подход несет в себе дополнительные трудности из-за
самого алгоритма сжатия PGP: алгоритм не является детерминирован-
ным, и различные реализации алгоритма выбирают разные варианты оп-
тимизации соотношения скорости выполнения и сжатия, в результате
получаются сжатые файлы разной формы. Такие разные алгоритмы сжа-
тия являются переносимыми из-за того, что любая версия алгоритма мо-
жет правильно восстановить данные, полученные с помощью другой вер-
сии. Применение функции хэширования и создания подписи после сжа-
тия заставило бы во всех реализациях PGP применять один и тот же
алгоритм сжатия.
2. Шифрование сообщения применяется после сжатия для усиления крипто-
графической защиты сообщения. Поскольку сжатое сообщение имеет мень-
шую избыточность по сравнению с оригинальным открытым текстом, крип-
тоанализ оказывается более трудным делом.
В качестве алгоритма сжатия применяется ZIP, описание которого вы най-
дете в дополнении 5.1.
Глава 5. Защита электронной почты
157
Совместимость на уровне электронной почты
При использовании PGP шифруется по крайней мере часть передаваемо-
го блока. Если требуется только цифровая подпись, то шифруется профиль
сообщения (с использованием личного ключа отправителя). Если использует-
ся сервис обеспечения конфиденциальности, шифруется (с использованием
одноразового симметричного ключа) сообщение и подпись (при наличии по-
следней). Таким образом, часть или весь выходной блок сообщения пред-
ставляет собой поток произвольных 8-битовых байтов. Однако многие систе-
мы электронной почты позволяют использовать только блоки, состоящие из
символов текста ASCII. В связи с такими ограничениями, PGP поддерживает
сервис конвертирования 8-битового двоичного потока данных в поток печа-
таемых символов ASCII.
Для этого используется схема конвертирования в 64-символьный формат
(radix-64). Каждая группа из трех байтов двоичных данных преобразуется в
четыре символа ASCII, к которым присоединяется контрольная сумма (CRC),
позволяющая обнаружить ошибки при передаче данных. Подробности — в
дополнении 5.2.
Конвертирование в 64-символьный формат увеличивает длину переда-
ваемого сообщения на 33%. К счастью, сеансовый ключ и порция подписи
сообщения относительно компактны, а открытый текст сообщения сжимает-
ся. Фактически сжатие с избытком компенсирует расширение, получаемое в
результате перевода в 64-символьный формат. Например, в [HELD96] сооб-
щается о среднем коэффициенте сжатия для ZIP около 2,0. Если игнориро-
вать относительно небольшую подпись и компоненты ключа, типичное пол-
ное влияние сжатия и расширения для файла длины X должно быть прибли-
зительно равно 1,33 х 0,5 хХ= 0,665 х X. Таким образом, имеет место общее
сжатие примерно на одну треть.
Отличительной особенностью алгоритма radix-64 является то, что он кон-
вертирует входной поток в 64-символьный формат невзирая на содержимое —
даже если ввод уже оказывается текстом ASCII. Таким образом, если сообщение
подписано, но не шифруется, и конвертирование применяется ко всему блоку, то
выходной поток данных будет непонятен случайному наблюдателю, что уже
обеспечивает определенный уровень конфиденциальности. Для PGP можно вы-
брать такую конфигурацию, чтобы конвертирование в 64-символьный формат
выполнялось только для порции подписи открытого сообщения. Получатель при
этом имеет возможность прочитать сообщение без помощи PGP. Но PGP придет-
ся использовать, если потребуется проверить подпись.
На рис. 5.2 показана связь между четырьмя описанными выше сервиса-
ми. При передаче, если это требуется, подпись генерируется с помощью хэш-
кода открытого текста. Затем открытый текст и подпись, если последняя
имеется, сжимаются. Далее, если требуется конфиденциальность, блок
(сжатый открытый текст или сжатые подпись и открытый текст) шифруется,
и в начало добавляется шифрованный открытым ключом ключ шифрования
традиционной схемы. Наконец весь полученный блок конвертируется в 64-
символьный формат.
158
Часть II. Приложения сетевой защиты
а'- общая схема отправки (на стороне А) б) общая схема получения (на стороне В)
Рис. 5.2. Отправка и прием сообщений PGP
На стороне получателя поступающий блок сначала конвертируется обратно из
64-символьного формата в двоичный. Затем, если сообщение зашифровано, получа-
тель восстанавливает сеансовый ключ и дешифрует сообщение. Полученный в ре-
зультате блок разжимается. Если сообщение подписано, получатель восстанавливает
полученный хэш-код и сравнивает его с хэш-кодом, вычисленным им самим.
Сегментация и обратная сборка сообщения
Средства электронной почты часто ограничивают максимально допустимую
длину сообщения. Например, многие средства электронной почты, доступные че-
рез Internet, допускают пересылку сообщений длиной не более 50000 байт. Лю-
бое более длинное сообщение должно быть разбито на сегменты меньшей длины,
каждый из которых посылается отдельно.
Чтобы соответствовать такому ограничению, PGP автоматически разбивает
слишком длинные сообщения на сегменты, достаточно малые для того, чтобы их
можно было переслать с помощью электронной почты. Сегментация проводится
после выполнения всех других операций, включая преобразование в 64-
символьный формат. В результате компоненты ключа и подписи появляются
только один раз, в начале первого сегмента. На стороне получателя система PGP
должна отбросить заголовок электронной почты и вновь собрать весь оригиналь-
ный блок сообщения перед выполнением шагов, показанных на рис. 5.2, б.
Криптографические ключи и связки ключей
PGP использует четыре типа ключей: одноразовые сеансовые ключи схемы
традиционного шифрования, открытые ключи, личные ключи и парольные клю-
Глава 5. Защита электронной почты
159
чи схемы традиционного шифрования, описанные ниже. В отношении этих клю-
чей можно сформулировать следующие три требования.
1. Необходимо иметь средства генерирования непредсказуемых сеансовых
ключей.
2. Желательно, чтобы пользователь имел несколько пар открытых/личных клю-
чей. Тогда он сможет время от времени менять пару ключей. Но в результате
все сообщения, находящиеся в этот момент в пути следования, окажутся соз-
данными со старым ключом. К тому же получатели будут знать только старый
открытый ключ до тех пор, пока не получат новую версию ключа. В дополне-
ние к необходимости время от времени менять ключи пользователь может
иметь разные пары ключей для взаимодействия с разными группами получате-
лей или просто для того, чтобы усилить защиту, ограничивая объем материала,
шифруемого одним и тем же ключом. При этом теряется однозначность соот-
ветствия между пользователями и их открытыми ключами и возникает необхо-
димость в средствах, позволяющих идентифицировать конкретные ключи.
3. Каждый объект системы PGP должен поддерживать файл собственных пар
открытых/личных ключей, а также открытых ключей корреспондентов.
Рассмотрим эти требования по порядку.
Генерирование сеансовых ключей
Каждый сеансовый ключ связывается с одним сообщением и используется
только для шифрования и дешифрования этого сообщения. Вспомните, что
шифрование/дешифрование сообщения выполняется с помощью алгоритма сим-
метричной схемы шифрования. При этом алгоритмы CAST-128 и IDEA исполь-
зуют 128-битовые ключи, a TDEA — 168-битовый ключ. В дальнейшем обсуж-
дении для определенности мы предполагаем использование CAST-128.
Случайные 128-битовые числа генерируются с помощью самого алгоритма
CAST-128. Ввод для генератора случайных чисел складывается из 128-битового
ключа и двух 64-битовых блоков, которые рассматриваются как открытый
текст, подлежащий шифрованию. Используя режим шифрованной обратной свя-
зи, шифровальщик CAST-128 порождает два 64-битовых блока шифрованного
текста, которые связываются конкатенацией, в результате чего формируется
128-битовый сеансовый ключ.
“Открытый текст” для генератора случайных чисел, формируемый из двух
64-битовых блоков, извлекается из рандомизованного потока 128-битовых чисел.
Эти числа строятся на основе ввода с клавиатуры пользователя. Для создания
рандомизованного потока используется как время между нажатиями, так и ин-
формация о фактически нажатых клавишах. Таким образом, если пользователь
нажимает “случайные” клавиши в своем обычном темпе, будет порожден
“достаточно случайный” поток для ввода. Этот случайный ввод объединяется с
предыдущим сеансовым ключом, выданным алгоритмом CAST-128, чтобы сфор-
мировать данные для ввода генератору. В результате благодаря хорошим пере-
мешивающим свойствам CAST-128 порождается последовательность сеансовых
ключей, которая оказывается практически непредсказуемой.
Детали схемы генерирования случайных чисел PGP обсуждаются в допол-
нении 5.3.
160
Часть II. Приложения сетевой защиты
Идентификаторы ключей
Как уже говорилось выше, шифрованное сообщение сопровождается
шифрованным сеансовым ключом, использованным для шифрования сообще-
ния. Сеансовый ключ шифруется с помощью открытого ключа получателя.
Следовательно, только получатель сможет дешифровать сеансовый ключ,
чтобы с его помощью прочесть сообщение. Если бы каждый пользователь ис-
пользовал одну пару открытого и личного ключей, то получатель сразу бы
знал, с помощью какого ключа можно дешифровать сеансовый ключ — с по-
мощью единственного личного ключа получателя. Однако мы выдвинули
требование, чтобы пользователь мог иметь любое число пар откры-
тых/личных ключей.
Как в этом случае получателю узнать, какой из открытых ключей ис-
пользовался для шифрования сеансового ключа? Простейшим решением яв-
ляется передача открытого ключа вместе с сообщением. Получатель мог бы
тогда удостовериться, что это действительно один из открытых ключей, а за-
тем продолжить обработку сообщения. Эта схема должна работать, но при
этом пересылается слишком много лишних данных. Открытый ключ RSA
может иметь длину в сотни десятичных разрядов. Другим решением являет-
ся связывание с каждым открытым ключом некоторого идентификатора,
уникального по крайней мере для одного пользователя. Для этой цели впол-
не подойдет, например, комбинация идентификатора пользователя и иденти-
фикатора ключа. При этом придется пересылать только короткий идентифи-
катор ключа. Такое решение, однако, порождает проблему управления:
идентификаторы ключей должны выбираться и храниться так, чтобы как
отправитель, так и получатель могли установить соответствие между иден-
тификаторами ключей и самими открытыми ключами. Это кажется несколь-
ко обременительным.
В PGP принято решение присвоить каждому открытому ключу идентифи-
катор, который с очень высокой вероятностью должен быть уникальным для
данного пользователя. Идентификатор, связываемый с каждым открытым клю-
чом, представляет собой значение, хранящееся в младших 64 разрядах ключа.
Это значит, что идентификатор открытого ключа KUa равен (KUamod264). Этой
пдины достаточно для того, чтобы вероятность дублирования идентификаторов
ключей оказалась очень малой.
Идентификатор ключа требуется и для цифровой подписи PGP. Из-за
того что отправитель может воспользоваться одним из нескольких личных
ключей для шифрования профиля сообщения, получатель должен знать, ка-
кой открытый ключ ему следует использовать. Поэтому раздел цифровой
подписи сообщения включает 64-битовый идентификатор соответствующего
открытого ключа. Получив сообщение, адресат проверяет, соответствует ли
пдентификатор известному ему открытому ключу отправителя, а затем при-
ступает к проверке подписи.
Теперь, определив понятие идентификатора ключа, мы можем более при-
стально взглянуть на формат передаваемого сообщения (рис. 5.3). Сообщение
складывается из трех компонентов: собственно сообщения, его подписи
необязательно) и сеансового ключа (необязательно).
Глава 5. Защита электронной почты
161
Содержимое
Компонент
сеансового
ключа
Подпись
Сообщение
Идентификатор открытого
ключа получателя (KUb)
Сеансовый ключ (К s)
Штамп даты-времени
Идентификатор открытого
ключа отправителя (KUa)
Ведущие два октета
профиля сообщения
Профиль сообщения
Имя файла
Штамп даты-времени
Данные
Операция
Екиь
EKRa
Обозначения:
ЕкиЬ — шифрование с нспользованиемлнчного ключа пользователя В,
ЕкИа — шифрование с использованием открытого ключа пользователя А,
Eks — шифрование с использованием сеансового ключа,
ZIP —функция сжатия Zip,
R64 — функция преобразования в формат radix-64.
Рис. 5.3. Общий, формат сообщения PGP (от А к В)
• Компонент сообщения включает фактические данные, предназначенные для
хранения или передачи, а также имя файла и штамп даты-времени, указы-
вающий время создания сообщения.
• Компонент подписи включает следующие элементы.
• Штамп даты-времени. Время создания подписи.
• Профиль сообщения. 160-битовый профиль сообщения, созданный с помо-
щью SHA-1 и зашифрованный с использованием личного ключа подписи
отправителя. Профиль вычисляется для штампа даты-времени подписи,
связанного конкатенацией с порцией данных компонента сообщения.
Включение штампа даты-времени подписи в профиль сообщения обеспечи-
вает защиту от атак воспроизведения. Исключение имени файла и штампа
даты-времени компонента сообщения гарантирует, что отделенная подпись
будет в точности совпадать с подписью, добавляемой в префикс сообщения.
Отделенные подписи вычисляются непосредственно для файла, без полей
заголовка компонента сообщения.
162
Часть II. Приложения сетевой защиты
• Ведущие два октета профиля сообщения. Чтобы обеспечить получателю воз-
можность определить, соответствующий ли открытый ключ использовался для
дешифрования профиля сообщения с целью аутентификации, проводится срав-
нение этих первых двух октетов открытого текста исходного профиля с первы-
ми двумя октетами дешифрованного профиля. Эти октеты также выполняют
роль 16-битовой контрольной последовательности для сообщения.
• Идентификатор открытого ключа отправителя. Идентифицирует открытый
ключ, который должен использоваться для дешифрования профиля сообще-
ния и, следовательно, идентифицирует личный ключ, использовавшийся
для шифрования профиля сообщения.
Компонент сообщения и необязательный компонент подписи могут быть
:.-.аты с помощью ZIP и зашифрованы с использованием сеансового ключа.
Компонент сеансового ключа содержит сеансовый ключ и идентификатор
открытого ключа получателя, который использовался отправителем для шифро-
зания данного сеансового ключа.
Весь блок обычно переводится в 64-символьный формат.
Связки ключей
Мы видели, что идентификаторы ключей в PGP очень важны, и два иден-
тификатора ключей включаются в любое сообщение PGP, предполагающее кон-
фштенциальность и аутентификацию. Эти ключи необходимо хранить и органи-
зм зать некоторым стандартизованным образом для эффективного применения
з-меми сторонами, участвующими в обмене данными. Используемая в PGP схема
предполагает создание в каждом узле двух структур данных, из которых одна
используется для хранения пар открытых/секретных ключей данного узла, а
другая — для хранения открытых ключей других пользователей, известных
данному узлу. Эти структуры данных называются соответственно связкой лич-
- :.х ключей и связкой открытых ключей.
Общая структура связки личных ключей показана на рис. 5.4. Связку мож-
Ill I
: интерпретировать как таблицу, в которой каждая строка представляет одну
связанных ключей
(открытый и личный),
принадлежащих данному пользо-
нагелю. Строки состоят из следующих полей.
• Штамп даты-времени. Дата и время создания данной'пары ключей.
• Идентификатор ключа. Младшие 64 разряда открытого ключа данной строки.
• Открытый ключ. Открытый ключ данной пары.
• Личный ключ. Личный ключ данной пары; это поле шифруется.
• Идентификатор пользователя. Обычно здесь размещается адрес электрон-
ной почты пользователя (например stallings@acm.org). Однако пользователь
может указать для каждой пары ключей разные имена (например, Stallings,
WStallings, WilliamStallings и т.п.) или использовать один идентификатор
несколько раз.
Связка личных ключей может быть индексирована либо по полю Иденти-
Г'::-'.=тор пользователя, либо по полю Идентификатор ключа; цель такой ин-
Гтнсации мы выясним позже.
i лава 5. Защита электронной почты
163
Связка личных ключей
Штамп Идентификатор Открытый Шифрованный Идентификатор
даты-временн ключа* ключ личный ключ пользователя*
Tj KU; mod 2м KUj EH(Pi)[KRi] "'тел™'
Связка открытых ключей
Штамп даты-времени Идентификатор ключа* Открытый ключ Доверие владельцу Идентификатор пользователя* Законность ключа Подпись (подписи) Доверие подписи (подписям)
т. KU i mod 2й KUj флаг_ Пользова- флаг.
доверия j тель i доверия j
* — поле, используемое для индексации таблицы
Рис. 5.4. Общая структура связок личных и открытых ключей
Хотя предполагается, что связка личных ключей должна храниться только
на машине пользователя, создавшего и владеющего соответствующими парами
ключей, и должна быть доступна только этому пользователю, имеет смысл сде-
лать значения личных ключей защищенными настолько, насколько это возмож-
но. Соответственно, сам личный ключ в открытом виде в связке ключей не хра-
нится, а шифруется с помощью CAST-128 (или IDEA, или TDEA). При этом ис-
пользуется следующая процедура.
1. Пользователь выбирает фразу-пароль, которая будет служить для шифрова-
ния личных ключей.
2. Когда система с помощью RSA генерирует новую пару связанных ключей
(открытый и личный), она требует от пользователя указать такую фразу-
пароль. Из нее с помощью SHA-1 генерируется 160-битовый хэш-код, а за-
тем пароль удаляется.
3. Система шифрует личный ключ с помощью CAST-128, используя 128 бит
хэш-кода в качестве ключа. Хэш-код затем удаляется, а шифрованный лич-
ный ключ сохраняется в связке личных ключей.
Впоследствии, когда пользователь обратится к связке, чтобы извлечь лич-
ный ключ, ему придется снова указать фразу-пароль. PGP извлечет шифрован-
ный личный ключ, вычислит хэш-код пароля и дешифрует личный ключ с по-
мощью CAST-128 с данным хэш-кодом.
164
Часть II. Приложения сетевой защиты
Это очень компактная и эффективная схема. Как и в любой основанной
н= паролях системе, защищенность всей системы зависит от защищенности
пароля. Чтобы не поддаться искушению записать пароль, пользователь дол-
изан использовать такую парольную фразу, которую угадать нелегко, а за-
д:мнить — просто.
На рис. 5.4 показана и общая структура связки открытых ключей. Эта
здруктура данных позволяет хранить открытые ключи других пользователей,
известных данному узлу. Пока проигнорируем некоторые поля, указанные в
таблице, и опишем только часть из них.
• Штамп даты-времени. Дата и время создания данной записи.
• Идентификатор ключа. Младшие 64 разряда открытого ключа данной записи.
• Открытый ключ. Открытый ключ данной записи.
• Идентификатор пользователя. Определяет владельца данного ключа. С од-
ним открытым ключом можно связать несколько идентификаторов пользо-
вателя.
Связка открытых ключей может быть индексирована либо по полю Иденти-
;ч?:атор пользователя, либо по полю Идентификатор ключа; цель такой ин-
дексации мы выясним позже.
Теперь мы можем показать, как эти связки ключей применяются при пе-
редаче и приеме сообщений. Для простоты в следующем примере мы игнори-
руем сжатие и преобразование в 64-символьный формат. Сначала рассмотрим
передачу сообщения (рис. 5.5) и предположим, что сообщение должно быть и
дздписано, и зашифровано. Посылающий сообщение объект PGP выполняет
зледующие шаги.
1. Создание подписи сообщения.
• PGP извлекает личный ключ отправителя из связки личных ключей, ис-
пользуя введенное значение your_userid в качестве ключа поиска. Если
соответствующая команда не предлагает значения your_userid, выбира-
ется первый личный ключ в связке.
• PGP запрашивает у пользователя фразу-пароль, чтобы расшифровать
личный ключ.
• Создается компонент подписи сообщения.
2. Шифрование сообщения.
• PGP генерирует сеансовый ключ и шифрует сообщение.
• PGP извлекает открытый ключ получателя из связки открытых ключей,
используя значение her_userid в качестве ключа поиска.
• Создается компонент сеансового ключа сообщения.
Принимающий объект PGP выполняет следующие шаги (рис. 5.6).
1. Дешифрование сообщения.
• PGP извлекает личный ключ получателя из связки личных ключей, ис-
пользуя в качестве ключа поиска значение поля Идентификатор ключа
компонента сеансового ключа сообщения.
_ пава 5. Защита электронной почты
165
• PGP запрашивает у пользователя фразу-пароль, чтобы расшифровать
личный ключ.
• PGP восстанавливает сеансовый ключ и дешифрует сообщение.
Связка открытых
ключей
Рис. 5.5. Создание сообщения PGP (от А к В, без сжатия и преобразования в 64-символьный
формат )
2. Аутентификация сообщения.
• PGP извлекает открытый ключ отправителя из связки открытых ключей,
используя в качестве ключа поиска значение поля Идентификатор ключа
компонента подписи сообщения.
• PGP восстанавливает полученный профиль сообщения.
• PGP вычисляет профиль сообщения для принятого сообщения и сравни-
вает его с профилем, пришедшим вместе с сообщением, чтобы убедиться
в их идентичности.
Управление открытыми ключами
Как можно уже догадаться из приведенного выше описания, PGP содержит
ясный и эффективный набор взаимосвязанных функций и форматов, обеспечи-
вающих надежную конфиденциальность и средства аутентификации. Для завер-
шенности системы необходимо решить еще одну проблему, а именно проблему
управления открытыми ключами. В документации PGP о важности этой про-
блемы говорится следующее.
166
Часть II. Приложения сетевой защиты
Проблема защиты открытых ключей от несанкционированного вмешательства
является отдельной и наиболее сложной практической проблемой приложений,
использующих открытые ключи. Это “ахиллесова пята” криптографии с откры-
тым ключом, и в значительной мере сложность соответствующего программного
обеспечения определяется сложностью решения именно этой задачи.
PGP предлагает структуру для решения этой проблемы и ряд опций, кото-
рые могут при этом использоваться. Поскольку система PGP предназначена для
использования в самых разных условиях, нет никакой жесткой схемы управле-
ния открытыми ключами, как, например, в системе S/MIME, которую мы pac-
с.чотрим в этой же главе немного позже.
|>| 1)1
Пути решения проблемы управления открытыми ключами
Суть проблемы заключается в следующем. Пользователь А должен постро-
ить связку открытых ключей, содержащую открытые ключи других пользовате-
лей, чтобы взаимодействовать с ними, используя PGP. Предположим, что связка
с- пс-очей стороны А включает открытый ключ, приписанный стороне В, но на са-
чсм деле владельцем этого ключа является сторона С. Такая ситуация, в частно-
ст;:. может иметь место, если участник А взял ключ с электронной доски объяв-
лений (BBS), которую участник В использовал для пересылки открытого ключа,
: ключ был скомпрометирован неким С. В результате возникает угроза по двум
вправлениям. Во-первых, С может посылать сообщения А, фальсифицируя
. пава 5. Защита электронной почты
167
подпись В так, что А будет считать сообщения прибывшими от В. Во-вторых, С
сможет прочесть любое шифрованное сообщение от А к В.
Для минимизации риска того, что связка открытых ключей пользователя со-
держит ложные открытые ключи, можно предложить несколько вариантов дейст-
вий. Предположим, что А требуется получить надежный открытый ключ В. Вот не-
сколько вариантов процедуры, которую при этом можно было бы использовать.
1. Получение ключа от В лично (физически). Пользователь В может сохранить
свой открытый ключ (KUb) на дискете и вручить эту дискету пользователю
А. Пользователь А затем может загрузить такой ключ с дискеты в свою
систему. Это действительно безопасный путь, но он имеет свои очевидные
ограничения.
2. Проверка ключа по телефону. Если А может узнать голос В по телефону, то
А может позвонить В и попросить продиктовать ключ в 64-символьном
формате radix-64. Еще более удобным оказывается следующий вариант. В
передает свой ключ пользователю А в виде электронного сообщения. Поль-
зователь А с помощью PGP и SHA-1 генерирует 160-битовый профиль клю-
ча и представляет его в шестнадцатеричном формате; такой профиль назы-
вается “отпечатком” ключа. После этого А звонит В и просит продиктовать
строку, соответствующую отпечатку его ключа. Если два отпечатка совпа-
дут, ключ считается проверенным.
3. Получение открытого ключа В от внушающего доверие обеим сторонам на-
дежного посредника D. Для этого D создает подписанный сертификат. Та-
кой сертификат должен включать открытый ключ В, время его создания и
срок действия. Сторона D генерирует профиль SHA-1 этого сертификата,
шифрует его с помощью своего личного ключа и присоединяет полученную
подпись к сертификату. Поскольку создать такую подпись в состоянии
только D, никто не сможет фальсифицировать открытый ключ и заявить,
что он был подписан стороной D. Подписанный сертификат может быть
доставлен стороне А либо стороной В, либо стороной D, или же выставлен
на электронной доске объявлений.
4. Получение открытого ключа В от надежного центра сертификации. Опять
же, сертификат открытого ключа создается и подписывается центром сер-
тификации. Затем пользователь А, указав свое имя, получает подписанный
сертификат и доступ к соответствующему узлу.
В случаях 3 и 4 пользователь А должен иметь экземпляр открытого ключа
поставщика сертификатов и быть уверенным в его надежности. В конечном счете
А должен сам решить, насколько он доверяет стороне, выступающей в роли по-
ставщика сертификатов.
Использование степеней доверия
Хотя в системе PGP не определено никаких спецификаций, касающихся
выбора центров сертификации и установления доверительных отношений, PGP
предлагает удобные средства использования степеней доверия, информации о
них, а также связывания их с открытыми ключами.
Базовая схема выглядит следующим образом. Любой элемент в связке от-
крытых ключей является сертификатом открытого ключа. С каждым таким
168
Часть II. Приложения сетевой защиты
элементом связывается поле соответствия ключа, которое задает степень дове-
рия, с которой PGP будет считать, что указанный в сертификате пользователь
является истинным владельцем данного открытого ключа: чем выше степень до-
верия, тем сильнее привязка идентификатора пользователя к данному ключу.
Это поле вычисляется PGP. С каждым элементом связывается также некоторое
(возможно, нулевое) число подписей для данного сертификата, которые были со-
браны владельцем связки ключей. В свою очередь, с каждой подписью связыва-
ется поле доверия подписи, определяющее степень, с которой PGP доверяет дан-
ному объекту подписывать сертификаты открытых ключей. Значение поля соот-
ветствия ключа выводится из совокупности значений полей доверия подписи для
данного элемента связки ключей. Наконец, каждый элемент определяет откры-
тый ключ, связываемый с конкретным владельцем, а соответствующее поле до-
верия владельцу указывает степень доверия, с которой этот открытый ключ
может использоваться для подписи других сертификатов открытых ключей; эта
степень доверия определяется и присваивается пользователем. Значения полей
доверия подписи можно рассматривать как взятые из других элементов связки
ключей кэшированные копии значений полей доверия владельцу.
Таблица 5.2. Содержимое байта флага доверия
а) степень доверия владель-
цу открытого ключа
(размещается после пакета
информации о ключе, опре-
деляется пользователем)
Поле OWNERTRUST
— неопределенное доверие
— неизвестный пользователь
— минимальный уровень дове-
рия для подписи
— средний уровень доверия
для подписи
— максимальный уровень
доверия для подписи
— данный ключ присутствует в
связке секретных ключей
(наивысшее доверие)
Бит BUCKSTOP
— устанавливается, если дан-
ный ключ присутствует в
связке секретных ключей
б) степень доверия паре
“открытый
ключ/идентификатор поль-
зователя” (размещается по-
сле идентификатора пользо-
вателя, вычисляется PGP)
Поле KEYLEGIT
— неизвестное или неоп-
ределенное соответствие
— ненадежное соответст-
вие владельцу ключа
— минимально надежное
соответствие владель-
цу ключа
— полное соответствие
владельцу ключа
Бит WARNONLY
— устанавливается, если
пользователь желает
получить только пре-
дупреждение, когда
для шифрования ис-
пользуется не вполне
подтвержденный ключ
в) степень доверия подписи
(размещается после пакета
подписей, кэшированная ко-
пия значения поля
OWNERTRUST для данного
поставщика подписи)
Поле SIGTRUST
— неопределенное доверие
— неизвестный пользо-
ватель
— минимальный уровень
доверия для подписи
— средний уровень дове-
рия для подписи
— максимальный уровень
доверия для подписи
— данный ключ присут-
ствует в связке сек-
ретных ключей
(наивысшее доверие)
Бит CONTIG
— устанавливается, если
подпись восходит по
непрерывной цепочке
надежных сертифика-
тов к владельцу связ-
ки ключей с наивыс-
шим доверием
Глава 5. Защита электронной почты
169
Три поля, упоминаемые в предыдущем абзаце, содержатся в структуре, на-
зываемой байтом флага доверия. Содержимое флага доверия для каждого поля
показано в табл. 5.2. Предположим, что мы имеем дело со связкой открытых
ключей пользователя А. Операция определения степени доверия может быть
описана следующим образом.
1. При добавлении пользователем А нового открытого ключа в связку откры-
тых ключей система PGP должна присвоить значение флагу доверия, соот-
ветствующему владельцу этого открытого ключа. Если владельцем является
А (это значит, что тот же открытый ключ должен присутствовать и в связке
личных ключей), то полю доверия владельцу автоматически присваивается
значение, соответствующее наивысшему доверию. В противном случае PGP
спрашивает пользователя А о том, какой уровень доверия следует припи-
сать владельцу ключа, а пользователь А должен ввести подходящее значе-
ние. Пользователь может указать, что этот владелец неизвестен, ненадежен,
минимально надежен или вполне надежен.
2. При добавлении нового открытого ключа с ним можно связать одну или
несколько подписей. Позже можно добавить и другие подписи. При до-
бавлении подписи система PGP выполняет поиск в связке открытых
ключей, чтобы выяснить, значится ли имя владельца подписи среди из-
вестных владельцев открытых ключей. Если да, то значение поля
OWNERTRUST этого владельца присваивается полю SIGTRUST данной
подписи. В противном случае полю присваивается значение, соответст-
вующее неизвестному пользователю.
3. Значение поля соответствия ключа вычисляется на основе значений полей
доверия подписи данного элемента связки. Если хотя бы для одной подписи
в поле доверия подписи установлено значение, соответствующее наивысше-
му доверию, то в поле соответствия ключа помещается значение, означаю-
щее полное соответствие. В противном случае PGP вычисляет взвешенную
сумму значений полей доверия. Подписям с максимальным уровнем дове-
рия приписывается вес 1/Х, а подписям со средним уровнем доверия — вес
1/Y, где X и Y являются параметрами, задаваемыми пользователем. Если
общая сумма весов поставщиков комбинаций “ключ/идентификатор пользо-
вателя” достигает 1, то соответствие признается надежным, и в поле соот-
ветствия ключа помещается значение, означающее полное соответствие.
Таким образом, при отсутствии наивысшего доверия для полного соответст-
вия потребуется по крайней мере X подписей с максимальным уровнем до-
верия или Y подписей со средним уровнем доверия (или некоторая подхо-
дящая их комбинация).
Периодически PGP выполняет проверку связки открытых ключей, чтобы
поддерживать согласованность. Этот процесс является нисходящим. При такой
проверке PGP просматривает связку для каждого значения поля OWNERTRUST,
находит все подписи, автором которых является данный владелец, и обновляет
значения полей SIGTRUST, чтобы эти значения соответствовали значению поля
OWNERTRUST. Процесс начинается с ключей, для которых указано наивысшее
доверие. После этого значения всех полей KEYLEGIT пересчитываются на базе
новых значений для подписей.
170
Часть II. Приложения сетевой защиты
На рис. 5.7 показана схема, иллюстрирующая связь доверия подписи и соответ-
ствия ключа.1 На рисунке представлена структура связки открытых ключей. В дан-
ном случае пользователь получил несколько открытых ключей, какие-то непосредст-
венно от их владельцев, а какие-то от третьей стороны, например, с сервера ключей.
(•) — ключ, считающийся вами соответствующим владельцу
Рис. 5.7. Пример модели доверия PGP
Вершина, обозначенная на рисунке “Вы”, представляет элемент связки откры-
тых ключей, соответствующий данному пользователю. Этот ключ, очевидно, соответ-
ствует владельцу, поэтому значение поля OWNERTRUST соответствует наивысшему
доверию. Для остальных вершин поле OWNERTRUST в связке ключей будет иметь
значение, соответствующее неопределенному доверию, если только пользователь не
задаст некоторое другое значение. В данном примере пользователь указал, что он
всегда доверяет подписывать другие ключи пользователям D, Е, F и L. Частичное
доверие подписывать другие ключи получили пользователи А и В.
Таким образом, закраска или отсутствие таковой для вершин на рис. 5.7
соответствует уровню доверия, определенному для пользователей. Древовидная
структура указывает, какими пользователями были подписаны соответствующие
ключи. Если ключ был подписан пользователем, чей ключ также присутствует в
данной связке ключей, от подписанного ключа к подписавшему данный ключ
пользователю идет стрелка. Если ключ подписан пользователем, ключа которого
1 Этот рисунок предоставил автору Фил Зиммерман.
Глава 5. Защита электронной почты
171
в данной связке нет, стрелка идет от подписанного ключа к знаку вопроса, озна-
чающему, что подписавшая ключ сторона данному пользователю неизвестна.
На рис. 5.7 проиллюстрированы следующие моменты.
1. Обратите внимание на то, что все ключи, владельцам которых полностью
или частично доверяет данный пользователь, были подписаны этим пользо-
вателем, за исключением вершины L. Такая подпись пользователя не обяза-
тельна (и здесь ее нет для вершины L), но на практике большинство поль-
зователей, скорее всего, подпишут ключи всех владельцев, которым они до-
веряют. Поэтому, например, хотя ключ Е уже был подписан надежным
поставщиком F, пользователь решил подписать ключ Е лично.
2. Мы предполагаем, что двух отчасти надежных подписей достаточно для того,
чтобы сертифицировать ключ. Поэтому ключ Н расценивается системой PGP
как надежный (т.е. соответствующий владельцу), ввиду того, что он подписан
пользователями А и В, которым данный пользователь отчасти доверяет.
3. Ключ может считаться надежным, если он подписан одной вполне надежной
или двумя отчасти надежными сторонами, но может оказаться, что соответст-
вующему пользователю не доверяется подписывать другие ключи. Например,
ключ N является надежным, поскольку он подписан стороной Е, которой дан-
ный пользователь доверяет, но подписывать другие ключи стороне N не доверя-
ется, поскольку данный пользователь не присвоил N соответствующее значение
степени доверия. Поэтому, хотя ключ R и подписан стороной N, система PGP
не считает его надежным. Такая ситуация имеет совершенно определенный
смысл. Если вы хотите послать секретное сообщение некоторому адресату, со-
всем не обязательно, чтобы вы доверяли этому адресату хоть в какой-то степе-
ни. Необходимо только, чтобы вы были уверены в том, что имеете надежный
открытый ключ соответствующего пользователя.
4. На рис. 5.7 показан также пример отдельной “вершины-сироты” S с двумя не-
известными подписями. Такой ключ мог быть получен с сервера ключей. PGP
не может считать этот ключ надежным только потому, что этот ключ пришел с
имеющего хорошую репутацию сервера. Пользователь должен объявить этот
ключ надежным, подписав его лично или сообщив PGP о том, что он готов
полностью доверять одной из сторон, уже подписавших данный ключ.
В качестве резюме можно сказать следующее. Выше уже отмечалось, что с
одним открытым ключом в связке открытых ключей можно связать несколько
идентификаторов пользователей. Это может иметь место, например, в случае,
когда некоторая сторона меняет свое имя или выступает под многими именами,
указывая для себя разные адреса электронной почты. Поэтому открытый ключ
можно рассматривать как корень некоторого дерева. С открытым ключом связы-
вается некоторое число идентификаторов пользователей и ассоциированных с
каждым из них подписей. Привязка конкретного идентификатора пользователя
к ключу зависит от связываемых с этим идентификатором подписей, так что
степень доверия данному ключу (для использования его в подписях других клю-
чей) оказывается функцией всех соответствующих ему подписей.
Отзыв открытых ключей
Пользователь может отменить действие своего текущего открытого ключа
либо потому, что ключ скомпрометирован, либо для того, чтобы не допустить
172
Часть II. Приложения сетевой защиты
| использования одного и того же ключа в течение слишком долгого времени. 06-
i ратите внимание на то, что скомпрометировать ключ противник может, только
। получив либо экземпляр вашего личного ключа в открытом виде, либо личный
ключ из вашей связки личных ключей и вашу фразу-пароль.
Отзыв открытого ключа пользователя осуществляется в форме выпуска
сертификата отмены ключа, подписанного владельцем данного ключа. Этот
сертификат имеет такой же вид, как и обычный сертификат подписи, но
включает индикатор, указывающий на то, что данный сертификат отменяет
действие соответствующего открытого ключа. Для подписи сертификата, от-
меняющего открытый ключ, следует использовать соответствующий личный
ключ. Владелец должен распространить этот сертификат как можно шире и
быстрее, чтобы потенциальные корреспонденты могли внести изменения в
свои связки открытых ключей.
Следует учитывать, что противник, скомпрометировавший личный ключ
владельца, тоже может выпустить такой сертификат. Но это приведет к отрица-
нию соответствия ключа не только законному владельцу, но и противнику, по-
этому такая угроза кажется существенно меньшей, чем злонамеренное использо-
вание похищенного личного ключа.
5.2. S/MIME
Система S/MIME (Secure/Multipurpose Internet Mail Extension — защищен-
ные многоцелевые расширения электронной почты) является усовершенствова-
нием стандарта MIME электронной почты в Internet, определенным соответст-
вующими документами RFC и обеспечивающим защиту электронной почты на
базе использования технологии RSA Data Security. Хотя необходимую процедуру
становления стандарта IETF проходят и PGP, и S/MIME, есть основания пола-
гать, что S/MIME станет стандартом коммерческого и промышленного использо-
вания, a PGP останется альтернативой для защиты личной электронной почты
большинства индивидуальных пользователей.
Чтобы понять структуру протокола S/MIME, необходимо понять лежащий в
основе этого протокола формат электронной почты (MIME). Но, чтобы уяснить
значение MIME, нам придется сначала рассмотреть традиционный формат элек-
тронной почты, RFC 822, который все еще остается довольно популярным. Соот-
ветственно, в этом разделе сначала рассматриваются эти два более старых стан-
дарта, а затем уже описывается протокол S/MIME.
RFC 822
Документ RFC 822 определяет формат текстовых сообщений, пересылаемых
по электронной почте. Он стал стандартом для текстовых сообщений электрон-
ной почты в Internet и широко применяется до сих пор. В контексте документа
RFC 822 сообщения рассматриваются как объекты, имеющие конверт и содер-
жимое. Конверт содержит информацию, необходимую для пересылки и достав-
ки. Содержимое является объектом, доставляемым получателю. Стандарт
RFC 822 касается только представления содержимого. Но этот стандарт содер-
жимого определяет целый ряд полей заголовка, которые могут использоваться
Глава 5. Защита электронной почты
173
почтовой системой при создании конверта, и задача стандарта — упростить про-
цесс извлечения такой информации прикладной программой.
Общая структура сообщения, соответствующего стандарту RFC 822,
очень проста. Сообщение формируется из некоторого числа строк заголовка,
за которым следует текст неограниченной длины (тлело сообщения). Заголо-
вок сообщения отделяется от тела сообщения пустой строкой. Иными слова-
ми, сообщение является потоком символов ASCII, где все строки до первой
пустой строки считаются строками заголовка, используемыми агентом поч-
товой системы пользователя.
Строка заголовка обычно состоит из ключевого слова, завершающегося двоето-
чием, за которым следуют параметры. При этом формат допускает разбивать длин-
ные строки на несколько строк. Чаще всего используются такие ключевые слова,
как From (От), То (Для), Subject (Тема) и Date (Дата). Вот пример сообщения.
Date: Tue, 16 Jan 1998 10:37:17 (EST)
From: "William Stallings" <ws@shore.net>
Subject: Синтаксис RFC 822
To: Smith@Other-host.com
Cc: Jones@Yet-Another-Host.com
Привет. С этой строки начинается непосредственно тело сообщения,
которое отделяется от заголовка сообщения пустой строкой.
Еще одним полем, которое часто присутствует в заголовках сообщений
RFC 822, является поле Message-ID (идентификатор сообщения). Это поле со-
держит уникальный идентификатор, связываемый с данным сообщением.
Многоцелевые расширения электронной почты
Стандарт MIME является расширением RFC 822, призванным решить неко-
торые проблемы и преодолеть ограничения систем электронной почты, исполь-
зующих RFC 822 и протокол SMTP (Simple Mail Transfer Protocol — простой
протокол передачи почты) или другой аналогичный протокол. В [MURP95] пред-
ставлен следующий список ограничений схемы SMTP/822.
1. SMTP не позволяет передавать исполняемые файлы и другие объекты в
двоичном формате. Существует ряд схем преобразования двоичных файлов
в текстовые (к ним относится и популярная схема UUencode/UUdecode для
UNIX), которые затем могут быть использованы различными почтовыми
системами SMTP. Однако ни одна из таких схем не является стандартом
или хотя бы стандартом де-факто.
2. SMTP не позволяет передавать текстовые данные, включающие символы на-
циональных языков, поскольку такие символы представляются 8-битовыми
кодами с десятичными значениями от 128 и выше, a SMTP ограничивает
возможности передачи 7-битовыми кодами ASCII.
3. Серверы SMTP могут отвергнуть электронное сообщение, по длине превы-
шающее определенное значение.
4. Шлюзы SMTP, выполняющие трансляцию кодов ASCII в коды EBCDIC
(Extended Binary Coded Decimal Interchange Code — расширенный двоично-
174
Часть II. Приложения сетевой защиты
десятичный код обмена информацией) и обратно, могут иметь разные таб-
лицы перевода, что выливается в проблемы трансляции.
5. Шлюзы SMTP, связанные с сетями электронной почты протокола Х.400, не мо-
гут обработать нетекстовые данные, включаемые в сообщения стандарта Х.400.
6. Некоторые реализации протокола SMTP не слишком строго придерживают-
ся стандарта SMTP, определенного в документе RFC 821. При этом возни-
кают следующие типичные проблемы:
• исчезновение, добавление или изменение порядка символов возврата ка-
ретки и перехода на новую строку;
• усечение или разрыв строк, имеющих длину более 76 символов;
• удаление имеющихся в конце строки пропусков (символов табуляции и
пробелов);
• дополнение всех строк сообщения до одинаковой длины;
• преобразование символов табуляции в наборы нескольких символов пробела.
Стандарт MIME должен решать эти проблемы, сохраняя совместимость с
существующими реализациями RFC 822. Соответствующие технические специ-
фикации приводятся в документах RFC с номерами от 2045 до 2049.
Краткий обзор MIME
Технические спецификации MIME включают следующие элементы.
1. Определяется пять новых полей заголовка сообщения, которые могут вклю-
чаться в заголовок RFC 822. Эти поля несут в себе информацию о теле со-
общения.
2. Определяется несколько форматов содержимого, задающих стандарты пред-
ставления документов мультимедиа в сообщениях электронной почты.
3. Определяются стандарты кодировок передаваемых данных, позволяющие защи-
тить содержимое сообщения от изменения при выполнении почтовыми систе-
мами преобразований передаваемых данных из одного формата в другой.
Ниже мы рассмотрим пять полей заголовка сообщения, определяемых стан-
дартом MIME, а в следующих разделах будут описаны форматы содержимого и
кодировки передаваемых данных.
• MIME-Version (версия MIME). Соответствующий параметр должен иметь
значение 1.0. Это поле указывает на то, что сообщение соответствует стан-
дартам RFC 2045 и 2046.
• Content-Type (тип содержимого). Дает описание помещенных в тело сообщения
данных с достаточной подробностью для того, чтобы агент получателя мог вы-
брать подходящий механизм представления полученных данных пользователю
или обработать их каким-то иным соответствующим образом.
» Content-Transfer-Encoding (кодировка передаваемого содержимого). Указы-
вает тип преобразования, использовавшегося для представления тела сооб-
щения в виде, приемлемом для пересылки почтой.
• Content-Ш (идентификатор содержимого). Служит для того, чтобы уникальным
образом идентифицировать объекты MIME в различных контекстах.
Глава 5. Защита электронной почты
175
• Content-Description (описание содержимого). Текстовое описание объекта в
теле сообщения; оказывается полезным тогда, когда объект имеет форму,
отличную от обычного текста (например, звуковые данные).
Любое или все эти поля могут присутствовать в обычном заголовке RFC
822. Любая реализация, как минимум, должна поддерживать обработку полей
MIME-Version, Content-Type и Content-Transfer-Encoding, а поля Content-
ID и Content-Description являются опциями и в реализации получателя мо-
гут игнорироваться.
Типы содержимого MIME
Немалая часть спецификаций MIME касается определения множества до-
пустимых типов содержимого. Причиной этого является необходимость стандар-
тизации способов обработки информации, представляемой в неоднородной среде
в самых разных форматах.
В табл. 5.3 представлен список типов содержимого, определяемых в доку-
менте RFC 2046. Существует 7 основных типов содержимого и 15 подтипов. Во-
обще говоря, тип содержимого указывает общий тип данных, а подтип опреде-
ляет конкретный формат, используемый для представления этого типа данных.
Таблица 5.3. Типы содержимого MIME
Тип Подтип Описание
Text (текст) Plain (простой) Неформатированный текст; может быть в кодировке ASCII или ISO 8859
Enriched (расширенный) Формат, более гибкий по сравнению с простым тек- стовым
Multipart (многокомпо- нентный) Mixed (смешанный) Разные части независимы, но должны передаваться вместе. Они должны быть представлены получателю в том порядке, в котором они появляются в почтовом сообщении
Parallel (параллельный) Отличается от смешанного только тем, что не опреде- ляется порядок, в котором части сообщения должны быть представлены получателю
Alternative (альтернативный) Разные части являются альтернативными вариантами одной и той же информации. Они располагаются в порядке возрастания точности соответствия оригина- лу, и почтовая система получателя должна выбрать для отображения пользователю “лучший” вариант
Digest (реферативный) Подобен смешанному, но по умолчанию для поля тип/подтип каждой части выбирается message/rfc822
Message (сообщение) rfc822 Тело сообщения само является инкапсулированным сообщением в формате RFC 822
Partial (фрагментарный) Обеспечивает возможность фрагментации больших почтовых объектов по некоторым правилам, не тре- бующим вмешательства получателя
External-body (внешний) Содержит указатель на объект, существующий где-то в другом месте
176
Часть II. Приложения сетевой защиты
Окончание табл. 5.3
Тип Подтип Описание
Image jpeg Изображение в формате JPEG, кодировка JFIF
1 изображение) gif Изображение в формате GIF
Video mpeg Формат MPEG
видео) Audio Basic Одноканальная 8-битовая кодировка стандарта ISDN
звук) (основной) с частотой выборки 8 кГц, выполненная по закону
Application PostScript компандирования с ^-характеристикой Формат Adobe PostScript
। приложение) Octet-stream Двоичные данные общего вида, состоящие из 8-
(поток байтов) битовых байтов
Для типа text, чтобы увидеть текст такого сообщения, не требуется никакого
специального программного обеспечения, если только текст представлен в кодиров-
ке, с помощью которой он был создан. Главным подтипом данного типа является
plain text, что означает просто строку символов ASCII или символов ISO 8859.
Подтип enriched дает возможность использовать более гибкий формат.
Тип multipart указывает на то, что тело сообщения состоит из нескольких
независимых частей. Поле Content-Type заголовка сообщения включает пара-
метр boundary (граница), задающий разделитель, отделяющий части тела сооб-
щения одну от другой. Этот разделитель не должен присутствовать ни в одной из
частей сообщения. Каждый такой разделитель должен начинаться с новой стро-
ки, он формируется из двух дефисов, за которыми следует значение разделите-
ля. Завершающий разделитель, указывающий конец последней части сообще-
ния, имеет еще и суффикс, состоящий из двух дефисов. Внутри каждой части
может присутствовать необязательный обычный заголовок MIME.
Вот простой пример составного сообщения, включающего две части, каждая
их которых представляет собой простой текст (это пример из документа RFC
2046 с переводом пояснений).
From: Nathaniel Borenstein <nsb@bellcore.com>
To: Ned Freed <ned@innosoft.com>
Subject: Sample message
MIME-Version: 1.0
Fontent-type: multipart/mixed; boundary="simple boundary"
Это преамбула. Она игнорируется, но здесь создатель сообщения может
разместить пояснения для читателя, система которого не соответству-
ет стандарту MIME.
--simple boundary
Это неявно типизированный текст ASCII. Он НЕ заканчивается символом
обрыва строки.
--simple boundary
Глава 5. Защита электронной почты
177
Content-type: text/plain; charset=us-ascii
Это явно типизированный текст ASCII. Он ЗАКАНЧИВАЕТСЯ символом об-
рыва строки.
--simple boundary—
Это эпилог. Он тоже игнорируется.
Существует четыре подтипа для типа multipart сообщения, и все они име-
ют общий синтаксис. Подтип multipart/mixed используется при наличии не-
скольких независимых частей, которые должны быть связаны в определенном
порядке. Для подтипа multipart/parallel порядок частей не существен. Если
система получателя позволяет, все части сообщения могут быть представлены
параллельно. Например, изображение или текстовая часть могут сопровождаться
голосовым комментарием, который проигрывается, пока отображается изобра-
жение или текст.
Для подтипа multipart/alternative разные части являются различными
представлениями одной и той же информации. Рассмотрим следующий пример.
From: Nathaniel Borenstein <nsb@bellcore.com>
To: Ned Freed <ned@innosoft.com>
Subject: Formatted text mail
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary=boundary42
-~boundary42
Content-Type: text/plain; charset=us-ascii
... здесь размещается вариант сообщения в виде простого текста ...
—boundary42
Content-Type: text/enriched
... то же сообщение в виде текста в расширенном формате RFC 1896
--boundary42—
В этом подтипе части сообщения упорядочены по возрастанию их предпоч-
тения. Что касается данного примера, если принимающая система способна ото-
бражать сообщения в расширенном текстовом формате, то так он и будет ото-
бражен, в противном случае будет использован простой текстовый формат.
Подтип multipart/digest применяется тогда, когда каждая из частей
тела сообщения должна интерпретироваться как сообщение RFC 822 со сво-
им заголовком. Этот подтип позволяет создавать сообщения, части которого
являются отдельными сообщениями. Например, модератор группы может со-
бирать сообщения электронной почты участников группы, связывать их вме-
сте и пересылать инкапсулированными в одном сообщении MIME.
178
Часть II. Приложения сетевой защиты
Тип message обеспечивает ряд важных возможностей MIME. Подтип
ressage/rfс822 указывает на то, что тело представляет полное сообщение,
зключающее заголовок и тело сообщения. Несмотря на название этого подтипа,
инкапсулированное сообщение может быть не только простым сообщением
RFC 822, а любым сообщением MIME вообще.
Подтип message/partial позволяет разделить большое сообщение на не-
сколько частей, которые снова будут собраны в одно в системе получателя. Для
этого подтипа в поле Content-Type: Message/Partial указываются три пара-
с-сетра: идентификатор, общий для всех фрагментов этого сообщения, порядко-
вый номер, уникальный для каждого фрагмента, и общее число фрагментов.
Подтип message/external-body указывает на то, что фактических данных
з теле пересылаемого сообщения нет. Вместо этого тело сообщения содержит
информацию, необходимую для получения доступа к этим данным. Как и в слу-
чае с другими типами сообщения, подтип message/external-body имеет внеш-
ний заголовок и инкапсулированное сообщение с собственным заголовком. Един-
ственным необходимым полем во внешнем заголовке является поле Content-
Type, которое идентифицирует это сообщение как сообщение подтипа
message/external-body. Внутренний заголовок является заголовком сообще-
ния для инкапсулированного сообщения. Поле Content-Type во внешнем заго-
ловке должно включать параметр типа доступа, указывающий метод доступа,
например FTP (File Transfer Protocol — протокол передачи файлов).
Тип application ссылается на другие виды данных, обычно либо на неин-
терпретируемые данные в двоичном формате, либо на информацию, которая
должна обрабатываться почтовым приложением.
Кодировки MIME
Другим основным компонентом спецификаций MIME, наряду с типом со-
держимого, являются определения кодировок передаваемого тела сообщения.
Цель указания кодировки — исключить искажения при пересылке сообщения
через разнородную сетевую среду.
Стандарт MIME определяет два метода кодирования данных. Поле
Content-Transfer-Encoding может принимать шесть различных значений,
указанных в табл. 5.4. Однако три из этих значений (7bit, 8bit и binary)
указывают на то, что никакого кодирования выполнено не было, и поэтому
дают только некоторую информацию о природе пересылаемых данных. Для
передачи по протоколу SMTP безопаснее всего использовать кодировку, зада-
ваемую значением 7bit. В других почтовых транспортных контекстах могут
быть также приемлемыми данные в 8-битовой и двоичной форме (значения
zbit и binary). Еще одним значением поля Content-Transfer-Enccding
является x-token, которое говорит о том, что действует некоторая другая
схема кодирования, для которой должно быть указано имя. Это может быть
специальная схема кодирования поставщика или конкретного приложения.
Двумя определяемыми значениями для схемы кодирования являются
guoted-printable и base64. Эти две схемы предлагаются для того, чтобы
обеспечить возможность выбора между вариантом, когда сохраняется воз-
можность чтения обычного текста человеком, и вариантом, который доста-
точно компактен и безопасен для пересылки всех типов данных.
Глава 5. Защита электронной почты
179
Таблица 5.4. Кодировки MIME
7bit Все данные представляются короткими строками символов ASCII
8bit Все строки являются короткими, но могут содержать символы, не яв- ляющиеся символами ASCII (байты с ненулевыми старшими битами)
binary Могут присутствовать не только символы, не являющиеся символами ASCII, но и строки не обязательно должны быть достаточно короткими для транспорта SMTP
quoted-printable Данные кодируются таким образом, что если исходные данные явля- ются в основном текстом ASCII, то в кодированной форме они остают- ся в значительной степени распознаваемыми человеком
base64 Данные кодируются отображением 6-битовых блоков входных данных в 8-битовые блоки, являющиеся печатаемыми символами ASCII
x-token Нестандартное кодирование с указанным именем
Кодировку quoted-printable целесообразно использовать тогда, когда боль-
шинство байтов данных соответствует печатаемым символам ASCII. По сущест-
ву, она переводит непечатаемые символы в шестнадцатеричные представления
их кодов и вставляет обратимые (мягкие) переходы на новую строку, чтобы ог-
раничить длину строк до 76 символов.
Кодировка base64, известная также под названием radix-64, является
общепринятым преобразованием произвольных данных из двоичного формата
в такой, который не искажается при обработке данных программами пере-
сылки почты. Именно эта кодировка используется в PGP и описывается в
дополнении 5.2.
Пример многокомпонентного сообщения
На рис. 5.8, созданном на основе соответствующего примера из RFC
1521, схематически представлено сложное многокомпонентное сообщение.
Это сообщение состоит из пяти частей, которые должны отображаться после-
довательно: две вводные части в виде простого текста, вложенное многоком-
понентное сообщение, часть в виде текста расширенного формата и заключи-
тельное инкапсулированное текстовое сообщение, в котором используются
символы, не являющиеся символами ASCII. Вложенное многокомпонентное
сообщение состоит из двух частей, которые должны отображаться парал-
лельно, — изображения и звукового фрагмента.
180
Часть II. Приложения сетевой защиты
MIME-Version: 1.0
From: Nathaniel Borenstein <nsb@bellcore.com>
To: Ned Freed <ned@innosoft.com>
Subject: A multipart example
Content-Type: multipart/mixed;
boundary=unique-boundary-1
Это раздел преамбулы многокомпонентного сообщения. Получатель, распознающий данный формат,
должен игнорировать эту' преамбулу. Прочитав этот текст, вы, возможно, захотите использовать
почтовую программу, способную правильно отображать многокомпонентные сообщения.
-unique-boundary-1
... Здесь размещается некоторый текст ...
[Заметим, что предыдущая пустая строка означает отсутствие полей заголовка для этого текста, и что
это текст из символов US-ASCII. Последнее можно было бы указать явно, как это сделано
в следующей части сообщения.]
-unique-boundary-1
Content-type: text/plain; charset=US-ASCII
Этот текст мог быть включен в предыдущую часть сообщения, но он иллюстрирует возможность
явного указания типа содержимого в сравнении с неявным.
-unique-boundary-1
Content-Type: multipart/parallel; boundary=unique-boundary-2
- uniq ue-boundary-2
Content-Type: audio/basic
Content-Transfer-Encoding: base64
... здесь размещаются кодированные в формате base64 данные, представляющие собой
одноканальную 8-битовую цифровую запись звука с частотой выборки 8000 Гц. выполненную
по закону компандирования с ^-характеристикой ...
-unique-boundary-2
Content-Type: image/jpeg
Content-Transfer-Encoding: base64
... здесь размещается кодированное в формате base64 изображение ...
-unique-boundary-2—
-unique-boundary-1
Content-type: text/enriched
Это текст в <boldxitalic>paciHHpeHHOM формате,</italicx/bold> <5та11ег>определенном
в RFC 1896</smaller>
Разве это не <biggei><bigger>3,’;opoBO?</bigger></bigger>
-unique-boundary-1
Content-Tуре: message/rfc822
From: (почтовый ящик в кодах US-ASCII)
То: (адрес в кодах US-ASCII)
Subject: (тема сообщения в кодах US-ASCII)
Content-Type: Text/plain; charset=ISO-8859-l
Content-Transfer-Encoding: Quoted-printable
... Здесь размещается дополнительный текст в кодах ISO-8859-1 ...
-unique-boundary-1-
Рис. 5.8. Пример структуры сообщения MIME
Глава 5. Защита электронной почты
181
Каноническая форма
Важным понятием в MIME и S/MIME является понятие канонической фор-
мы. Каноническая форма представляет собой формат, подходящий данному типу
содержимого и стандартизованный для использования при обмене между систе-
мами. В этом отношении каноническая форма отличается от собственной формы
содержимого, которая может зависеть от конкретной системы. Табл. 5.5, взятая
из документа RFC 2049, должна помочь разобраться в сути этого понятия.
Таблица 5.5. Собственная и каноническая формы
Собственная Тело сообщения создается в собственном формате соответствующей сис-
форма темы. Используются собственные наборы символов и, возможно, ло-
кальные соглашения о символах окончания строк. Тело сообщения мо-
жет представлять собой или текстовый файл UNIX, или растровое изо-
бражение Sun, или индексированный файл VMS, или звуковые данные в
зависящем от системы формате, сохраняемым только в памяти, или ка-
кой-то иной объект, соответствующий локальной модели представления
некоторой информации. Главное, что данные создаются в некоторой
“родной” форме, задаваемой типом носителя
Каноническая Все тело сообщения, включая дополнительную информацию (например, о
форма длине записей или атрибутах файла), переводится в универсальную канони-
ческую форму. При этом каноническая форма тела сообщения определяется
типом тела сообщения, а также связанными с этим типом атрибутами. Пре-
образование в правильную каноническую форму может означать преобразо-
вание набора символов, трансформацию звуковых данных, сжатие или ка-
кие-то другие действия, допустимые в отношении содержимого данного кон-
кретного типа. Однако преобразование набора символов требует четкого
понимания семантики представления содержимого, от которой такое преоб-
разование может существенно зависеть (например, при наличии синтаксиче-
ски важных символов в тексте, подтип которого отличен от простого)
Функциональные возможности S/MIME
С точки зрения общих функциональных возможностей защиты S/MIME и
PGP очень схожи. Обе системы предлагают возможность подписывать и/или
шифровать сообщения. В этом разделе мы кратко опишем функции S/MIME. За-
тем рассмотрим их более детально, изучив форматы сообщения и процесс подго-
товки сообщения.
Функции
S/MIME обеспечивает возможность использования следующих функций.
• Упакованные данные. Состоят из шифрованного содержимого любого типа и
ключей шифрования содержимого для одного или нескольких получателей.
• Подписанные данные. Цифровая подпись формируется путем вычисления
профиля для требующего подписи содержимого сообщения с последующим
его шифрованием личным ключом стороны, подписывающей содержимое.
После этого содержимое вместе с подписью переводятся в формат base64.
Сообщение с подписанными данными может быть просмотрено только по-
лучателем, располагающим возможностями S/MIME.
182
Часть II. Приложения сетевой защити
• Открытые подписанные данные. Как и в подписанных данных, формирует-
ся цифровая подпись содержимого. Однако в данном случае с использовани-
ем base64 кодируется только цифровая подпись. В результате получатели
без возможностей S/MIME смогут просмотреть содержимое сообщения, но
не смогут проверить подпись.
• Подписанные и упакованные данные. Возможности подписи и упаковки
могут быть вложены одна в другую, так что шифрованные данные могут
быть подписаны, а подписанные или открытые подписанные данные за-
шифрованы.
Криптографические алгоритмы
В табл. 5.6 представлены криптографические алгоритмы, используемые в
системе S/MIME. В S/MIME принята следующая терминология, предложенная в
документе RFC 2119 и позволяющая указать уровень требований.
• ОБЯЗАТЕЛЬНО (MUST). Определение является абсолютным требованием
спецификации. Любая реализация должна включать это свойство или
функцию, чтобы соответствовать данной спецификации.
• РЕКОМЕНДУЕТСЯ (SHOULD). В конкретном окружении могут существо-
вать причины игнорировать это свойство или функцию, но рекомендуется,
чтобы реализация все же их имела.
Таблица 5.6. Криптографические алгоритмы, используемые в S/MIME
Функция Требование
Вычисление профиля сообщения при созда- нии цифровой подписи ОБЯЗАТЕЛЬНА поддержка SHA-1 и MD5. РЕКОМЕНДУЕТСЯ использование SHA-1
Шифрование профиля сообщения для созда- ния цифровой подписи Для агентов отсылки и приема сообщений ОБЯЗАТЕЛЬНА под- держка DSS. Для агента отсылки сообщений РЕКОМЕНДУЕТСЯ поддержка шифрования RSA. Для агента приема сообщений РЕКОМЕНДУЕТСЯ поддержка верификации подписей RSA с длиной ключа от 512 до 1024 бит
Шифрование сеансо- вого ключа для пере- паяй с сообщением Для агентов отсылки и приема сообщений ОБЯЗАТЕЛЬНА под- держка алгоритма Диффи-Хеллмана. Для агента отсылки сообщений РЕКОМЕНДУЕТСЯ поддержка шифрования RSA с длиной ключа от 512 до 1024 бит. Для агента приема сообщений РЕКОМЕНДУЕТСЯ поддержка дешифрования RSA
Шифрование сообще- ния для передачи с одноразовым сеансо- вым ключом Для агента отсылки сообщений РЕКОМЕНДУЕТСЯ поддержка шифрования tripleDES и RC2/40. Для агента приема сообщений РЕКОМЕНДУЕТСЯ поддержка дешифрования tripleDES и ОБЯЗАТЕЛЬНА поддержка дешиф- рования RC2/40
S/MIME включает три алгоритма, использующие открытые ключи. Стандарт цифровой подписи (алгоритм DSS), упоминавшийся в главе 3, является предпочти- тельным алгоритмом создания цифровой подписи. Предпочтительным алгоритмом
Глава 5. Защита электронной почты
183
шифрования сеансовых ключей в S/MIME называется алгоритм Диффи-Хеллмана,
но фактически в S/MIME используется вариант алгоритма Диффи-Хеллмана, обеспе-
чивающий шифрование/дешифрование и обычно называемый алгоритмом Эль-
Гамаля. В качестве альтернативы как для подписей, так и для шифрования сеансо-
вых ключей может использоваться алгоритм RSA, описанный в главе 3. Те же алго-
ритмы применяются в PGP, поскольку они обеспечивают достаточно высокий уро-
вень защиты. Для функции хэширования, используемой при создании цифровых
подписей, спецификации рекомендуют 160-битовый алгоритм SHA-1, но требуют
поддержку 128-битового алгоритма MD5. Как уже говорилось в главе 3, имеются
обоснованные сомнения в достаточной защищенности MD5, так что SHA-1 является,
очевидно, более предпочтительной альтернативой. Однако MD5 применяется очень
широко, чем и объясняется его поддержка.
Для шифрования сообщений рекомендуется “тройной” DES с тремя ключа-
ми (tripleDES), но любая гибкая реализация должна поддерживать 40-битовую
версию алгоритма RC2. Последний является весьма слабым алгоритмом шифро-
вания, но зато соответствует экспортным ограничениям США.
Спецификации S/MIME включают описание процедуры выбора алгоритма
шифрования содержимого. По существу, агент отправки сообщений должен при-
нять следующие решения. Во-первых, он должен определить, способен ли агент
приема сообщений дешифровать данный алгоритм шифрования. Во-вторых, если
агент приема способен принимать только слабо шифрованное содержимое, агент
отправки должен решить, можно ли использовать слабое шифрование. Для под-
держки этого процесса выбора в отсылаемом сообщении агент отправки может
объявлять возможности дешифрования в порядке возрастания предпочтения.
Агент приема может сохранить эту информацию для дальнейшего применения.
Агент отправки при принятии решения должен использовать представлен-
ные ниже правила в следующем порядке.
1. Если агент отправки имеет список предпочтения возможностей дешифрова-
ния предполагаемого получателя, РЕКОМЕНДУЕТСЯ выбрать из этого спи-
ска первую возможность (возможность с наивысшим предпочтением) из тех,
которые получатель может использовать.
2. Если агент отправки не имеет такого списка возможностей предполагаемого
получателя, но имеет одно или несколько сообщений, пришедших от полу-
чателя, то для отправляемого сообщения РЕКОМЕНДУЕТСЯ использовать
алгоритм шифрования, применявшийся в последнем из подписанных и
шифрованных сообщений, прибывших от предполагаемого адресата.
3. Если агент отправки ничего не знает о возможностях дешифрования пред-
полагаемого получателя и может допустить риск того, что получатель не
сможет дешифровать сообщение, то агенту отправки РЕКОМЕНДУЕТСЯ ис-
пользовать tripleDES.
4. Если агент отправки ничего не знает о возможностях дешифрования пред-
полагаемого получателя и не желает рисковать тем, что получатель не смо-
жет дешифровать сообщение, то агенту отправки ОБЯЗАТЕЛЬНО использо-
вать RC2/40.
Если сообщение должно быть послано нескольким получателям и нельзя
выбрать алгоритм шифрования, общий для всех, то агенту отправки следует ото-
184
Часть II. Приложения сетевой защиты
слать два сообщения. Однако важно заметить, что сообщение становится более
уязвимым при передаче копии сообщения с более слабой защитой.
Сообщения S/MIME
В S/MIME определен ряд новых типов содержимого MIME, перечисленных
в табл. 5.7. Все эти новые подтипы приложений помечаются сигнатурой PKCS
(Public-Key Cryptography Specifications — спецификации криптографии с откры-
тым ключом). Соответствующие спецификации опубликованы RSA Laboratories
и открыты для использования в S/MIME.
Таблица 5.7. Типы содержимого S/MIME
Тип Подтип Параметр smime Описание
Multipart (многокомпонентный) Signed (подписанны й) Открытое подписанное сообщение из двух частей —сообщения и его подписи
Application (приложение) pkcs7-mime signedData Подписанный объект S/MIME
pkcs7-mime envelopedData Шифрованный объект S/MIME
pkcs7-mime degenerate signedData Объект, содержащий только сер- тификаты открытых ключей
pkcs7- signature — Тип подписи, являющейся частью сообщения типа multipart/signed
pkcslO-mime — Сообщение запроса регистрации сертификата
Мы рассмотрим все этих типы по очереди после того, как уделим внимание
общим процедурам подготовки сообщений S/MIME.
Защита объекта MIME
В S/MIME защита объекта MIME обеспечивается подписью, шифрованием
или и тем и другим одновременно. Объектом MIME может быть как все сообще-
ние (за исключением его заголовков RFC 822), так и одна или несколько частей
сообщения (в многокомпонентном сообщении MIME). Объект MIME готовится в
соответствии с обычными правилами подготовки сообщений MIME. Затем объект
MIME вместе с некоторыми связанными с ним данными защиты (например,
идентификаторами алгоритма и сертификатов) обрабатываются средствами
S/MIME, чтобы в результате получить то, что обычно называют объектом PKCS.
С объектом PKCS затем обращаются как с содержимым сообщения, которое упа-
ковывают по правилам MIME (добавляя соответствующие заголовки). Этот про-
цесс должен стать понятным после того, как мы рассмотрим конкретные объек-
ты и соответствующие примеры.
В любом случае отсылаемое сообщение переводится в каноническую форму.
При этом каноническая форма зависит от типа и подтипа содержимого сообще-
ния. Для многокомпонентных сообщений подходящая каноническая форма вы-
бирается для каждой части в отдельности.
Глава 5. Защита электронной почты
185
Использование кодировок требует особого внимания, В большинстве случаев
в результате применения алгоритма защиты получается объект, который час-
тично или полностью представляется произвольными двоичными данными. Этот
объект затем упаковывается во внешнее сообщение MIME и при этом может ис-
пользоваться соответствующая кодировка, обычно base64. Но в случае подписан-
ного многокомпонентного сообщения, который будет подробно обсуждаться ни-
же, часть содержимого сообщения после применения средств защиты остается
без изменения. Если это содержимое не является набором 7-битовых символов,
то оно должно передаваться в кодировке base64 или quoted-printable во избежа-
ние изменения содержимого, к которому относится подпись.
Давайте рассмотрим каждый из типов содержимого S/MIME.
Упакованные данные
Подтип application/pkcs7-mime используется для четырех категорий об-
работки содержимого S/MIME, каждой из которых соответствует свой уникаль-
ный параметр smime-типа. Результат такой обработки, называемый объектом,
представляется в так называемом формате BER (Basic Encoding Rules — базовые
правила кодирования), определяемом рекомендациями Х.209 группы ITU-T.
Формат BER задает строки произвольных байтов, определяя, таким образом,
данные в двоичном формате. Такой объект во внешнем сообщении MIME должен
передаваться кодированным в формате base64. Сначала мы рассмотрим объект
envelopedData (упакованные данные).
При подготовке объекта envelopedData должны быть выполнены следую-
щие действия.
1. Генерируется псевдослучайный сеансовый ключ для конкретного алгоритма
симметричной схемы шифрования (RC2/40 или tripleDES).
2. Для каждого получателя сеансовый ключ шифруется с помощью открытого
ключа получателя и RSA.
3. Для каждого получателя готовится блок данных, называемый
Recipientinfo (информация для получателя), содержащий сертификат от-
крытого ключа2 отправителя, идентификатор алгоритма, сеансовый ключ
шифрования и шифрованный сеансовый ключ.
4. Содержимое сообщения шифруется с помощью сеансового ключа.
Блоки Recipientinfo, за которыми следует шифрованное содержимое со-
общения, вместе составляют блок envelopedData. Эта информация затем коди-
руется в формате base64. Вот пример такого сообщения (с исключенными заго-
ловками RFC 822).
2 Это сертификат стандарта Х.509, использование которого будет обсуждаться ниже.
186 Часть IL Приложения сетевой защиты
Zontent-Type: application/pkcs7-mime; smime-type=enveloped~data;
r.ame=smime. p7m
Zontent-Transfer-Encoding: base64
Zontent-Disposition: attachment; filename=smime.p7m
rfvbnj756tbBghyHhHUujhJhjH77n8HHGT9HG4VQpfyF467GhIGfHfYT6
“n8HHGghyHhHUujhJh4VQpfyF467GhIGfHfYGTrfvbnjT6jH7756tbB9H
58HHGTrfvhJhjH776tbB9HG4VQbnj7567GhIGfHfYT6ghyHhHUujpfyF4
ZGhlGfHfQbnj756YT64V
Чтобы восстановить шифрованное сообщение, в системе получателя сначала
снимается кодировка base64, затем с помощью личного ключа получателя от-
крывается сеансовый ключ, и наконец, содержимое сообщения дешифруется с
помощью этого сеансового ключа.
Подписанные данные
Тип signedData (подписанные данные) предназначен для документов, под-
писанных одной или несколькими сторонами. Для определенности мы ограни-
чимся исследованием одной цифровой подписи. При подготовке объекта
signedData выполняются следующие действия.
1. Выбирается алгоритм создания профиля сообщения (SHA или MD5).
2. Вычисляется профиль сообщения (значение хэш-функции) для содержимо-
го, которое должно быть подписано.
3. Профиль сообщения шифруется с помощью личного ключа стороны, подпи-
сывающей документ.
4. Подготавливается блок, называемый Signer Info (информация подписав-
шей стороны), содержащий сертификат открытого ключа подписавшей до-
кумент стороны, идентификатор алгоритма, использовавшегося для шифро-
вания профиля сообщения, и шифрованный профиль сообщения.
Объект signedData формируется из ряда блоков, включающих идентификатор
алгоритма создания профиля сообщения, само подписываемое сообщение и блок
Signerinfo. Объект signedData может также включать набор сертификатов откры-
тых ключей, достаточный для того, чтобы составить цепочку от признанного центра
сертификации или центра сертификации высшего уровня доверия к объекту, подпи-
савшему документ. Эта информация затем кодируется в формате base64. Вот пример
такого сообщения (с исключенными заголовками RFC 822).
Zontent-Type: application/pkcs7-mime; smime-type=signed-data;
name=smime.p7m
Zontent-Transfer-Encoding: base64
Zontent-Disposition: attachment; filename=smime.p7m
:57GhIGfHfYT6ghyHhHUujpfyF4f8HHGTrfvhJhjH776tbB9HG4VQbnj7
“7n8HHGT9HG4VQpfyF467GhIGfHfYT6rfvbnj756tbBghyHhHUujhJhjH
SoujhJh4VQpfyF467GhIGfHfYGTrfvbnjT6jH7756tbB9H7n8HHGghyHh
:YT64VOGhIGfHfQbnj 75
Глава 5. Защита электронной почты
187
Чтобы восстановить подписанное сообщение и проверить подпись, получа-
тель сначала снимает кодировку base64. Затем используется открытый ключ
стороны, подписавшей документ, чтобы открыть профиль сообщения. Наконец,
получатель самостоятельно вычисляет профиль сообщения и сравнивает его с
дешифрованным профилем сообщения, чтобы проверить подпись.
Открытое подписанное сообщение
Открытое подписанное сообщение получается тогда, когда для содержимого
используется тип multipart и подтип signed. Как уже упоминалось, такой
процесс подписи не трансформирует само подписываемое сообщение, так что оно
пересылается в “открытом” виде. Таким образом, получатели с возможностями
MIME, но не S/MIME, все равно смогут прочитать поступившее сообщение.
Сообщение типа multipart/signed состоит из двух частей. Первая часть
может быть любого типа MIME, но должна быть подготовлена так, чтобы она не
была изменена в пути следования от источника к адресату. Это значит, что если
первая часть не представлена в 7-битовой кодировке (тип 7bit), то данные необ-
ходимо кодировать, используя формат base64 или quoted-printable. Затем эта
часть сообщения обрабатывается точно так же, как обычный объект
signedData, но в данном случае у создаваемого в формате signedData объекта
поле содержимого оказывается пустым. Этот объект представляет собой отделен-
ную подпись. Затем объект кодируется в формат base64, чтобы стать второй ча-
стью многокомпонентного сообщения. Для типа MIME этой второй части выби-
рается значение application, а для подтипа — pkcs7-signature. Вот пример
такого сообщения.
Content-Type: multipart/signed;
protocol="application/pkcs7-signature";
micalg=shal; boundary=boundary42
--boundary42
Content-Type: text/plain
Это открытый текст подписанного сообщения.
--boundary42 t
Content-Type: application/pkcs7-signature; name=smime,p7s
Content-Transfer-Encoding: base 64
Content-Disposition: attachment; filename=smime.p7s
ghyHhHUujhJhjH77n8HHGTrfvbnj756tbB9HG4VQpfyF467GhIGfHfYT6
4VQpfyF467GhIGfHfYT6jH77n8HHGghyHhHUujhJh756tbB9HGTrfvbnj
n8HHGTrfvhJhjH776tbB9HG4VQbnj7567GhIGfHfYT6ghyHhHUujpfyF4
7GhIGfHfYT64VQbnj 756
--boundary42--
Значение параметра protocol указывает на то, что этот объект является
двухкомпонентным открытым подписанным сообщением. Значение параметра
mi cal g указывает тип используемого профиля сообщения. Получатель может
188
Часть II. Приложения сетевой защиты
—сверить подпись, вычислив профиль сообщения из первой части и сравнив его
: профилем сообщения, который восстанавливается из подписи во второй части.
Запрос регистрации
Обычно приложение или пользователь обращается к центру сертификации
~z поводу получения сертификатов открытых ключей. Объект S/MIME типа
= ;plication/pkcslO служит для идентификации запроса такого сертификата,
rinpoc сертификата включает блок certificationRequestlnfo (информация о
поросе сертификата), идентификатор алгоритма шифрования с открытым клю-
чом и подпись блока certificationRequestlnfo, созданную с помощью лично-
?: ключа отправителя. Блок certificationRequestlnfo содержит имя объекта
:^ртификации (объект, открытый ключ которого должен быть сертифицирован)
2 представление открытого ключа пользователя в виде строки битов.
Сообщение, содержащее только сертификаты
Сообщения, содержащие только сертификаты или список отозванных сертифи-
катов (CRL), могут посылаться в ответ на запрос регистрации. Типом/подтипом та-
кого сообщения будет application/pkcs7-mime с параметром degenerate
вырожденный) для smime-типа. Выполняемые при этом действия аналогичны тем,
что и при создании сообщения signedData, за исключением того, что в данном слу-
чае нет содержимого сообщения, и поле signerinfo оказывается пустым.
Обработка сертификатов в S/MIME
S/MIME использует сертификаты открытых ключей, соответствующие стандар-
ту Х.509 версии 3 (см. главу 4). Схема управления ключами в S/MIME является в
некотором смысле гибридом строгой иерархии сертификатов Х.509 и сети доверия
PGP. Как и в модели PGP, администраторы и/или пользователи S/MIME должны
предоставить каждому клиенту список надежных ключей и список отозванных сер-
тификатов. Это значит, что ответственность за поддержку множества сертификатов,
необходимых для проверки поступающих подписей и шифрования отправляемых со-
общений, ложится на локальную систему. В то же время сами сертификаты подпи-
:ываются уполномоченными центрами сертификации.
Роль агента пользователя
Пользователю S/MIME приходится выполнять следующие функции управ-
ления ключами.
• Генерирование ключей. Для пользователя соответствующей утилиты адми-
нистрирования (например, осуществляющей управление локальной сетью)
ОБЯЗАТЕЛЬНО должна быть предусмотрена возможность генерирования
отдельных пар ключей Диффи-Хеллмана и DSS и РЕКОМЕНДУЕТСЯ иметь
возможность генерировать пары ключей RSA. Каждая пара ключей
ОБЯЗАТЕЛЬНО должна генерироваться с использованием случайных зна-
чений, полученных от хорошего недетерминированного источника, и долж-
на быть надежно защищена. Для агента пользователя РЕКОМЕНДУЕТСЯ
генерировать пары ключей RSA с длиной ключа от 768 до 1024 бит и
ОБЯЗАТЕЛЬНО отказаться от генерирования ключей длиной менее 512 бит.
Глава 5. Защита электронной почты
189
• Регистрация. Открытый ключ пользователя должен быть зарегистрирован
уполномоченным центром сертификации с целью получения сертификата
Х.509 этого ключа.
• Хранение и поиск сертификатов. Пользователю требуется доступ к локаль-
ному списку сертификатов, чтобы обеспечивалась возможность проверки
поступающих подписей и шифрования отправляемых сообщений. Такой
список может поддерживаться самим пользователем или некоторым ло-
кальным административным объектом от имени группы пользователей.
Сертификаты VeriSign
Существует несколько компаний, предлагающих сервис сертификации. Так,
фирма Nortel предлагает комплексное решение проблемы сертификации для
предприятий и может обеспечить поддержку S/MIME в рамках отдельной орга-
низации. Существуют центры сертификации, использующие Internet, и среди
них VeriSign, GTE и U.S. Postal Service. Наиболее популярной является служба
сертификации VeriSign, краткое описание которой предлагается ниже.
VeriSign обеспечивает сервис сертификации, совместимый с S/MIME и це-
лым рядом других приложений. VeriSign выдает сертификаты стандарта Х.509,
называемые цифровыми удостоверениями VeriSign (VeriSign Digital ID). На на-
чало 1998 года цифровые удостоверения сервера VeriSign использовали свыше
35000 коммерческих Web-узлов, и более миллиона цифровых удостоверений бы-
ло выдано пользователям броузеров Netscape и Microsoft.
Информация, содержащаяся в цифровом удостоверении, зависит от его типа
и области применения. Как минимум, каждое цифровое удостоверение содержит
следующие элементы:
• открытый ключ владельца,
• имя владельца или его псевдоним,
• дата истечения срока действия цифрового удостоверения,
• номер цифрового удостоверения,
• имя центра сертификации, выдавшего цифровое удостоверение,
• подпись центра сертификации, выдавшего данное цифровое удостоверение.
Цифровые удостоверения могут содержать и другую предоставленную поль-
зователем информацию, включая
• почтовый адрес,
• адрес электронной почты,
• регистрационную информацию (название страны, почтовый индекс, возраст
и пол).
VeriSign обеспечивает три уровня или класса защиты сертификатов от-
крытых ключей, как это показано в табл. 5.8. Пользователь запрашивает
сертификат в интерактивном режиме, обращаясь к Web-узлу VeriSign или
другому уполномоченному узлу. Запросы класса 1 и класса 2 выполняются в
интерактивном режиме, и в большинстве случаев их выполнение занимает
всего несколько секунд. Кратко соответствующую процедуру можно описать
следующим образом.
190
Часть II. Приложения сетевой защиты
• Для цифрового удостоверения класса 1 VeriSign подтверждает адрес элек-
тронной почты пользователя с помощью отправки PIN-кода и информации
о получении цифрового удостоверения по адресу электронной почты, ука-
занному в запросе.
• Для цифрового удостоверения класса 2 VeriSign в дополнение ко всем про-
веркам, выполняемым для удостоверений класса 1, проверяет информацию
в запросе с помощью ее автоматизированного сравнения с базой данных по-
требителей. В конце концов посылается подтверждение по указанному поч-
товому адресу, предупреждающее пользователя о том, что на имя этого
пользователя было выдано цифровое удостоверение.
• Для цифрового удостоверения класса 3 VeriSign требует высшего уровня на-
дежности идентификации пользователя. Субъект должен идентифицировать се-
бя, или предъявив нотариально заверенный документ, или явившись лично.
Глава 5. Защита электронной почты
191
Таблица 5.8. Классы сертификатов VeriSign открытых ключей
Процедура подтверждения личности Защита личного ключа центра сертификации Защита личного ключа заказчика сертификата и подписчика Задачи запрашивающих сертификаты пользователей
Класс 1 Автоматизированный поиск имени и адреса электронной почты РСА: надежное оборудо- вание; СА: надежное программ- ное обеспечение или на- дежное оборудование Программное шифрование (защищенное PIN-кодами) — рекомендуется, но необяза- тельно Просмотр Web-страниц и исполь- зование некоторых функций об- мена электронной почтой
Класс 2 То же, что и для класса 1, плюс автоматизированная проверка регистрационной информации и адреса РСА и СА: рудование надежное обо- Программное шифрование (защищенное PIN-кодами) — обязательно Индивидуальная, внутри- и межкорпоративная электронная почта, подписка в интерактив- ном режиме, замена паролей и проверка аутентичности про- граммного обеспечения
Класс 3 То же, что и для класса 1, плюс персональное присутст- вие и предъявление удостове- ряющего личность докумен- та, а также автоматизиро- ванная проверка удостовере- ния для индивидуальных пользователей или регистра- ционных документов (фай- лов) для организаций, как для класса 2 РСА и СА: рудование надежное обо- Программное шифрование (защищенное PIN-кодами) — обязательно; аппаратная идентификация — рекомен- дуется, но необязательна Электронные банковские опера- ции, доступ к корпоративным ба- зам данных, интерактивные службы для зарегистрированных членов, серверы электронной коммерции, проверка аутентично- сти программного обеспечения; аутентификация LRAA и особо защищаемых серверов
СА — Certification Authority (центр сертификации)
РСА — VeriSign Public Primary Certification Authority (первичный центр сертификации VeriSign)
PIN — Personal Identification Number (личный идентификационный номер)
LRAA — Local Registration Authority Administrator (администратор локального отделения регистрации)
Сервис усовершенствованной защиты
На момент создания этой книги уже было предложено три проекта сервисов
усовершенствованной защиты для Internet. Возможно, что-то в них изменится,
могут также появиться дополнительные службы. Ниже дано описание трех сер-
висов, о которых идет речь.
• Подписанные подтверждения получения. Подписанное подтверждение по-
лучения может быть запрошено в объекте SignedData. Возврат подписан-
ного подтверждения получения обеспечивает отправителю сообщения дока-
зательство доставки этого сообщения и позволяет продемонстрировать
третьей стороне, что адресат сообщение получил. По существу, получатель
подписывает все оригинальное сообщение вместе с подписью отправителя и
присоединяет новую подпись, формируя новое сообщение S/MIME.
• Ярлыки защиты. Ярлык защиты может включаться в атрибуты аутентифика-
ции объекта SignedData. Ярлык защиты представляет информацию о степени
секретности содержимого, защищаемого средствами инкапсуляции S/MIME.
Такие ярлыки могут применяться для управления доступом, указывая, каким
пользователям разрешен доступ к данному объекту. Можно также указать при-
оритет (секретный, конфиденциальный, ограниченный доступ и т.д.) или роле-
вое назначение, указывающее на то, кто может увидеть данную информацию
(например, врачи, агенты страховых компаний и т.д.).
• Защищенные списки рассылки. Когда пользователь посылает сообщение не-
скольким адресатам, требуется выполнить определенный объем работы для
каждого из них, в частности использовать открытый ключ каждого получа-
теля. Пользователь может быть избавлен от этой работы, поручив ее агенту
списков рассылки S/MIME. Агент списков рассылки может взять сообщение
и выполнить соответствующие операции шифрования для каждого из адре-
сатов, а затем передать сообщение дальше. В этом случае автор сообщения
должен отослать агенту списков рассылки только сообщение, зашифрован-
ное с использованием открытого ключа агента списков рассылки.
5.3. РЕКОМЕНДУЕМЫЕ ИСТОЧНИКИ
ДОПОЛНИТЕЛЬНОЙ ИНФОРМАЦИИ
. .Jk Вниманию читателей предлагаются следующие Web-узлы.
• Информационная страница PGP. Посвященная PGP страница
к/ Web-узла фирмы Network Associates, ведущего коммерческого
I поставщика PGP.
• Посвященная распространению PGP страница МГГ (Массачусетс-
ского технологического института). Ведущий распространитель
свободно доступных версий PGP. Его страница содержит полезную
информацию, список часто задаваемых вопросов с ответами и
ссылки на другие посвященные PGP узлы.
Глава 5. Защита электронной почты
193
• S/MIME Charter (Хартия S/MIME). Самые последние документы RFC и
проекты стандартов S/MIME для Internet.
• S/MIME Central (Централ S/MIME). Посвященный S/MIME узел RSA, Inc.
Содержит список часто задаваемых вопросов с ответами и другую полезную
информацию.
5.4. ЗАДАЧИ
5.1. В PGP используется режим шифрованной обратной связи (режим CFB) алгорит-
ма CAST-128, тогда как большинство других приложений шифрования
(отличных от приложений шифрования ключей) использует режим сцепления
шифрованных блоков (режим СВС). Для этих режимов имеем:
СВС: С,.=ЕК[С,_1®Р(]; Р,-=CM®DK[C,.];
CFB: C(=P,.®EK[C,._i]; Р,- = С; ©ЕкЕС^].
Оба варианта, кажется, обеспечивают одинаковую защиту. Предложите объяс-
нение причин, по которым в PGP используется режим CFB.
5.2. Первые 16 бит 128-битового профиля сообщения в подписи PGP пересылаются в
открытом виде.
а. В какой мере это компрометирует защиту алгоритма хэширования?
б. В какой мере это в действительности выполняет свою функцию — помогает
определить, соответствующий ли ключ RSA использовался для того, чтобы
дешифровать профиль сообщения?
5.3. На рис. 5.4 каждая запись в связке открытых ключей содержит поле доверия
владельцу, значение которого указывает степень данного открытого ключа. По-
чему этого недостаточно? (Иными словами, если этот владелец надежен и пред-
полагается, что данный открытый ключ принадлежит ему, то почему этого не
достаточно для того, чтобы сразу разрешить PGP использовать соответствующий
открытый ключ?)
5.4. Рассмотрим преобразование в 64-символьный формат (radix-64) как форму
шифрования. В этом случае нет никаких ключей. Но предположим, что против-
ник знает только о том, что для шифрования английского текста применен не-
который алгоритм замены. Насколько эффективным является этот алгоритм с
точки зрения криптоанализа?
5.5. Фил Зиммерман выбрал для традиционного шифрования PGP алгоритмы IDEA,
“тройной” DES с тремя ключами и CAST-128. Укажите причины, по которым
другие рассмотренные в данной книге алгоритмы традиционной схемы шифро-
вания могут подходить или не подходить для PGP (это DES, “тройной” DES с
двумя ключами, Blowfish, RC2 и RC5).
ДОПОЛНЕНИЕ 5.1. СЖАТИЕ ДАННЫХ
С ПОМОЩЬЮ ZIP
В PGP используется пакет сжатия данных, называемый ZIP, авторами кото-
рого являются Жан-Луп Галли (Jean-loup Gailly), Марк Адлер (Mark Adler) и Ри-
чард Уэйлз (Richard Wales). ZIP является свободно распространяемым пакетом,
194
Часть II. Приложения сетевой защиты
написанным на языке С, выполняемым как утилита в системе UNIX и ряде других
систем. ZIP функционально равноценен пакету PKZIP, являющемуся широко дос-
тупным и условно бесплатным пакетом для систем под управлением Windows,
разработанным PKWARE, Inc. Алгоритм ZIP реализует, по-видимому, наиболее
часто используемую технику сжатия данных, обеспечивая возможность межплат-
форменного обмена данными: бесплатные и условно бесплатные версии ZIP дос-
тупны для Macintosh и многих других систем, а не только для Windows и UNIX.
Алгоритм ZIP и ему подобные появились в результате исследований Джей-
коба Зива (Jacob Ziv) и Абрахама Лемпела (Abraham Lempel). В 1977 году они
описали технологию, основанную на использовании буфера скользящего окна,
хранящего только что обработанный текст [ZIV77]. Этот алгоритм обычно назы-
вают LZ77. Версия именно такого алгоритма используется в схеме сжатия ZIP
(PKZIP, gzip, zipit и т.д.).
Алгоритм LZ77 и его варианты основаны на том факте, что слова и фразы
внутри потока текста (или данные изображения в случае файла GIF), вероятнее
всего, повторяются. Когда это имеет место, повторная последовательность может
быть заменена более коротким кодом. Программа сжатия находит такие повто-
рения и строит коды прямо по ходу обработки данных, заменяя повторяющиеся
последовательности. В дальнейшем коды применяются повторно, чтобы обрабо-
тать новые последовательности. Алгоритм должен быть определен таким обра-
зом, чтобы программа декомпрессии могла построить правильное отображение
кодов в последовательности исходных данных.
Перед тем как приступить к детальному описанию LZ77, рассмотрим про-
стой пример.1 Возьмем бессмысленную фразу
the brown fox jumped over the brown foxy jumping frog,
длина которой равна 53 байт, или 424 бит. Алгоритм обрабатывает этот текст слева
направо. Сначала каждый символ отображается в 9-битовый двоичный код, склады-
вающийся из двоичной единицы и следующего за ней 8-битового ASCII-кода симво-
ла. В ходе дальнейшего выполнения алгоритм ищет повторяющиеся последователь-
ности. Когда встречается повторение, алгоритм продолжает сканирование до конца
повторяющейся последовательности. Другими словами, каждый раз, когда встреча-
ется повторение, алгоритм включает в повторяющуюся последовательность макси-
мальное количество символов. Здесь первой найденной повторяющейся последова-
тельностью будет the brown fox. Эта последовательность заменяется указателем на
предыдущую последовательность и данными о ее длине. В нашем случае встретив-
шаяся ранее последовательность the brown fox находится на 26 символов левее и
длина ее равна 13 символам. Для данного примера предположим два варианта коди-
рования: 8-битовый указатель и 4-битовое значение длины или 12-битовый указатель
и 6-битовое значение длины; 2-битовый заголовок указывает, какой вариант был вы-
бран: значение 00 обозначает первый вариант, а 01 — второй. Таким образом, второе
вхождение последовательности the brown fox кодируется в виде <00bx26dxl3d>,
или 0000011010 1101.
Оставшаяся часть сжатого сообщения складывается из буквы у, последова-
тельности <00bx27d x5d>, которая заменяет последовательность из символа
1 Основан на примере из [WEIS93].
Глава 5. Защита электронной почты
195
пробела и следующих за ним символов jump, а также последовательности сим-
волов ing frog.
Соответствующее отображение сжатия представлено на рис. 5.9. Сжатое со-
общение состоит из 35 9-битовых символов и двух кодов, в сумме это 35 х 9 +
2 х 14 = 343 бит. В сравнении с 424 битами несжатого сообщения это дает коэф-
фициент сжатия, равный 1,24.
the brown fox f jumped over the brown foxy jumping frog k 1 1 L_< —1
1J J
‘ 20 -27
the brown fox jumped over ob26d13d У 0b27d5d ing frog
Puc. 5.9. Пример применения схемы LZ77
Алгоритм сжатия
Алгоритм сжатия для схемы LZ77 и его варианты используют два буфера.
Скользящий буфер предыстории содержит N символов источника, обработанных
последними, а буфер упреждающей выборки содержит L символов, которые
должны обрабатываться следующими (рис. 5.10, а). Алгоритм пытается найти
два или несколько символов из буфера упреждающей выборки в строке из
скользящего буфера предыстории. Если совпадений не найдено, первый символ
из буфера упреждающей выборки выводится как 9-битовый символ, сам этот
символ перемещается в скользящее окно, а самый старый символ из этого окна
выталкивается. Если совпадение обнаружено, алгоритм продолжает просматри-
вать символы в поиске совпадающей последовательности наибольшей длины. За-
тем совпадающая строка выводится в виде трех значений (индикатор, указатель,
длина). Для строки из К символов самые старые К символов из скользящего ок-
на выталкиваются, а К символов кодированной строки сдвигаются в это окно.
На рис. 5.10, б показано действие этой схемы на последовательности из на-
шего примера. На иллюстрации изображено 39-символьное скользящее окно и
13-символьный буфер упреждающей выборки. В верхней части иллюстрации
уже обработано 40 первых символов и последние 39 из них в несжатом виде на-
ходятся в скользящем окне. Остальная часть данных источника находится в бу-
фере упреждающей выборки. Алгоритм сжатия определяет следующее повторе-
ние символов, перемещает пять символов из буфера упреждающей выборки в
скользящее окно и выводит код соответствующей строки. Состояние буфера по-
сле этих действий показано в нижней части иллюстрации.
Схема LZ77 является эффективной и адаптирующейся к природе вводимых
данных, и, тем не менее, она имеет определенные недостатки. Алгоритм использу-
ет ограниченное окно для поиска совпадений в предыдущем тексте. Для очень
длинных блоков текста в сравнении с размерами окна много потенциальных сов-
падений будет игнорироваться. Размер окна можно увеличить, но за это придется
платить следующим: во-первых, увеличением времени выполнения алгоритма, по-
196
Часть II. Приложения сетевой защиты
скольку необходимо выполнять сравнения строк из буфера упреждающей выборки
с каждой позицией в скользящем окне и, во-вторых, увеличением длины поля
<указатель> из-за необходимости указывать более длинные переходы.
Сдвиг
текста
источника
Вывод
сжатого текста
а) общая структура
he brown fox jumped over the brown foxy
own fox jumped over the brown foxy jump
б)пример
Рис. 5.10. Схема LZ77
Алгоритм декомпрессии
Распаковка сжатого по схеме LZ77 текста выполняется просто. Алгоритм
декомпрессии должен сохранять последние N символов восстановленного вывода.
Когда встречается закодированная строка, алгоритм декомпрессии использует
значения полей <указатель> и <длина>, чтобы заменить код реальной строкой
текста.
ДОПОЛНЕНИЕ 5.2. ПРЕОБРАЗОВАНИЕ
В 64-СИМВОЛЬНЫЙ ФОРМАТ
Как в PGP, так и в S/MIME применяется техника кодирования, назы-
ваемая преобразованием в 64-символьный формат (radix-64). Эта техника по-
зволяет отобразить вводимые двоичные данные произвольного вида в после-
довательности печатаемых символов. Данная форма кодирования имеет сле-
дующие характеристики.
1. Областью значений функции является набор символов, универсально
представимых в любом узле, и не требующих специальной двоичной ко-
дировки. Поэтому эти символы могут быть закодированы конкретной сис-
темой в любую форму. Например, символ “Е” представляется в системе на
базе ASCII как шестнадцатеричное 45, а в системе на базе EBCDIC — как
шестнадцатеричное С5.
. лава 5. Защита электронной почты
197
2. Этот набор символов состоит из 65 печатаемых символов, один из которых
выступает в качестве заполнителя. Доступными при этом являются 26 = 64
символа, так что каждый символ может использоваться для представления
6 бит данных ввода.
3. Никакие управляющие символы во множество не включаются. Таким обра-
зом, кодированное в 64-символьном формате сообщение может беспрепятст-
венно пройти сквозь любую систему почтовой обработки, просматривающую
поток данных в поиске управляющих символов.
4. Символ дефиса (“-”) не используется. Этот символ имеет особое значение в
формате RFC 822, поэтому его следует избегать.
В табл. 5.9 показано отображение 6-битовых значений ввода в символы.
Набор символов складываются из буквенно-цифровых символов, а также симво-
лов “+” и Символ “=” служит в качестве символа заполнителя.
Таблица 5.9. Кодирование radix-64
6-битовое значение Символ коди- рования 6-битовое значение Символ коди- рования 6-битовое значение Символ коди- рования 6-битовое значение Символ кодирова- ния
0 А 16 Q 32 g 48 W
1 В 17 R 33 h 49 X
2 С 18 S 34 Я 50 У
3 D 19 Т 35 J 51 Z
4 Е 20 и 36 к 52 0
5 F 21 V 37 1 53 1
6 G 22 W 38 m 54 2
7 Н 23 X 39 п 55 3
8 I 24 Y 40 о 56 4
9 J 25 Z 41 р 57 5
10 К 26 а 42 q 58 6
11 L 27 ь 43 Г 59 7
12 М 28 с 44 S 60 8
13 N 29 d 45 t 61 9
14 О 30 е 46 U 62 +
15 Р 31 f 47 V 63 /
(запол- нитель)
На рис. 5.11 показана схема соответствующего отображения. Двоичный
ввод обрабатывается блоками по 3 октета, или 24 бит. Каждый набор из 6 бит в
24-битовом блоке отображается в символ. На рисунке символы представлены за-
кодированными в виде 8-битовых величин. В таком типичном случае каждые 24
бит ввода расширяются до 32 бит вывода.
198
Часть II. Приложения сетевой защиты
-4--------------------- 24 бит ------------------►
----------------------- 4 символа = 32 бит -----------------------►
Рис. 5.11. Кодирование двоичных данных в виде печатаемых
символов в формате radix-64
Для примера рассмотрим 24-битовую текстовую последовательность
00100011 01011100 10010001, которая может быть записана в шестнадцатерич-
ном формате как 235С91. Разобьем эту последовательность на блоки по 6 бит:
001000 110101 110010 010001.
Выделенные 6-битовые значения в десятичном представлении соответственно
равны 8, 53, 50, 17. С помощью табл. 5.9 находим представление этих значений
в формате radix-64, в результате получая следующую последовательность симво-
лов: IlyR. Если эти символы сохранить в 8-битовом формате ASCII с разрядом
четности, равным нулю, получим
01001001 00110001 01111001 01010010.
В шестнадцатеричном представлении это 49317952. Итак, получаем следующее.
Входные данные
Двоичное представление Шестнадцатеричное представление 00100011 01011100 10010001 235С91
Представление входных данных в формате radix-64
Символьное представление IlyR
Коды ASCII (8-битовое представление с нулевым битом четности) 01001001 00110001 01111001 01010010
Шестнадцатеричное представление 49317952
Глава 5. Защита электронной почты
199
ДОПОЛНЕНИЕ 5.3. ГЕНЕРИРОВАНИЕ
СЛУЧАЙНЫХ ЧИСЕЛ PGP
В PGP используется сложная и мощная схема генерирования случайных и
псевдослучайных чисел. PGP генерирует случайные числа на основе последова-
тельности символов, соответствующих нажатиям клавиш пользователем, и ин-
тервалов между ними. Псевдослучайные числа генерируются с помощью алго-
ритма, в основу которого положен алгоритм из документа ANSI Х12.17. PGP
использует эти числа в следующих целях.
• Истинно случайные числа:
• применяются при создании пар ключей RSA,
• обеспечивают начальные значения для генератора псевдослучайных чисел,
• обеспечивают дополнительный ввод при генерировании псевдослучай-
ных чисел.
• Псевдослучайные числа:
• применяются при создании сеансовых ключей,
• служат для создания векторов инициализации (IV), используемых с сеан-
совыми ключами при шифровании в режиме CFB.
Истинно случайные числа
PGP поддерживает 256-байтовый буфер случайных битов. Все время PGP ожи-
дает нажатия клавиш пользователем, отразив в 32-битовом формате момент, с кото-
рого началось ожидание. Когда нажимается клавиша, записывается время нажатия
клавиши и 8-битовое значение нажатой клавиши. Информация о времени нажатия и
клавише применяется при генерировании ключа, который, в свою очередь, служит
для шифрования текущего значения из буфера случайных битов.
Псевдослучайные числа
При генерировании псевдослучайных чисел используется 24-байтовое на-
чальное значение и создается 16-байтовый сеансовый ключ, 8-байтовый вектор
инициализации и новое начальное значение, которые предполагается использо-
вать для получения следующего псевдослучайного числа. Алгоритм задействует
следующие структуры данных.
1. Ввод.
• randseed.bin (24 октета). Если этот файл пуст, он заполняется 24 ис-
тинно случайными октетами.
• Сообщение. Сеансовый ключ и значение IV, которые используются
для шифрования сообщения, являются функциями этого сообщения.
Это вносит дополнительную случайность для данного ключа и значе-
ния IV, поскольку если противник знает содержимое сообщения в ви-
де открытого текста, ему нет никакой необходимости выяснять значе-
ние сеансового ключа.
200
Часть II. Приложения сетевой защиты
2. Вывод.
• К (24 октета). Первые 16 октетов, К[0..15], содержат сеансовый ключ, а
последние восемь октетов, К[16.. 23], содержат значение IV.
• randseed.bin (24 октета). В этом файле размещается новое начальное
значение для генератора псевдослучайных чисел.
3. Внутренние структуры данных.
• dtbuf (8 октетов). Первые четыре октета, dtbuf[0..3], инициализируются с
помощью текущего значения даты-времени. Этот буфер эквивалентен пе-
ременной DT из алгоритма Х12.17.
• rkey (16 октетов). Ключ шифрования CAST-128, действующий на всех
стадиях алгоритма.
• rseed (8 октетов). Эквивалент переменной V(- из алгоритма XI2.17.
• rbuf (8 октетов). Псевдослучайное число, генерируемое алгоритмом. Этот
буфер эквивалентен переменной R( из алгоритма Х12.17.
• К' (24 октета). Временный буфер для нового значения randseed.bin.
Алгоритм состоит из девяти шагов. Первый и последний шаги призваны
уменьшить значение файла randseed.bin для противника, если последнему
удастся этот файл перехватить. Остальные шаги показаны на рис. 5.12. Пошаго-
вое описание алгоритма выглядит следующим образом.
К[16..23] К[8..15] КДО..7]
Рис. 5.12. Генерирование сеансового ключа и вектора инициализации
PGP (шаги G2-G8 алгоритма)
G1. [Дооперационная обработка начального значения.]
• randseed.bin копируется в К[0..23].
• Хэш-код сообщения (он уже имеется, если сообщение требует подписи
иначе используются первые 4096 октетов сообщения) служит в качеств»
ключа, вводится нулевое значение IV, и К шифруется в режиме CFB; ре
зультат сохраняется в К.
G2. [Установка начального значения.]
Глава 5. Защита электронной почты
20
• Для dtbuf[0.. 3] устанавливается значение, равное 32-битовому значению
текущего локального времени. Значение dtbuf[4..7] обнуляется. Копиру-
ется rkey <— К[0..15]. Копируется rseed <— К[16..23].
• 64-битовое значение dtbuf шифруется с использованием 128-битового зна-
чения rkey в режиме ЕСВ; результат сохраняется в dtbuf.
G3. [Подготовка к генерированию случайных октетов.] Устанавливается
rcount <— 0 и к <— 23. Циклическое повторение шагов G4-G7 будет выпол-
нено 24 раза (для к= 23 ... 0), и при каждом выполнении будет получен
случайный октет, помещаемый в К. Переменная rcount представляет число
еще неиспользованных случайных октетов в rbuf. Ее значение трижды
уменьшается от 8 до 0, чтобы в результате было получено 24 октета.
G4. [Доступны ли еще байты?] Если rcount = 0, следует перейти к шагу G5, в
противном случае — к шагу G7.
G5. [Генерирование новых случайных октетов.]
• rseed <— rseed © dtbuf .
• rbuf <— Erkey[rseed] в режиме ЕСВ.
G6. [Генерирование следующего начального значения.]
• rseed <— rseed©dtbuf .
• rbuf <— Erkey[rseed] в режиме ЕСВ.
• Устанавливается rcount <— 8.
G7. [Перенос по одному байту из rbuf в К.]
• Устанавливается rcount <— rcount-1.
• Генерируется истинно случайный байт b и устанавливается
K[k] <— rbuf [rcount] Ф b .
G8. [Готово?] Если к=0, следует перейти к шагу G9, в противном случае уста-
нов!вгь к <— к-1 и перейти к шагу G4.
G9. [Послеоперационная обработка начального значения и возвращение ре-
зультата.]
• Генерируются еще 24 байт методом, представленным шагами G4-G7, но
связывание с помощью операции XOR со случайным значением в G7 не
производится. Результат помещается в буфер К'.
• К' шифруется в режиме CFB с ключом К[0..15] и вектором инициали-
зации К[16..23]; результат сохраняется в randseed.bin.
• Возвращается К.
Определить сеансовый ключ из 24 новых октетов, генерируемых на шаге
G5, должно быть невозможно. Однако, чтобы гарантировать, что сохраненный
файл randseed.bin не даст информации о последнем сеансовом ключе, шифру-
ется 24 новых октета, и результат сохраняется как новое начальное значение
для генератора псевдослучайных чисел.
Этот тщательно проработанный алгоритм должен порождать криптографи-
чески надежные псевдослучайные числа.
202
Часть II. Приложения сетевой защиты
6
ГЛАВА
Защита IP
6.1. Обзор возможностей защиты на уровне IP
6.2. Архитектура защиты на уровне IP
6.3. Заголовок аутентификации
6.4. Защищенный полезный груз
6.5. Комбинации защищенных связей
6.6. Управление ключами
6.7. Рекомендуемые источники дополнительной
информации
6.8. Задачи
Дополнение 6.1. Протоколы межсетевого
взаимодействия
Сообщество Internet разработало механизмы защиты для целого ряда прило-
жений, включая электронную почту (S/MIME, PGP), приложения типа кли-
ент-сервер (Kerberos), приложения доступа к ресурсам Web (Secure Sockets
Layer — протокол защищенных сокетов) и т.д. Однако некоторые вопросы защиты
не укладываются в рамки протокола определенного уровня. Например, предпри-
ятие может защищать свою сеть TCP/IP, запретив доступ к ненадежным узлам,
шифруя пакеты данных, покидающие сеть предприятия, и требуя аутентификации
пакетов, приходящих в сеть извне. С помощью защиты на уровне IP (Internet Pro-
tocol — протокол межсетевого взаимодействия) организация может обеспечить
безопасность не только сетевых приложений, имеющих свои встроенные средства
защиты, но и приложений, не обладающих такими возможностями.
Защита на уровне IP охватывает три сферы безопасности: аутентифика-
цию, конфиденциальность и управление ключами. Механизм аутентификации
должен гарантировать, что полученный пакет был на самом деле отправлен
стороной, указанной в качестве источника сообщения в заголовке пакета.
Кроме того, тот же механизм должен гарантировать, что пакет по пути не был
изменен. Средства конфиденциальности должны обеспечить возможность шиф-
рования передаваемых сообщений, чтобы исключить риск чтения таких сооб-
щений третьей стороной. Средства управления ключами должны гарантировать
защиту процесса обмена ключами.
Мы начнем эту главу с обсуждения защищенного протокола IP (IPSec) и его
архитектуры. Затем будет рассмотрена каждая из трех функций защиты данного
протокола в отдельности. В дополнении к этой главе предлагается обзор прото-
колов межсетевого взаимодействия.
6.1. ОБЗОР ВОЗМОЖНОСТЕЙ ЗАЩИТЫ
ИА УРОВНЕ IP
В 1994 году Совет по архитектуре Internet (Internet Architecture Board —
IAB) опубликовал отчет, названный “Защита в рамках архитектуры Internet”
(документ RFC 1636, “Security in the Internet Architecture”). Отчет отразил
общее понимание того, что Internet нуждается в большей и лучшей защите, и
определил области применения ключей в механизмах защиты. Среди прочего
отмечалась необходимость защиты сетевой инфраструктуры от несанкциониро-
ванного мониторинга и управления потоками данных, а также защиты сквоз-
ного обмена данными между пользователями с помощью средств аутентифика-
ции и шифрования.
Такие требования вполне оправданны. Подтверждением могут служить дан-
ные ежегодного отчета CERT (Computer Emergency Rresponse Team — группа
компьютерной “скорой помощи”) 1998 года, в котором сообщается более чем о
1300 зарегистрированных случаях нарушений защиты, повлиявших на работу
почти 20000 узлов [CERT99]. К наиболее серьезным типам нарушений относятся
фальсификация адресов IP (когда нарушители создают пакеты с ложными IP-
адресами и используют приложения, предполагающие аутентификацию на осно-
ве адресов IP) и самые разные формы перехвата пакетов с данными (в результате
чего нарушители получают передаваемую информацию, включая информацию
аутентификации и содержимое баз данных).
204
Часть II. Приложения сетевой защиты
В ответ на эту угрозу IAB счел необходимым рассматривать аутентифика-
цию и шифрование как обязательные средства защиты протокола IP следующего
поколения (протокола IPv6). К счастью, эти средства можно применять как с
действующим сейчас протоколом IPv4, так и с протоколом будущего IPv6. Это
значит, что поставщики могут предлагать соответствующие возможности уже
сейчас, и многие из них действительно делают это.
Области применения IPSec1
Протокол IPSec обеспечивает защиту обмена данными в локальных сетях,
корпоративных и открытых глобальных сетях и в Internet. Примеры его приме-
нения включают следующее.
• Защищенный доступ к филиалу организации через Internet. Компания может
построить защищенную частную виртуальную сеть в рамках сети Internet или
другой открытой глобальной сети. Это позволяет использовать каналы Internet
и тем самым сократить расходы на создание и поддержку частной сети.
• Защищенный удаленный доступ через Internet. Конечный пользователь, в
системе которого предусмотрены протоколы защиты IP, может с помощью
локального телефонного вызова обратиться к поставщику услуг Internet и
получить защищенный доступ к сети компании. Это сокращает транспорт-
ные расходы служащих и надомных работников.
• Внутрисетевое и межсетевое взаимодействие с партнерами. Средства IPSec
могут обеспечить защищенную связь с другими организациями, гарантируя
аутентификацию и конфиденциальность, а также предлагая механизм об-
мена ключами.
• Усиление защиты электронных коммерческих операций. Даже если какие-
то приложения Web и электронной коммерции имеют встроенные протоко-
лы защиты данных, использование IPSec усиливает эту защиту.
Главной особенностью IPSec, позволяющей этому протоколу поддерживать
самые разнообразные приложения, является возможность шифрования и/или
аутентификации всего потока данных на уровне IP. Таким образом, защита мо-
жет быть обеспечена любому распределенному приложению, включая приложе-
ния удаленной регистрации, приложения типа клиент-сервер, приложения элек-
тронной почты, передачи файлов, доступа к ресурсам Web и т.д.
На рис. 6.1 показан типичный сценарий использования IPSec. Некоторая
организация поддерживает ряд локальных сетей, находящихся в разных местах.
В рамках этих локальных сетей трафик IP не защищается. Для обмена данными
через корпоративную или открытую внешнюю глобальную сеть используются
протоколы IPSec. Эти протоколы применяются устройствами, размещенными по
периметру сети (например, маршрутизаторами или брандмауэрами) и соединяю-
щими локальные сети с внешним миром. Использующее IPSec сетевое устройст-
во обычно шифрует и сжимает весь поток данных, отправляемый в глобальную
сеть, и дешифрует и разворачивает данные, приходящие извне. Все выполняе-
мые в этом случае операции не заметны для рабочих станций и серверов локаль-
1 Материал этого раздела опирается на сведения из документа IP Security
Whitepaper, изданного С у LAN Technologies в 1997 году и доступного по адресу
http://www.cylan.com/files/whpaper.htm.
Глава 6. Защита IP
205
ной сети. Защищенный обмен данными возможен и с индивидуальными пользо-
вателями, использующими удаленный доступ к сети через глобальные сети. Что-
бы обеспечить защиту, рабочие станции таких пользователей тоже должны ис-
пользовать протоколы IPSec.
Рис. 6.1. Защита на уровне IP
Преимущества IPSec
В [MARK97] перечислены следующие преимущества IPSec.
• Если поддержку IPSec реализовать в брандмауэре или маршрутизаторе, это
обеспечит надежную защиту всему потоку данных, идущему через границу
локальной сети. При этом поток данных внутри локальной сети компании
или рабочей группы не перегружается лишними операциями, связанными с
защитой.
• Средства IPSec в брандмауэре трудно обойти, если использование IP пред-
полагается для всего потока данных, а брандмауэр является единственной
точкой, связывающей сеть организации с Internet.
• Средства IPSec размещаются ниже транспортного уровня (TCP, UDP), а по-
этому оказываются незаметными для приложений. Нет необходимости ме-
нять программное обеспечение в системах пользователя или сервера, когда
в брандмауэре или маршрутизаторе реализуется IPSec. Даже если IPSec
реализуется в конечных системах, на программное обеспечение верхнего
уровня, включая приложения, это не влияет.
• Использование IPSec может быть незаметным для конечного пользователя.
Нет необходимости объяснять пользователю механизмы защиты, выдавая
ему соответствующие инструкции и требуя их вернуть, когда он покинет
организацию.
206
Часть II. Приложения сетевой защиты
• При необходимости IPSec может обеспечить защиту индивидуальным поль-
зователям. Это может понадобиться для лиц, работающих вне территории
предприятия, или при создании защищенной виртуальной подсети внутри
организации для работы с особо важными приложениями.
Приложения маршрутизации
Кроме поддержки конечных пользователей и защиты систем и сетей пред-
приятия, IPSec может участвовать в создании архитектуры маршрутизации при
межсетевом взаимодействии. В [HUIT98] приводится следующий список приме-
ров использования IPSec. Применение IPSec может гарантировать, что:
• прибывающее извещение маршрутизатора (т.е. сообщение нового маршру-
тизатора, объявляющее о его присутствии в сети) действительно исходит от
авторизованного маршрутизатора;
• прибывающее извещение соседнего маршрутизатора (т.е. маршрутизатора,
пытающегося установить отношения соседства с маршрутизатором из друго-
го домена маршрутизации) действительно исходит от авторизованного мар-
шрутизатора;
• прибывающее сообщение переадресации исходит именно от того маршрути-
затора, которому посылался исходный пакет;
• прибывающее обновление маршрута не является фальсифицированным.
Если не использовать меры защиты, противник может разорвать связь или
направить поток данных в обход по некоторому другому пути. Для защищенных
связей между маршрутизаторами, определенных протоколом IPSec, должны
поддерживаться протоколы маршрутизации типа OSPF (Open Shortest Path
First — первоочередное открытие кратчайших маршрутов).
6.2. АРХИТЕКТУРА ЗАЩИТЫ НА УРОВНЕ IP
Спецификации IPSec довольно сложны. Чтобы получить общее представле-
ние об архитектуре IPSec, мы начнем с обсуждения документов, определяющих
этот протокол. Затем мы исследуем сервисы IPSec и определим понятие защи-
щенных связей.
Документы IPSec
Спецификации IPSec определяются целым рядом документов. Наиболее
важными из них, опубликованными в ноябре 1998 года, являются документы
RFC с номерами 2401, 2402, 2406 и 2408 (см. приложение 1 в конце книги):
• RFC 2401 — обзор архитектуры защиты;
• RFC 2402 — описание расширений аутентификации пакетов IPv4 и IPv6;
• RFC 2406 — описание расширений шифрования пакетов IPv4 и IPv6;
• RFC 2408 — спецификации средств управления ключами.
Поддержка этих возможностей обязательна для IPv6 и допустима, но не обяза-
тельна для IPv4. В обоих случаях средства защиты реализуются в виде заголов-
Глава 6. Защита IP
207
ков расширений, которые следуют за основным заголовком IP. Заголовок рас-
ширения аутентификации называют заголовком АН (Authentication Header —
заголовок аутентификации), а заголовок расширения шифрования — заголовком
ESP (Encapsulating Security Payload header — заголовок защищенного полезного
груза, или заголовок защищенного содержимого).
В дополнение к этим четырем документам Рабочая группа разработки про-
токола защиты IP (IP Security Protocol Working Group), созданная IETF, опуб-
ликовала еще ряд проектов стандартов. Все документы разделены на следующие
семь групп (рис. 6.2).
• Архитектура. Содержит описание общих принципов, требований защиты, а
также определения и механизмы реализации технологии IPSec.
• Защищенный полезный груз (ESP). Описание формата пакета и общих
принципов использования ESP для шифрования пакетов и, если нужно, для
аутентификации.
• Заголовок аутентификации (АН). Описание формата пакета и общих прин-
ципов использования АН для аутентификации пакетов.
• Алгоритм шифрования. Набор документов, определяющих использование
различных алгоритмов шифрования для ESP.
• Алгоритм аутентификации. Набор документов, определяющих использова-
ние различных алгоритмов аутентификации для АН и для опции аутенти-
фикации ESP.
• Управление ключами. Документы, описывающие схемы управления ключами.
• Область интерпретации (DOI — Domain of Interperetaion). Содержит значе-
ния, необходимые для соответствия одних документов другим. Это, в част-
ности, идентификаторы проверенных алгоритмов шифрования и аутенти-
фикации, а также некоторые параметры, например, продолжительности
жизненного цикла ключей.
Сервис IPSec
IPSec обеспечивает сервис защиты на уровне IP, позволяя системе выбрать не-
обходимые протоколы защиты, определить алгоритм (алгоритмы) для соответст-
вующего сервиса (сервисов) и задать значения любых криптографических ключей,
требующихся для запрашиваемого сервиса. Для защиты используется два протокола:
протокол аутентификации, указанный заголовком аутентификации АН, и комбини-
рованный протокол шифрования/аутентификации, определенный форматом пакета
для протокола ESP. В данном случае обеспечиваются следующие виды сервиса:
• управление доступом;
• целостность без установки соединений;
• аутентификация источника данных;
• отторжение воспроизведенных пакетов (форма целостности последователь-
ностей);
• конфиденциальность (шифрование);
• ограниченная конфиденциальность транспортного потока.
208
Часть II. Приложения сетевой защиты
Рис. 6.2. Общая структура документации IPSec
В табл. 6.1 показано, какие из этих сервисов обеспечиваются протоколами
АН и ESP. В ESP имеются два варианта — с использованием и без использова-
ния опции аутентификации. Как АН, так и ESP имеют возможности управления
доступом, основанные на распределении криптографических ключей и управле-
нии транспортными потоками, связанными с этими протоколами защиты.
Таблица 6.1. Сервис IPSec
Управление доступом
Целостность без установки соединений
Аутентификация источника данных
Отторжение воспроизведенных пакетов
Конфиденциальность
Ограниченная конфиденциальность
транспортного потока
АН ESP ESP
(только (шифрование
шифрование) и аутентификация)
✓ ✓ ✓
✓
✓ ✓
✓ ✓ ✓
✓ ✓
✓ ✓
Глава 6. Защита IP
209
Защищенные связи
Ключевым объектом в механизмах аутентификации и конфиденциальности
IP является защищенная связь (Security Association). Связь представляет собой
одностороннее отношение между отправителем и получателем, применяющим
сервис защиты к транспортному потоку. Если требуется равноправное отношение
для двустороннего защищенного обмена, необходимы две защищенные связи.
Сервис защиты дает возможность для защищенной связи использовать либо АН,
либо ESP, но никак не оба эти протокола одновременно.
Защищенная связь однозначно определяется следующими тремя параметрами.
• Индекс параметров защиты. Строка битов, присваиваемая данной защи-
щенной связи и имеющая только локальное значение. Индекс параметров
защиты передается в заголовках АН и ESP, чтобы принимающая система
имела возможность выбрать защищенную связь, в рамках которой должен
обрабатываться принимаемый пакет.
• Адрес IP пункта назначения. В настоящее время допускаются только одно-
направленные адреса — это адрес пункта назначения защищенной связи,
который может представлять систему конечного пользователя или сетевой
объект типа брандмауэра или маршрутизатора.
• Идентификатор протокола защиты. Этот идентификатор указывает, являет-
ся ли данная связь защищенной связью АН или это защищенная связь ESP.
Таким образом, в любом пакете IP2 защищенная связь однозначно идентифи-
цируется адресом пункта назначения, указанным в заголовке IPv4 или IPv6, и ин-
дексом параметров защиты во вложенном заголовке расширения (АН или ESP).
Параметры защищенной связи
В каждой реализации IPSec имеется номинальная3 таблица защищенных
связей (Security Association Database), которая определяет параметры защищен-
ных связей. Защищенная связь характеризуется следующими параметрами.
• Счетчик порядкового номера. 32-битовое значение, используемое при гене-
рировании значений поля порядкового номера в заголовках АН или ESP
(требуется во всех реализациях).
• Флаг переполнения счетчика порядкового номера. Флаг, указывающий на
переполнение счетчика порядкового номера, должен генерировать регистри-
руемое событие и вести к прекращению дальнейшей передачи пакетов с
применением этой защищенной связи (требуется во всех реализациях).
• Окно защиты от воспроизведения. Используется для выявления воспроиз-
веденных пакетов среди прибывающих пакетов АН или ESP, как описано
ниже в разделе 6.3 (требуется во всех реализациях).
2 В этой главе термин пакет IP означает либо дейтаграмму IPv4, либо пакет IPv6.
3 Номинальная в том смысле, что функциональные возможности, обеспечиваемые таб-
лицей защищенных связей, должны существовать в любой реализации IPSec, но способ, кото-
рым эти функциональные возможности реализуются, выбирается разработчиком.
210
Часть II. Приложения сетевой защиты
• Информация АН. Алгоритм аутентификации, ключи, параметры продол-
жительности жизни ключей и другие необходимые параметры, используе-
мые в рамках АН (требуются в реализациях АН).
• Информация ESP. Алгоритм шифрования и аутентификации, ключи, зна-
чения инициализации, параметры продолжительности жизни ключей и
другие необходимые параметры, используемые в рамках ESP (требуются в
реализациях ESP).
• Продолжительность жизни данной защищенной связи. Интервал времени
или значение счетчика байтов, по достижении которого защищенная связь
должна быть заменена новой (с новым индексом параметров защиты) или
завершена с указанием того, какое именно из этих событий должно про-
изойти (требуется во всех реализациях).
• Режим протокола IPSec. Туннельный, транспортный или задаваемый груп-
повым символом (требуется во всех реализациях). Режимы описаны в этом
разделе ниже.
• Максимальная единица передачи (Maximum Transmission Unit — MTU)
маршрута. Максимальная единица передачи (максимальный размер пакета,
который может быть передан без фрагментации) для всех участков маршру-
та и переменные времени существования (требуются во всех реализациях).
Механизм управления ключами связывается с механизмами аутентифика-
ции и конфиденциальности только через индекс параметров защиты. Таким об-
разом, аутентификация и конфиденциальность оказываются определенными не-
зависимо от конкретного механизма управления ключами.
Селекторы защищенной связи
IPSec обеспечивает пользователю значительную гибкость в выборе способа
применения средств IPSec к трафику IP. Как мы вскоре убедимся, защищенные
связи могут комбинироваться, чтобы предоставить пользователю желаемую кон-
фигурацию. Кроме того, IPSec обеспечивает достаточную избирательность, раз-
личая трафик, подлежащий защите IPSec, и трафик, которому позволяется
обойти IPSec, что достигается путем ассоциации части потока данных IP с
имеющимися защищенными связями.
Средством, с помощью которого реализуется ассоциация потока IP с защи-
щенными связями (или отсутствием таковой, если потоку данных позволено
обойти IPSec), является номинальная база данных политики защиты (Security
Policy Database — SPD). В наиболее простой своей форме база данных политики
защиты представляет собой набор записей, каждая из которых определяет неко-
торое подмножество потока IP и указывает защищенную связь для этого под-
множества потока. В более сложных средах может определяться несколько запи-
сей, потенциально соответствующих одной защищенной связи, или множество
защищенных связей, ассоциируемых с одним элементом базы данных политики
защиты. (Более подробную информацию по этому вопросу можно почерпнуть из
соответствующих документов IPSec.)
Каждая запись базы данных политики защиты состоит из набора значений
полей протокола IP и протоколов более высокого уровня — эти поля называются
селекторами. Селекторы используются для фильтрации исходящего потока с
Глава 6. Защита IP
211
целью его отображения в конкретную защищенную связь. Каждый отправляе-
мый пакет IP обрабатывается следующим образом.
1, Сравниваются значения соответствующих полей пакета (селекторов) с по-
лями базы данных политики защиты и в результате этого находится нуж-
ная запись базы данных политики защиты, в которой указано некоторое
(возможно, нулевое) число защищенных связей.
2. Определяется защищенная связь и соответствующий индекс параметров за-
щиты для данного пакета, если защита требуется.
3. Выполняются необходимые операции IPSec (т.е. обработка АН или ESP).
Запись базы данных политики защиты состоит из следующих селекторов.
• Адрес IP пункта назначения. Это может быть один адрес IP, нумерованный
список или диапазон адресов, либо группа адресов, задаваемая групповым
символом (маской). Последние два варианта предназначены для указания
нескольких систем-адресатов, использующих одну защищенную связь.
® Адрес IP источника. Это может быть один адрес IP, нумерованный список
или диапазон адресов, либо группа адресов, задаваемая групповым симво-
лом (маской). Последние два варианта обеспечивают возможность указать
несколько систем-источников, использующих одну защищенную связь.
® Идентификатор пользователя (UserID). Идентификатор пользователя, по-
лучаемый от операционной системы. Это не поле в заголовке IP или заго-
ловке протокола более высокого уровня, но оно доступно, когда IPSec вы-
полняется в той же операционной системе, с которой работает пользователь.
• Уровень (гриф) секретности данных. Предусмотрен для систем, обеспечи-
вающих соответствующую защиту информационного потока (например,
секретный или несекретный).
® Протокол транспортного уровня. Соответствующая информация берется из
протокола IPv4 и поля Next Header (следующий заголовок) IPv6. Это может
быть конкретный номер протокола, список номеров протоколов или диапа-
зон номеров протоколов.
* Протокол IPSec (АН, или ESP, или АН/ESP). Если присутствует, то взят из
протокола IPv4 или из поля Next Header (следующий заголовок) IPv6.
® Порты источника и адресата. Это либо конкретные значения портов TCP
или UDP, нумерованный список портов, либо порт, представленный груп-
повым символом (wildcard).
® Класс IPv6. Соответствующая информация берется из заголовка IPv6. Это
может быть конкретное значение для класса IPv6 или значение, задаваемое
групповым символом.
® Метка потока IPv6. Соответствующая информация берется из заголовка
IPv6. Это может быть конкретное значение для метки потока IPv6 или зна-
чение, задаваемое групповым символом.
» Тип сервиса IPv4 (Type of Service — TOS). Соответствующая информация
берется из заголовка IPv4. Это может быть конкретное значение для типа
сервиса IPv4 или значение, задаваемое групповым символом.
Часть II. Приложения сетевой защиты
Транспортный и туннельный режимы
Заголовки АН и ESP поддерживают два режима использования: транспорт-
ный и туннельный. Суть этих двух режимов лучше всего понять в контексте
описаний заголовков АН и ESP, о которых пойдет речь соответственно в разде-
лах 6.3 и 6.4. Здесь же мы ограничимся кратким определением этих режимов.
Транспортный режим
Транспортный режим обеспечивает защиту прежде всего для протоколов
высшего уровня. Это значит, что защита транспортного режима распространяет-
ся на полезный груз пакета IP. Примерами могут быть сегменты TCP
(Transmission Control Protocol — протокол управления передачей) или UDP
(User Datagram Protocol — протокол передачи дейтаграмм пользователя), или же
пакет ICMP (Internet Control Message Protocol — протокол управления сообще-
ниями в сети Internet), размещающиеся в стеке протоколов хоста непосредствен-
но над IP. Обычно транспортный режим обеспечивает сквозную связь двух узлов
(например, клиента и сервера или двух рабочих станций). Когда система исполь-
зует заголовки АН или ESP над IPv4, полезным грузом являются данные, обыч-
но размещаемые сразу после заголовка IP. Для IPv6 полезным грузом являются
данные, обычно следующие после заголовка IP и всех имеющихся заголовков
расширений IPv6, за возможным исключением заголовка параметров адресата,
который тоже может подлежать защите.
ESP в транспортном режиме шифрует и, если нужно, аутентифицирует по-
лезный груз IP, но не заголовок IP. АН в транспортном режиме предполагает
аутентификацию полезного груза IP и некоторых частей заголовка IP.
Туннельный режим
Туннельный режим обеспечивает защиту всего пакета IP. Чтобы выполнить
эту задачу, после добавления к пакету IP полей АН или ESP весь пакет вместе с
полями защиты рассматривается как полезный груз некоторого нового “внешнего”
пакета IP с новым внешним заголовком IP. Весь оригинальный (внутренний) пакет
при этом пересылается через “туннель” от одной точки сети IP к другой, и ни один
из маршрутизаторов на пути не может проверить внутренний заголовок IP. По-
скольку оригинальный пакет инкапсулирован в новый, больший пакет, этот новый
пакет может иметь совершенно другие параметры источника и адресата, что, оче-
видно, усиливает защиту. Туннельный режим используется тогда, когда один или
оба конца защищенной связи являются шлюзами защиты, например, брандмау-
эрами или маршрутизаторами, использующими IPSec. При использовании тун-
нельного режима размещенные за брандмауэрами системы могут осуществлять
защищенный обмен данными без применения IPSec. Незащищенные пакеты, гене-
рируемые такими системами, передаются по туннелям, проложенным через внеш-
ние сети с помощью защищенных связей в туннельном режиме, устанавливаемых
программным обеспечением IPSec брандмауэра или защищенного маршрутизатора
на границе локальной сети.
Рассмотрим пример использования туннельного режима IPSec. Узел А сети
генерирует пакет IP с адресом узла назначения В в другой сети. Этот пакет на-
правляется от создавшего пакет узла к брандмауэру или защищенному маршру-
тизатору на границе сети А. Брандмауэр фильтрует все исходящие пакеты, что-
Глава 6. Защита IP
213
бы выяснить, нужно ли их защищать с помощью IPSec. Если направляющийся
от А к В пакет требует применения средств IPSec, брандмауэр выполняет функ-
ции IPSec и инкапсулирует оригинальный пакет во внешний пакет IP. Адресом
IP отправителя этого внешнего пакета IP будет данный брандмауэр, а адресом
получателя может быть брандмауэр, формирующий границу локальной сети В.
Теперь пакет направляется брандмауэру узла В, а промежуточные маршрутиза-
торы будут иметь дело только с внешним заголовком IP. В брандмауэре узла В
внешний заголовок IP удаляется, а внутренний пакет доставляется узлу В.
ESP в туннельном режиме шифрует и, если нужно, аутентифицирует весь внут-
ренний пакет IP, включая внутренний заголовок IP. АН в туннельном режиме ау-
тентифицирует весь внутренний пакет IP и некоторые части внешнего заголовка IP.
В табл. 6.2 представлены функциональные возможности транспортного и
туннельного режимов.
Таблица 6.2. Функциональные возможности транспортного и туннельного режимов
Транспортный режим защищенной связи Туннельный режим защищенной связи
АН Аутентифицирует полезный груз IP, а также некоторые части за- головка IP и заголовков расшире- ний IPv6 Аутентифицирует весь внутренний пакет IP (заголовок и полезный груз внутреннего пакета IP), а так- же некоторые части внешнего заго- ловка IP и внешних заголовков расширений IPv6
ESP Шифрует полезный груз IP и все заголовки расширений IPv6, сле- дующие за заголовком ESP Шифрует внутренний пакет IP
ESP с аутен- Шифрует полезный груз IP и все Шифрует внутренний пакет IP.
тификацией заголовки расширений IPv6, сле- дующие за заголовком ESP. Аутентифицирует полезный груз IP, но не заголовок IP Аутентифицирует внутренний пакет IP
6.3. ЗАГОЛОВОК АУТЕНТИФИКАЦИИ
Заголовок аутентификации (АН) обеспечивает поддержку целостности дан-
ных и аутентификацию пакетов IP. Свойство целостности данных гарантирует
невозможность тайной модификации содержимого пакета в пути следования.
Функция аутентификации позволяет конечной системе или сетевому устройству
идентифицировать пользователя или приложение и соответственно отфильтро-
вать трафик, а также защититься от очень распространенных сегодня в Internet
атак с подменой сетевых адресов. Заголовок АН защищает и от атак воспроизве-
дения сообщений, речь о которых пойдет ниже.
Аутентификация опирается на использование кодов аутентичности сообще-
ний, как объяснялось в главе 3, при этом две стороны должны использовать об-
щий секретный ключ.
Заголовок аутентификации состоит из следующих полей (рис. 6.3).
• Следующий заголовок (8 бит). Идентифицирует тип заголовка, следующего
непосредственно за данным заголовком.
214
Часть II. Приложения сетевой защиты
* Длина полезного груза (8 бит). Длина заголовка аутентификации в 32-
битовых словах, уменьшенная на 2. Например, установленная по умолча-
нию длина поля данных аутентификации равна 96 бит, или трем 32-
битовым словам. Вместе с заголовком фиксированной длины в три слова
общая длина всего заголовка оказывается равной шести словам, поэтому в
поле длины полезного груза в этом случае указывается значение 4.
® Зарезервировано (16 бит). Для будущего использования.
® Индекс параметров защиты (32 бит). Идентифицирует защищенную связь.
® Порядковый номер (32 бит). Значение счетчика, которое будет описано ниже.
® Данные аутентификации (переменной длины). Поле переменной длины
(равной целому числу 32-битовых слов), содержащее код ICV (Integrity
Check Value — код контроля целостности) или код MAC (Message Authenti-
cation Code — код аутентичности сообщения) для данного пакета, что под-
робнее объясняется ниже.
Бит: О
8
31
Следующий
заголовок
Длина полезного
груза
ЗАРЕЗЕРВИРОВАНО
Индекс параметров защиты
Порядковый номер
Данные аутентификации (переменной длины)
Рис. 6.3. Заголовок аутентификации IPSec
Сервис защиты от воспроизведения
Атака воспроизведения сообщений заключаются в том, что противник мо-
жет получить экземпляр удостоверенного пакета и позже предъявить его пред-
полагаемому адресату. Повторное получение одинаковых пакетов IP может ка-
ким-то образом нарушить сервис или иметь другие нежелательные последствия.
Поле порядкового номера предлагается использовать как раз для того, чтобы ис-
ключить возможность проведения такой атаки. Сначала мы обсудим вопрос ге-
нерирования порядкового номера отправителем, а затем выясним, как этот но-
мер обрабатывается получателем.
Когда устанавливается новая защищенная связь, отправитель инициализи-
рует счетчик порядковых номеров, установив соответствующее значение равным
0. Каждый раз, когда по соответствующей защищенной связи посылается пакет,
отправитель увеличивает значение данного счетчика и размещает его в поле по-
рядкового номера. Таким образом, первым используемым значением будет 1.
Если активна функция защиты от воспроизведения (что предполагается по
умолчанию), отправитель не должен позволить порядковому номеру превзойти
значение 232 - 1 , после которого значение счетчика должно снова стать равным
Глава 6. Защита IP
215
нулю, поскольку тогда по крайне мере два действительных пакета будут иметь
один и тот же порядковый номер. Если предел 232 -1 оказывается достигнутым,
отправитель должен завершить данную защищенную связь и начать переговоры
о создании новой защищенной связи с новым ключом.
Поскольку IP предполагает обмен без установления соединений, т.е. является
не слишком надежным сервисом, протокол не гарантирует, что пакеты будут достав-
лены в требуемом порядке и без потерь. Поэтому аутентификация IPSec требует,
чтобы получатель имел специальное окно размера W (по умолчанию IV = 64). Правая
граница окна должна представлять наивысший порядковый номер N для уже полу-
ченных действительных пакетов. Для любого пакета с порядковым номером из диа-
пазона от NW + 1 до N, который принят корректно (т.е. должным образом аутенти-
фицирован), помечается соответствующий сегмент окна (рис. 6.4). При получении
пакета его обработка выполняется следующим образом.
1. Если полученный пакет попадает в рамки окна и является новым, проверя-
ется значение МАС. Если аутентификация пакета завершается успешно,
помечается соответствующий сегмент в окне.
2. Если полученный пакет попадает в область правее окна и является новым,
проверяется значение МАС. Если аутентификация пакета завершается ус-
пешно, окно расширяется так, чтобы новый порядковый номер оказался
правой границей окна, а в окне помечается соответствующий сегмент.
3. Если полученный пакет оказывается слева от окна или аутентифицировать
его не удается, он будет отвергнут. Такое событие должно регистрироваться.
Увеличить окно, если получен
действительный пакет
с номером, оказывающимся
правее
пакет получен пакет еще не получен
Рис. 6.4. Механизм защиты от воспроизведения
Код контроля целостности
Поле данных аутентификации содержит значение, называемое кодом ICV
(Integrity Check Value — код контроля целостности). Код ICV представляет собой
код аутентичности сообщения или усеченную версию такого кода, порожденного
алгоритмом МАС. Имеющиеся на сегодня спецификации протокола требуют,
чтобы любая реализация поддерживала следующие схемы:
216
Часть II. Приложения сетевой зашиты
* HMAC-MD5-96,
* HMAC-SHA-1-96.
Обе схемы предполагают применение алгоритма НМАС, в первом случае с ис-
пользованием хэш-кода MD5, а во втором — хэш-кода SHA-1 (все указанные ал-
горитмы описаны в главе 3). В обоих случаях вычисляется полное значение
НМАС, но затем оно усекается до первых 96 бит, что соответствует длине поля
данных аутентификации, установленной по умолчанию.
Для вычисления значения МАС берется следующая информация.
® Поля заголовка IP, которые либо не изменяются в пути следования
(неизменяемые поля), либо имеют прогнозируемые значения в пункте на-
значения защищенной связи АН. Поля, которые могут измениться в пути
следования, и значения которых в конечной точке нельзя предсказать, об-
нуляются для вычислений и в пункте отправки, и в пункте назначения.
® Заголовок АН, отличный от поля данных аутентификации. Поле данных
аутентификации обнуляется для вычислений и в пункте отправления, и в
пункте назначения.
® Все данные протокола следующего выше уровня, которые должны оставать-
ся неизменными в пути следования (например, сегмент TCP или внутренний
пакет IP в туннельном режиме).
Для IPv4 примерами неизменяемых полей являются поля длины заголовка
Internet и адреса источника. Примером изменяемого, но прогнозируемого поля
служит поле адреса получателя (с приближенной или строгой трассировкой от
источника сообщения). Примерами изменяемых полей, которые обнуляются пе-
ред вычислением ICV, являются поля времени существования и контрольной
суммы заголовка. Заметим, что поля адреса как источника, так и адресата за-
щищаются, так что их фальсификация исключена.
Для IPv6 примерами соответствующих типов полей в базовом заголовке яв-
ляются поля версии (неизменяемое), адреса получателя (изменяемое, но прогно-
зируемое) и метки потока (изменяемое и обнуляемое для вычислений).
Транспортный и туннельный режимы
На рис. 6.5 показано два варианта использования сервиса аутентификации
IPSec. В первом случае аутентификация выполняется непосредственно между
сервером и рабочими станциями клиентов, причем рабочие станции могут раз-
мещаться как в той же сети, что и сервер, так и во внешней сети. Если рабочие
станции и сервер используют общие защищенные секретные ключи, процесс ау-
тентификации оказывается защищенным. В этом случае применяется транс-
портный режим защищенной связи. Во втором случае аутентификация удален-
ных рабочих станций выполняется корпоративным брандмауэром либо потому,
что требуется доступ ко всей внутренней сети, либо потому, что требуемый сер-
вер просто не имеет средств аутентификации. В такой ситуации используется
туннельный режим защищенной связи.
В этом разделе мы рассмотрим область применения аутентификации АН
и выясним особенности размещения заголовка аутентификации в каждом из
двух режимов. При этом случаи IPv4 и IPv6 несколько различаются. На
Глава 6. Защита IP
217
рис. 6.6, а показана структура типичных пакетов IPv4 и IPv6. В данном
примере полезным грузом IP является сегмент TCP, но это могут быть дан-
ные любого другого использующего IP протокола — например, протокола
UDP или ICMP.
Рис. в.5. Аутентификация между конечными пунктами и аутентификация между
конечным и промежуточным пунктами
Для транспортного режима АН с применением IPv4 данные АН размеща-
ются непосредственно за оригинальным заголовком IP и перед полезным грузом
IP (например сегментом TCP), как показано в верхней части рис. 6.6, б. Аутен-
тификации подлежит весь пакет, за исключением изменяемых полей в заголовке
IPv4, которые при вычислении значения МАС обнуляются.
В контексте IPv6 данные АН рассматриваются как полезный груз сквозной
передачи; т.е. проверка и обработка этих данных промежуточными маршрутиза-
торами не предполагается. Поэтому данные АН размещаются после базового за-
головка IPv6 и заголовков расширений транзита, маршрутизации и фрагмента-
ции. Заголовок расширения параметров адресации может размещаться до или
после заголовка АН — в зависимости от требований семантики. Опять же, ау-
тентификация предполагается для всего пакета, за исключением изменяемых
полей, которые при вычислении значения МАС обнуляются.
Для туннельного режима АН аутентификации подлежит весь оригинальный
пакет IP, а заголовок АН размещается между оригинальным заголовком IP и
новым внешним заголовком IP (рис. 6.6, в). Внутренний заголовок IP несет ад-
реса оригинальных источника и адресата, в то время как внешний заголовок IP
может содержать совершенно другие адреса IP (например, адреса брандмауэров
или других шлюзов защиты).
В туннельном режиме весь внутренний пакет IP, включая весь внутренний
заголовок IP, защищается средствами АН. Внешний заголовок IP защищается с
исключением изменяемых и непрогнозируемых по значению полей (для IPv6 это
касается и внешних заголовков расширений IP).
218
Часть II. Приложения сетевой защиты
IPv6
IPv4
оригинальный заголовок IP TCP Данные
заголовки расширений (если имеются) TCP Данные
а) до применения АН
______ Аутентифицируется за исключением
изменяемых полей “
оригинальный заголовок IP АН TCP Данные
Аутентифицируется за исключением
изменяемых полей
IPv6
оригинальный! транзит,адресация,
заголовок IP маршрутизация,
фрагментация
АН адресация
TCP
Данные
б) транспортный режим
Аутентифицируется за исключением изменяемых полей
в новом заголовке IP
IPv4
новый
заголовок
IP
оригинальный
заголовок]?
TCP
Данные
Аутентифицируется за исключением изменяемых полей
в новом заголовке IP и его заголовках расширений
IPv6
новый
заголовок
IP
заголовки I I оригинальный! заголовки
расширений |АН I заголовок IP (расширений
TCP
Данные
в) туннельный режим
Рис. 6.6. Область применения аутентификации АН
6.4. ЗАЩИЩЕННЫЙ ПОЛЕЗНЫЙ ГРУЗ
Протокол ESP (Encapsulating Security Payload — защищенный или, точнее,
включающий защиту полезный груз) обеспечивает сервис конфиденциальности,
в том числе защиту содержимого сообщения и ограниченную конфиденциаль-
ность транспортного потока. В качестве дополнительной возможности ESP мо-
жет обеспечивать тот же сервис аутентификации, что и АН.
Глава 6. Защита IP
219
Формат ESP
На рис. 6.7 показан формат пакета ESP. Он содержит следующие поля.
• Индекс параметров защиты (32 бит). Идентифицирует защищенную связь.
• Порядковый номер (32 бит). Значение счетчика, используемого для защиты
от атак воспроизведения, как и при использовании протокола АН.
• Полезный груз (переменной длины). Это сегмент транспортного уровня (в
транспортном режиме) или пакет IP (в туннельном режиме), который за-
щищается шифрованием.
® Заполнитель (0—255 байт). Назначение этого поля объясняется ниже.
® Длина заполнителя (8 бит). Указывает число байтов заполнителя, предше-
ствующего данному полю.
• Следующий заголовок (8 бит). Идентифицирует тип данных, содержащихся
в поле данных полезного груза, указывая первый заголовок полезного груза
(заголовок расширения IPv6 или заголовок протокола верхнего уровня, на-
пример TCP).
• Данные аутентификации (переменной длины). Поле переменной длины
(которая должна представлять собой целое число 32-битовых слов), содер-
жащее код ICV (Integrity Check Value — код контроля целостности), вычис-
ляемый для всего пакета ESP без поля данных аутентификации.
16
24
31
S s
= 6*
Л S
0-4)
Бит: 0
Индекс параметров защиты
Порядковый номер
/ -X ' t / \ / X ' / X 'г У \ I х ' ' 1 '
Данный полезного груза (переменной длины)
Г' ' ~.'А " / <
Заполнитель (0-255 бант)
I ’ \ Х . I
! 4 Длина заполнителе
Данные аутентификации (переменной длины)
Следующий \
з^грдово|с /
Рис. 6.7. Формат ESP для IPSec
Шифрование и алгоритмы аутентификации
Сервис ESP предполагает шифрование полей полезного груза, заполнителя,
длины заполнителя и следующего заголовка. Если для алгоритма, используемого
при шифровании полезного груза, требуется криптографическая синхронизация дан-
ных (например, вектор инициализации IV), то необходимые данные могут быть пе-
220
Часть II. Приложения сетевой защиты
ренесены в начало поля полезного груза. При наличии значения IV это значение
обычно не шифруется, хотя часто считается частью шифрованного текста.
Существующие спецификации требуют, чтобы любая реализация поддержи-
вала использование алгоритма DES в режиме СВС (режим сцепления шифрован-
ных блоков, описанный в главе 2). В документации DOI определяется ряд иден-
тификаторов для других алгоритмов, которые, таким образом, тоже могут при-
менятся для шифрования. Среди таких алгоритмов необходимо назвать
следующие:
• “тройной” DES с тремя ключами,
• RC5,
• IDEA,
• “тройной” IDEA с тремя ключами,
• CAST,
• Blowfish.
Все эти алгоритмы были рассмотрены в главе 3.
Как и АН, протокол ESP поддерживает использование значений МАС, дли-
на которых по умолчанию равна 96 бит. Так же, как и для протокола АН, спе-
цификации требуют, чтобы любая реализация поддерживала схемы HMAC-MD5-
96 и HMAC-SHA-1-96.
Использование заполнителя
Поле заполнителя предназначено для следующих целей.
• Если алгоритм шифрования требует, чтобы длина открытого текста была
кратна некоторому целому числу байтов (например, длине одного блока
блочного шифра), поле заполнителя используется для того, чтобы допол-
нить до нужной длины открытый текст (складывающийся из полей полез-
ного груза, заполнителя, длины заполнителя и следующего заголовка).
• Формат ESP требует, чтобы поля длины заполнителя и следующего заго-
ловка выравнивались по правому краю в 32-бйтовом слове. Это эквивалент-
но требованию, чтобы шифрованный текст имел длину, кратную 32 бит.
Поле заполнителя предназначено для осуществления такого выравнивания.
• Заполнение можно использовать и для того, чтобы обеспечить частичную
конфиденциальность транспортного потока путем маскировки информации
об истинной длине полезного груза.
Транспортный и туннельный режимы
На рис 6.8 показано два варианта применения сервиса ESP протокола IPSec.
В верхней части рисунка шифрование (и, как опция, аутентификация) осущест-
вляется непосредственно между двумя узлами. На рис. 6.8, б показано, как ис-
пользовать туннельный режим для построения виртуальной частной сети. В
этом примере предполагается, что некоторая организация имеет четыре частные
сети, связанные через Internet. Узлы внутренних сетей используют Internet для
передачи данных, но не взаимодействуют с другими размещенными в Internet
Глава 6. Защита IP
221
узлами. Поскольку туннели заканчиваются в шлюзах защиты каждой внутрен-
ней сети, такая конфигурация позволяет внутренним узлам этих сетей избежать
необходимости применения механизмов защиты. В первом варианте применяется
транспортный режим защищенной связи, а во втором — туннельный режим.
а) защита на транспортном уровне
б) виртуальная частная сеть, построенная на связях в туннельном режиме
Рис. 6.8. Шифрование в транспортном и туннельном режимах
Мы рассмотрим пределы применения ESP в каждом из этих режимов. В
данном случае ситуации для IPv4 и IPv6 несколько различаются. Как и при ис-
пользовании протокола АН, для описания области действия ESP мы применяем
пакеты в формате, подобном показанному на рис. 6.6, а.
Транспортный режим ESP
Транспортный режим ESP служит для шифрования и, если требуется, ау-
тентификации данных, пересылаемых в пакете IP (например, сегмента TCP, как
показано на рис. 6.9, а). Для этого режима в рамках IPv4 заголовок ESP разме-
щается в пакете IP непосредственно перед заголовком транспортного уровня
(например, TCP, UDP, ICMP), а концевик пакета ESP (содержащий поля запол-
нителя, длины заполнителя и следующего заголовка) — после пакета IP. Если
используется функция аутентификации, то поле данных аутентификации ESP
222
Часть II. Приложения сетевой защиты
добавляется после концевика ESP. Весь сегмент транспортного уровня вместе с
концевиком ESP шифруются. Аутентификация охватывает весь шифрованный
текст и заголовок ESP.
Аутентифицируется
------ Шифруется
а) транспортный режим
4---------- Аутентифицируется ----------►
4------------ Шифруется ------------►
б) туннельный режим
Рис. 6.9. Область действия шифрования и аутентификации ESP
В контексте IPv6 данные ESP рассматриваются как предназначенный для
сквозной пересылки полезный груз, не подлежащий проверке или обработке
промежуточными маршрутизаторами. Поэтому заголовок ESP размещается после
основного заголовка IPv6 и заголовков расширений транзита, маршрутизации и
фрагментации. Заголовок расширения параметров адресата может быть помещен
до или после заголовка ESP — в зависимости от требований семантики. В IPv6
шифрование охватывает весь сегмент транспортного уровня вместе с концевиком
ESP, а также заголовок расширения параметров адресата, если этот заголовок
Глава 6. Защита IP
223
размещается после заголовка ESP. Аутентификация предполагается для шифро-
ванного текста и заголовка ESP.
В транспортном режиме выполняются следующие операции.
1. В узле источника блок данных, состоящий из концевика ESP и всего сег-
мента транспортного уровня, шифруется, и открытый текст этого блока за-
меняется шифрованным текстом, в результате чего формируется пакет IP
для пересылки. Если выбрана опция аутентификации, то добавляется поле
аутентификации.
2. Пакет направляется адресату. Каждый промежуточный маршрутизатор
должен проверить и обработать заголовок IP, а также все заголовки расши-
рений IP, доступные в нешифрованном виде. Шифрованный текст при этом
остается неизменным.
3. Узел адресата проверяет и обрабатывает заголовок IP и все заголовки рас-
ширений IP, доступные в нешифрованном виде. Затем на основе информа-
ции индекса параметров защиты в заголовке ESP дешифруются остальные
части пакета, в результате чего становится доступным сегмент транспортно-
го уровня в виде открытого текста.
Транспортный режим обеспечивает конфиденциальность для любого ис-
пользующего этот режим приложения, что позволяет избежать необходимости
реализации функций защиты в каждом отдельном приложении. Этот режим дос-
таточно эффективен, а объем добавляемых к пакету IP данных при этом неве-
лик. Недостатком этого режима является то, что при его использовании не ис-
ключается возможность анализа трафика пересылаемых пакетов.
Туннельный режим ESP
Туннельный режим ESP предполагает шифрование всего пакета IP
(рис. 6.9, б). В этом режиме заголовок ESP добавляется к пакету как префикс, а
затем пакет вместе с концевиком ESP шифруются. Данный метод можно исполь-
зовать, когда требуется исключить возможность проведения атак, построенных
на анализе трафика.
Поскольку заголовок IP содержит адрес пункта назначения и, возможно,
директивы исходной маршрутизации вместе с информацией о параметрах тран-
зита, нельзя просто передать шифрованный пакет IP с добавленным к нему в
виде префикса заголовком ESP. Промежуточные маршрутизаторы не смогут об-
работать такой пакет. Таким образом, необходимо включить весь блок
(заголовок ESP, шифрованный текст и данные аутентификации, если они есть)
во внешний пакет IP с новым заголовком, который будет содержать достаточно
информации для маршрутизации, но не для анализа трафика.
В то время как транспортный режим подходит для защиты соединений между
узлами, поддерживающими сервис ESP, туннельный режим оказывается полезным в
конфигурации, предполагающей наличие брандмауэра или иного шлюза защиты
внутренней сети от внешних сетей. В туннельном режиме шифрование используется
для обмена только между внешним узлом и шлюзом защиты или между двумя
шлюзами защиты. Это разгружает узлы внутренней сети, избавляя их от необходи-
мости шифрования данных, и упрощает процедуру распределения ключей, умень-
шая число требуемых ключей. Кроме того, такой подход усложняет проблему анали-
за потока сообщений, направляемых конкретному адресату.
224
Часть II. Приложения сетевой защиты
Рассмотрим случай, когда внешний узел соединяется с узлом внутренней
сети, защищенной брандмауэром, и ESP используется внешним узлом и бранд-
мауэром. Тогда при пересылке сегмента транспортного уровня от внешнего узла
к узлу внутренней сети выполняются следующие действия.
1. Источник готовит внутренний пакет IP с указанием адреса пункта назначе-
ния, являющегося узлом внутренней сети. К этому пакету в виде префикса
добавляется заголовок ESP. Затем пакет и концевик ESP шифруются и к
результату могут быть добавлены данные аутентификации. Полученный
блок заключается во внешний пакет IP с новым заголовком IP (базовый за-
головок плюс необязательные расширения, например, параметров маршру-
тизации и транзита для IPv6), в котором адресом пункта назначения явля-
ется адрес брандмауэра.
2. Внешний пакет отправляется брандмауэру. Каждый промежуточный мар-
шрутизатор должен проверить и обработать внешний заголовок IP и все
внешние заголовки расширений IP, оставляя при этом шифрованный текст
неизменным.
3. Брандмауэр-адресат проверяет и обрабатывает внешний заголовок IP и все
внешние заголовки расширений IP. Затем на основе информации, предос-
тавляемой индексом параметров защиты в заголовке ESP, брандмауэр де-
шифрует остальные части пакета, в результате чего становится доступным
внутренний пакет IP в виде открытого текста. Этот пакет потом передается
по внутренней сети.
4. Внутренний пакет передается маршрутизатору внутренней сети или непо-
средственно узлу-адресату.
6.5. КОМБИНАЦИИ ЗАЩИЩЕННЫХ СВЯЗЕЙ
Отдельная защищенная связь может использовать либо протокол АН, либо
ESP, но никак не оба эти протокола одновременно. Тем не менее, иногда кон-
кретному потоку данных может требоваться и сервис АН, и сервис ESP. Кроме
того, конкретному потоку данных может понадобиться сервис IPSec для связи
между узлами и другой сервис для связи между шлюзами защиты, например
брандмауэрами. Во всех этих случаях одному потоку для получения всего ком-
плекса услуг IPSec требуется несколько защищенных связей. Здесь полезным
оказывается понятие пучка защищенных связей (security association bundle),
обозначающее набор защищенных связей, посредством которых потоку должен
предоставляться необходимый набор услуг IPSec. При этом защищенные связи в
пучке могут завершаться в различных конечных точках.
Защищенные связи могут быть объединены в пучки следующими двумя
способами.
• Транспортная смежность. Применение нескольких протоколов защиты к
одному пакету IP без создания туннеля. Этот подход к созданию комбина-
ции АН и ESP оказывается эффективным только для одного уровня вложе-
ния: дальнейшие вложения не дают дополнительного выигрыша, поскольку
обработка выполняется в одной инстанции — IPsec (конечного) получателя.
Глава 6. Защита IP
225
• Повторное туннелирование. Применение нескольких уровней протоколов
защиты с помощью туннелирования IP. Этот подход допускает множество
уровней вложения, поскольку туннели могут начинаться и завершаться в
разных использующих IPsec узлах сети вдоль маршрута передачи данных.
Эти два подхода можно и объединить (например, организовав в части туннель-
ной защищенной связи между шлюзами защиты транспортную защищенную
связь между находящимися на пути узлами).
Интересным вопросом, возникающим при рассмотрении пучков защищенных
связей, является вопрос о роли порядка, в котором могут применяться аутентифика-
ция и шифрование между данной парой конечных узлов, и роли способов осуществ-
ления этих операций. Мы обсудим сначала этот вопрос, а затем рассмотрим комби-
нации защищенных связей, использующие, по крайней мере, один туннель.
Аутентификация плюс конфиденциальность
Шифрование и аутентификация могут комбинироваться для того, чтобы
обеспечить передаваемому пакету IP как конфиденциальность, так и аутентифи-
кацию. Мы рассмотрим несколько подходов к такому комбинированию.
ESP с опцией аутентификации
Этот подход иллюстрируется на рис. 6.9. Пользователь сначала применяет ESP
к требующим защиты данным, а затем добавляет поле данных аутентификации. На
самом деле в этом случае можно выделить следующие две возможности.
• Транспортный режим ESP. Аутентификация и шифрование применяются к
полезному грузу IP, доставляемому узлу адресата, но при этом заголовок IP
не защищается.
• Туннельный режим ESP. Аутентификация применяется ко всему пакету IP,
доставляемому по адресу IP внешнего получателя (например брандмауэра),
и аутентификация выполняется этим получателем. Весь внутренний пакет
IP защищается механизмом секретности, поскольку предназначен для дос-
тавки внутреннему адресату IP.
В обоих случаях аутентификации подлежит шифрованный, а не открытый текст.
Транспортная смежность
Другим способом применения аутентификации после шифрования явля-
ется использование пучка из двух защищенных связей в транспортном ре-
жиме, где внутренняя связь является защищенной связью ESP, а внешняя —
защищенной связью АН. В этом случае ESP используется без опции аутен-
тификации. Поскольку внутренняя защищенная связь используется в транс-
портном режиме, шифрованию подлежит полезный груз IP. Получаемый в
результате пакет состоит из заголовка IP (и, возможно, заголовков расшире-
ний IPv6), за которым следуют данные ESP. Затем применяется АН в транс-
портном режиме, так что аутентификация будет охватывать данные ESP и
оригинальный заголовок IP (а также расширения), за исключением изменяе-
мых полей. Преимущество этого подхода в сравнении с простым использова-
нием защищенной связи ESP с опцией аутентификации заключается в том,
что при комбинированном подходе аутентификация охватывает больше по-
226
Часть II. Приложения сетевой защиты
лей, включая поля адресов IP источника и адресата. Недостаток связан с ис-
пользованием двух защищенных связей вместо одной.
Транспортно-туннельный пучок
Использование функций аутентификации до шифрования может оказаться
более предпочтительным по нескольким причинам. Во-первых, поскольку дан-
ные аутентификации будут защищены шифрованием, никто посторонний не
сможет, перехватив сообщение, тайно изменить данные аутентификации. Во-
вторых, если необходимо хранить информацию аутентификации вместе с сооб-
щением в системе адресата, то удобнее аутентифицировать открытое сообщение.
Иначе для повторной аутентификации сообщение придется повторно шифровать.
Вариантом применения аутентификации до шифрования при обмене дан-
ными между двумя узлами является использование пучка защищенных связей,
состоящего из внутренней защищенной транспортной связи АН и внешней за-
щищенной туннельной связи ESP. В этом случае аутентификация охватывает
полезный груз IP вместе с заголовком IP (и расширениями), за исключением из-
меняемых полей. Полученный таким образом пакет IP затем обрабатывается в
туннельном режиме ESP, в результате чего внутренний пакет вместе с данными
аутентификации оказывается зашифрованным и имеющим новый внешний заго-
ловок IP (с необходимыми расширениями).
Основные типы комбинаций защищенных связей
В документе, описывающем архитектуру IPSec, приведено четыре примера
комбинации защищенных связей, которые должны поддерживаться использую-
щими IPSec узлами (рабочими станциями, серверами) или шлюзами защиты
(брандмауэрами, маршрутизаторами). Эти примеры иллюстрируются на
рис. 6.10. В нижней части иллюстраций для каждого случая представлены схе-
мы физического соединения элементов, а в верхней части — схемы логического
связывания с помощью одного или нескольких вложенных защищенных связей.
Каждая защищенная связь может быть либо связью АН, либо ESP. Для защи-
щенных связей между узлами используется транспортный либо туннельный ре-
жим, в других случаях — только туннельный.
Вариант 1 обеспечивает защиту связи между конечными системами, ис-
пользующими IPSec. Две конечные системы, сообщающиеся через защищенную
связь, должны использовать общие секретные ключи. При этом допустимы сле-
дующие комбинации.
а) АН в транспортном режиме;
б) ESP в транспортном режиме;
в) сначала АН, а затем ESP в транспортном режиме (защищенная связь
АН, вложенная в защищенную связь ESP);
г) любая из связей, указанных в пп. а, б и в, внутри АН или ESP в тун-
нельном режиме.
Мы уже выяснили, как эти различные комбинации могут использоваться
для поддержки аутентификации, шифрования, аутентификации перед шифрова-
нием и после него.
Глава 6. Защита IP
227
а) вариант 1
в) вариант 3
Туннельная защищенная
связь
б) вариант 2
• — предполагается использование iPSec
Рис. 6.10. Основные типы комбинаций защищенных связей
Туннельная защищенная Одна или две
связь защищенные
г) вариант 4
Вариант 2 обеспечивает защиту только между шлюзами (маршрутизаторами,
брандмауэрами и т.п.), а в конечных узлах применение IPSec не предполагается.
Эта ситуация иллюстрирует поддержку простой виртуальной частной сети. В до-
кументе, описывающем архитектуру защиты, говорится о том, что в подобной си-
туации требуется только одна туннельная защищенная связь. Туннель может ис-
пользовать АН, ESP или ESP с опцией аутентификации. Вложенные туннели не
нужны, поскольку сервис IPSec обращается ко всему внутреннему пакету.
Вариант 3 использует схему варианта 2 с добавлением сквозной защиты.
При этом допустимыми являются те же комбинации, которые уже были описа-
ны выше для вариантов 1 и 2. Туннель от шлюза к шлюзу обеспечивает аутен-
тификацию и/или конфиденциальность для всего трафика между конечными
системами. Когда туннель от шлюза к шлюзу использует ESP, обеспечивается и
ограниченная конфиденциальность потока обмена данными. Конечные системы
могут при этом обращаться к дополнительным сервисам IPSec, необходимым для
конкретных приложений или отдельных пользователей, используя для этого
сквозные защищенные связи.
Вариант 4 иллюстрирует поддержку удаленного узла, использующего
Internet для связи с брандмауэром организации с целью получения доступа к
серверу или рабочей станции за этим брандмауэром. Между удаленным узлом и
брандмауэром необходимо использовать только туннельный режим. Как и при
228
Часть II. Приложения сетевой защиты
варианте 1, между удаленным и локальным узлами можно использовать одну
или две защищенные связи.
6.6. УПРАВЛЕНИЕ КЛЮЧАМИ
Функции управления ключами IPSec предполагают определение и распре-
деление секретных ключей. Обычно для защищенной связи между двумя при-
ложениями требуется четыре ключа: по паре ключей передачи и получения дан-
ных для АН и ESP. В документе, описывающем архитектуру IPSec, говорится о
поддержке следующих двух типов управления ключами.
• Ручное. Системный администратор вручную конфигурирует каждую систе-
му с указанием ее ключей и ключей других сообщающихся систем. Это
вполне приемлемо для малых и относительно статичных сред.
• Автоматизированное. Автоматизированная система обеспечивает возмож-
ность создания ключей для защищенных связей по запросу и упрощает
проблему использования ключей в большой распределенной системе с часто
меняющейся конфигурацией.
Применяемый по умолчанию для IPSec протокол автоматизированного управ-
ления ключами называется ISAKMP/Oakley и состоит из следующих элементов.
• Протокол определения ключей Oakley. Oakley представляет собой протокол об-
мена ключами, основанный на алгоритме Диффи-Хеллмана, но обеспечиваю-
щий дополнительную защиту. Протокол Oakley оказывается общим в том
смысле, что он не диктует использования каких-то конкретных форматов.
• Протокол защищенных связей и управления ключами в Internet (Internet
Security Association and Key Management Protocol — ISAKMP). ISAKMP
обеспечивает каркас схемы управления ключами в Internet и поддержку
специального протокола и необходимых форматов процедуры согласования
атрибутов защиты.
ISAKMP не заставляет использовать какой-то конкретный алгоритм обмена
ключами, а предлагает набор типов сообщений, позволяющих задействовать лю-
бой подобный алгоритм. Oakley является конкретным алгоритмом обмена клю-
чами, предназначенным для использования с исходной версией ISAKMP.
Мы начнем с краткого обсуждения Oakley, а затем рассмотрим ISAKMP.
Протокол Oakley
Oakley представляет собой вариант обмена ключами, выполняемый по усо-
вершенствованной схеме Диффи-Хеллмана. Напомним, что алгоритм Диффи-
Хеллмана предлагает следующее взаимодействие между пользователями А и В.
Предполагается предварительное соглашение о двух глобальных параметрах: q,
представляющем собой достаточно большое простое число, и а, являющемся
первообразным корнем q. Сторона А выбирает случайное целое число ХА , кото-
рое будет личным ключом А, и передает стороне В открытый ключ УА=аХл.
Точно так же В выбирает случайное целое число Хв , которое будет личным
Глава 6. Защита IP
229
ключом В, и передает стороне А открытый ключ Ув=аЛв. Каждая из сторон
может теперь вычислить секретный сеансовый ключ по формуле
К = (rB)%Amod^ = (rA)XBmod^ = иХаХв mod q .
Алгоритм Диффи-Хеллмана имеет два привлекательных свойства.
• Секретные ключи создаются только тогда, когда это нужно. Нет необходи-
мости хранить секретные ключи в течение длительного периода времени,
делая их тем самым более уязвимыми.
• Процедура обмена не требует никакой специальной подготовки, кроме со-
глашения о значениях глобальных параметров.
Однако, как указано в [HUIT98], алгоритм Диффи-Хеллмана не лишен и недос-
татков.
• Алгоритм не предлагает никакой информации, позволяющей идентифици-
ровать стороны.
• Алгоритм уязвим в отношении атак с использованием посредника, когда неко-
торая третья сторона С выступает от имени В для А и от имени А для В. В этом
случае как А, так и В ведут переговоры о ключе со стороной С, которая затем
сможет принимать и отправлять дальше весь поток обмена данными между А и
В. Сценарий такой атаки может выглядеть следующим образом.
• Сторона В посылает свой открытый ключ Ув в сообщении, адресуемом
стороне А (см. рис. 3.11 в главе 3).
• Противник (Е) перехватывает это сообщение, сохраняет открытый ключ
В и посылает стороне А сообщение, содержащее идентификатор В и от-
крытый ключ YE стороны Е. Это сообщение посылается таким образом,
чтобы казалось, что оно было отправлено узлом В. Сторона А получает
сообщение Е и сохраняет открытый ключ Е с идентификатором В. Точно
так же Е посылает сообщение стороне В с открытым ключом Е, имитируя
его отправку с узла А.
• Сторона В вычисляет секретный ключ К{ на основе личного ключа В и
Ye . Сторона А вычисляет секретный ключ К2 на основе ключа А и YE .
Сторона Е вычисляет Кх, используя личный ключ ХЕ и Ув , и К2 , ис-
пользуя ХЕ и УА .
• С этого момента сторона Е может ретранслировать сообщения от А к В и
от В к А, меняя по пути их шифрованный вид так, что ни А, ни В не бу-
дут знать о том, что на самом деле они используют связь с Е.
• Алгоритм требует интенсивных вычислений. В результате он оказывается
уязвимым в отношении атак засорения, когда противник запрашивает
очень большое число ключей. В итоге жертва тратит значительную долю
вычислительных ресурсов на бесполезные возведения в степень в арифмети-
ке классов вычетов.
Oakley разработан как раз для того, чтобы, сохранив преимущества алго-
ритма Диффи-Хеллмана, избавиться от выявленных у последнего недостатков.
230
Часть II. Приложения сетевой защиты
Свойства Oakley
Алгоритм Oakley характеризуется следующими пятью важными особенностями.
1. Использует механизм так называемых рецептов (cookies'), чтобы противо-
стоять атакам засорения.
2. Позволяет двум сторонам договорится о группе, которая, по существу, опреде-
ляет глобальные параметры алгоритма обмена ключами Диффи-Хеллмана.
3. Использует оказии, чтобы противостоять атакам воспроизведения сообщений.
4. Осуществляет обмен значениями открытых ключей Диффи-Хеллмана.
5. Выполняет аутентификацию обмена Диффи-Хеллмана, чтобы противостоять
атакам посредника.
Мы уже обсуждали алгоритм Диффи-Хеллмана. Давайте рассмотрим оставшие-
ся элементы списка. Сначала разберемся с проблемой атак засорения. При этой атаке
противник фальсифицирует адрес законного источника и посылает жертве открытый
ключ Диффи-Хеллмана. Жертва выполняет модульное возведение в степень в ариф-
метике классов вычетов, чтобы вычислить секретный ключ. Многократно повторен-
ные сообщения такого типа могут засорить систему атакуемой стороны бесполезной
работой. Требование обмена рецептами означает, что каждая из сторон должна по-
слать в начальном сообщении псевдослучайное число, рецепт, который другая сто-
рона должна подтвердить. Это подтверждение должно повториться в первом сообще-
нии обмена ключами по Диффи-Хеллману. Если адрес источника был фальсифици-
рован, противник ответа не получит. Таким образом, противник сможет заставить
пользователя генерировать подтверждения, а не выполнять вычисления с использо-
ванием алгоритма Диффи-Хеллмана.
ISAKMP требует, чтобы процедура генерирования рецептов удовлетворяла
следующим трем основным требованиям.
1. Рецепт должен зависеть от параметров генерирующей его стороны. Это не
даст возможности противнику получить рецепт с помощью реальных адреса
IP и порта UDP, а затем использовать этот рецепт для того, чтобы забросать
жертву запросами с выбранных случайным образом адресов IP или портов.
2. Генерировать рецепты, которые будут признаны данным объектом, должен
иметь возможность только генерирующий объект. Отсюда следует, что гене-
рирующий объект должен использовать при создании и последующей вери-
фикации рецептов локальную секретную информацию. Эту информацию
должно быть невозможно извлечь из какого бы то ни было отдельного ре-
цепта. Смысл этого требования заключается в том, чтобы генерирующему
объекту не приходилось хранить копии рецептов, которые таким образом
становятся более уязвимыми, и можно было проверить поступающий с под-
тверждением рецепт тогда, когда это потребуется.
3. Генерирование рецептов и их верификация должны выполняться быстро,
чтобы не допустить проведения атак, направленных на блокирование ресур-
сов системы.
Рекомендуемый метод создания рецептов заключается в быстром вычисле-
нии хэш-кода (например MD5) для адресов IP источника и адресата, портов UDP
источника и адресата и локально генерируемого секретного значения.
Глава 6. Защита IP
231
Алгоритм Oakley поддерживает использование различных групп для об-
мена ключами Диффи-Хеллмана. В каждой группе определяются два гло-
бальных параметра и алгоритм. Имеющиеся сегодня спецификации опреде-
ляют следующие группы.
• Возведение в степень в арифметике классов вычетов с 768-битовым модулем:
q = 2768 - 2704 -l + 2Mx^2638 X7tj + 149686 j,
а = 2.
• Возведение в степень в арифметике классов вычетов с 1024-битовым модулем:
q = 21024 - 2960 -i + 264x^2894xrcj +129093),
а = 2.
• Возведение в степень в арифметике классов вычетов с 1024-битовым модулем.
• Параметры должны определяться.
• Группа эллиптической кривой над конечным полем из 2155 элементов.
• Генератор (в шестнадцатеричном виде): X = 7В, Y = 1С8.
• Параметры эллиптической кривой (в шестнадцатеричном виде): А = О,
Y = 7338F.
• Группа эллиптической кривой над конечным полем из 2185 элементов.
• Генератор (в шестнадцатеричном виде): Х= 18, Y = D.
• Параметры эллиптической кривой (в шестнадцатеричном виде): А = О,
Y = 1ЕЕ9.
Первые три группы представляют классический алгоритм Диффи-
Хеллмана, в котором происходит возведение в степень в арифметике классов
вычетов. Последние две группы используют аналог алгоритма Диффи-Хеллмана
для эллиптических кривых.
В алгоритме Oakley для защиты от атак воспроизведения сообщений приме-
няются оказии. Каждая оказия представляет собой локально порожденное псев-
дослучайное число. Оказии появляются в ответах и шифруются на определенных
стадиях обмена данными, чтобы защитить их при использовании.
С алгоритмом Oakley могут применяться три различных метода аутен-
тификации.
• Цифровые подписи. Аутентификация обмена данными осуществляется с
помощью подписи доступного обеим сторонам хэш-кода: каждая сторона
шифрует хэш-код своим личным ключом. Такой хэш-код генерируется для
каких-нибудь важных параметров, например, идентификаторов пользовате-
лей и оказий.
• Шифрование с открытым ключом. Аутентификация обмена данными осущест-
вляется с помощью шифрования некоторых параметров обмена (например,
идентификаторов и оказий) с использованием личного ключа отправителя.
232
Часть II. Приложения сетевой защиты
• Шифрование с симметричным ключом. Для аутентификации обмена дан-
ными может использоваться шифрование параметров обмена по симметрич-
ной схеме с помощью некоторого ключа, получаемого с применением како-
го-то дополнительного механизма.
Пример обмена Oakley
Спецификации Oakley включают ряд примеров обмена, допустимых для
энного протокола. Чтобы получить представление о работе Oakley, рассмотрим
1ин пример обмена данными, который в документе с описаниями специфика-
ий называется энергичным обменом ключами (aggressive key exchange). Назва-
ие объясняется тем, что при этом требуется обмен только тремя сообщениями.
На рис. 6.11 показана схема протокола энергичного обмена ключами. На
ервом шаге инициатор I передает рецепт, группу, которую предполагается ис-
:ользовать, и свой открытый ключ Диффи-Хеллмана для данного обмена. Кроме
ого, сторона I указывает алгоритмы шифрования с открытым ключом, хэширо-
1ания и аутентификации, которые предлагает использовать в ходе этого обмена.
£ще в сообщение включаются идентификаторы инициатора I и респондента R, а
?акже оказия инициатора I для этого обмена. Наконец, сторона I присоединяет к
юобщению подпись (построенную с помощью личного ключа I), охватывающую
зва идентификатора, оказию, группу, открытый ключ Диффи-Хеллмана и пред-
лагаемые алгоритмы.
I R: CKYi, OK_KEYX, GRP, gx, EHAO, NIDP, IDb IDr, Nb SKi[IDi II IDr II N{ II GRP II gx II EHAO]
R -»I: CKYr. CKYi, OK_KEYX, GRP, gX. EHAS, NIDP, IDr. IDj, Nr, N], SKr[IDr II ID] II Nr II Nj II GRP II gX II g* II EHAS]
I -> R: CKY;, CKYr, OK.KEYX, GRP, g\ EHAS, NIDP, IDb IDr, Nb Nr, SKj[IDl II IDr II Nj II Nr II GRP II gx II gX II EHAS]
Обозначения:
I — инициатор;
R — респондент;
CKY], CKYr — рецепты инициатора и респондента;
OK_KEYX — тип сообщения обмена ключами;
GRP — имя группы Диффи-Хеллмана для этого обмена;
gx. gX — открытые ключи инициатора и респондента; gxX — сеансовый ключ для этого обмена;
EHAO, EHAS — функции шифрования, хэширования, аутентификации, предложенные и выбранные;
NIDP — оставшаяся часть сообщения шифрованию не подлежит;
ID], IDr — идентификаторы инициатора и респондента;
N], Nr — случайные оказии инициатора и респондента для этого обмена;
8к|[Х], SKR[X] — подпись для X, использующая личный ключ (ключ подписи) инициатора, респондента.
Рис. 6.11. Пример энергичного обмена ключами Oakley
Получив сообщение, сторона R проверяет подпись, используя открытый
ключ подписи I. Затем R подтверждает сообщение, отсылая назад рецепт, иден-
тификатор и оказию I, а также группу. Кроме того, R также включает в сообще-
ние рецепт, свой открытый ключ Диффи-Хеллмана, выбранные алгоритмы (из
числа предложенных), идентификатор R и оказию R для этого обмена. Наконец
R присоединяет подпись, используя личный ключ R, которая подписывает два
идентификатора, две оказии, группу, два открытых ключа Диффи-Хеллмана и
выбранные алгоритмы.
Получив второе сообщение, инициатор I проверяет подпись, используя откры-
тый ключ R. Значения оказий в сообщении убеждают в том, что это не воспроизве-
Глава 6. Защита IP
233
дение старого сообщения. Чтобы завершить обмен, инициатор I должен отослать со-
общение назад R для подтверждения того, что I получил открытый ключ R.
Протокол ISAKMP
Протокол ISAKMP определяет процедуры и форматы пакета, используемые
для переговоров о создании, изменении или удалении защищенных связей. Как
часть процесса создания защищенной связи, ISAKMP определяет полезный груз
сообщений обмена ключами и аутентификации данных. Форматы полезного гру-
за обеспечивают согласованный каркас, не зависящий от конкретного протокола
обмена ключами, алгоритма шифрования или механизма аутентификации.
Формат заголовка ISAKMP
Сообщение ISAKMP состоит из заголовка ISAKMP и следующих за ним по-
лезных грузов. Все это передается с помощью транспортного протокола. Специ-
фикации требуют, чтобы любая реализация поддерживала использование UDP.
На рис. 6.12, а показан формат заголовка сообщения ISAKMP, формируе-
мого из следующих полей.
• Рецепт инициатора (64 бит). Рецепт объекта, инициировавшего процесс
создания, изменения или удаления защищенной связи.
• Рецепт респондента (64 бит). Рецепт отвечающего объекта; в первом сооб-
щении инициатора остается пустым.
• Следующий полезный груз (8 бит). Указывает тип первого полезного груза
в сообщении. (Типы полезного груза описаны в следующем разделе.)
• Главный номер версии (4 бит). Указывает главный номер используемой
версии ISAKMP.
• Дополнительный номер версии (4 бит). Указывает дополнительный номер
используемой версии.
• Тип обмена (8 бит). Указывает тип обмена. (Типы обмена рассмотрены ниже.)
• Флаги (8 бит). Указывают параметры, установленные для данного обмена
ISAKMP. Пока что определено два бита. Бит шифрования устанавливается
тогда, когда все имеющиеся полезные грузы, следующие за заголовком, за-
шифрованы с использованием алгоритма шифрования этой защищенной
связи. Бит фиксации предназначен для того, чтобы гарантировать, что
шифрованный материал не был получен до создания защищенной связи.
• Идентификатор сообщения (32 бит). Уникальный идентификатор данного
сообщения.
• Длина (32 бит). Длина всего сообщения (заголовка и всех полезных грузов)
в байтах.
Типы полезного груза ISAKMP
Все полезные грузы ISAKMP имеют заголовки одного типа. Структура тако-
го заголовка показана на рис. 6.12, б. Поле следующего полезного груза имеет
значение 0, если данный полезный груз является в сообщении последним, иначе
значением поля будет тип следующего полезного груза. Значение поля длины
234
Часть II. Приложения сетевой защиты
полезного груза указывает длину в байтах соответствующего полезного груза,
включая длину его заголовка.
Бит: j 8 16 31
nSu®rfv3 ЗАРЕЗЕРВИРОВАНО Длина полезного груза
б) заголовок типичного полезного груза
Рис. 6.12. Форматы ISAKMP
В табл. 6.3 приведен список типов полезного груза, допустимых для
ISAKMP, и указаны поля, или параметры, составляющие полезный груз каж-
дого из этих типов. Полезный груз типа SA (защищенная связь) служит для
того, чтобы начать процесс создания защищенной связи. В этом случае пара-
метр Domain of Interpretation идентифицирует область интерпретации (DOI), в
рамках которой выполняется согласование. Использование DOI протокола
IPSec является лишь одним примером, ISAKMP может использоваться и в дру-
гих контекстах. Параметр Situation (ситуация) определяет политику защиты
для процесса согласования, устанавливая степени защиты (например, гриф
секретности, уровень безопасности).
Полезный груз типа Р (предложение) включает информацию, используе-
мую в ходе согласования атрибутов создаваемой защищенной связи, а также
указывает протокол для этой защищенной связи (ESP или АН), в отношении
которой ведутся переговоры о соответствующих сервисах и механизмах. Кроме
того, полезный груз этого типа включает индекс параметров защиты объекта-
отправителя и число трансформаций. Каждая трансформация содержится в
полезном грузе типа Т (трансформация). Применение нескольких полезных
грузов типа трансформации позволяет инициатору предложить на выбор не-
сколько возможностей, из которых отвечающая сторона должна выбрать одну
или отвергнуть предложение.
Глава 6. Защита IP
235
Таблица 6.3. Типы полезного груза ISAKMP
Тип Параметры Описание
Защищенная связь (SA) Область интерпретации, си- туация Используется для согласования атрибутов защиты и указания области интерпретации и си- туации, в рамках которых вы- полняется такое согласование
Предложение (Р) Номер предложения, иденти- фикатор протокола, длина ин- декса параметров защиты, чис- ло трансформаций, индекс па- раметров защиты Используется в ходе согласо- вания параметров создавае- мой защищенной связи, ука- зывает применяемый прото- кол и число трансформаций
Трансформация (Т) Номер трансформации, иден- тификатор трансформации, ат- рибуты защищенной связи Применяется в ходе согласо- вания параметров защищен- ной связи, указывает преоб- разование и соответствующие атрибуты защищенной связи
Обмен ключами (КЕ) Данные обмена ключами Поддерживает целый ряд ме- тодов обмена ключами
Идентификация (ID) Тип идентификации, данные идентификации Предназначен для обмена ин- формацией идентификации
Сертификат (CERT) Кодировка сертификата, дан- ные сертификации Служит для пересылки серти- фикатов и другой связанной с сертификатами информации
Запрос сертификата (CR) Число типов сертификатов, ти- пы сертификатов, число типов центров сертификации, центры сертификации Используется для запросов сертификатов, указывает ти- пы запрашиваемых сертифи- катов и приемлемые центры сертификации
Хэширование (HASH) Данные хэширования Содержит данные, генерируе- мые функцией хэширования
Подпись (SIG) Данные подписи Содержит данные, генери- руемые функцией цифровой подписи
Оказия (NONCE) Данные оказии Содержит оказию
Уведомление (N) Область идентификации, иден- тификатор протокола, длина ин- декса параметров защиты, тип уведомления, индекс параметров защиты, данные уведомления Используется для передачи данных уведомления, напри- мер, признака возникновения ошибки
Удаление (D) Область идентификации, иден- тификатор протокола, длина индекса параметров защиты, число индексов параметров за- щиты, индекс параметров за- щиты (один или несколько) Указывает защищенную связь, которая больше не является действительной
236
Часть II. Приложения сетевой защиты
Полезный груз типа Т (трансформация) определяет защитную трансформацию,
которая должна использоваться для защиты коммуникационного канала в соответ-
ствии с указанным протоколом. Параметр Transform # (номер трансформации) по-
зволяет идентифицировать данный полезный груз, чтобы отвечающая сторона могла
сослаться на этот номер в подтверждение своего решения использовать именно эту
трансформацию. Поля Transform ID (идентификатор трансформации) и Attributes
(атрибуты) определяют трансформацию (например, 3DES для ESP или HMAC-SHA-1-
96 для АН) и связанные с ней параметры (например, длину хэш-кода).
Полезный груз типа КЕ (обмен ключами) может использоваться для целого
ряда методов обмена ключами, среди которых Oakley, обмен по Диффи-
Хеллману и обмен ключами RSA, предусмотренный в PGP. Поле Key Exchange
data (данные обмена ключами) содержит данные, необходимые для создания се-
ансового ключа и зависящие от используемого алгоритма обмена ключами.
Полезный груз типа ID (идентификация) предназначен для идентификации
связывающихся сторон и может использоваться для проверки аутентичности
информации. Как правило, поле ID Data (данные идентификации) содержит ад-
рес IPv4 или IPv6.
Полезный груз типа CERT (сертификат) несет сертификат открытого ключа.
Поле Certificate Encoding (кодировка сертификата) указывает тип сертификата или
связанную с сертификатом информацию, которая может обозначать следующее:
• сертификат Х.509 в упаковке KCS #7;
• сертификат PGP;
• подписанный ключ DNS;
• сертификат Х.509 — подпись;
• сертификат Х.509 — обмен ключами;
• мандаты Kerberos;
• список отозванных сертификатов (CRL);
• список отозванных полномочий (ARL);
• сертификат SPKI.
В любой точке обмена ISAKMP отправитель может разместить полезный
груз типа CR (запрос сертификата), чтобы запросить сертификат второй из уча-
ствующих в обмене сторон. Этот полезный груз может содержать список не-
скольких типов сертификатов и нескольких центров сертификации, которые
рассматриваются как приемлемые.
Полезный груз типа HASH (хэширование) содержит данные, генерируемые
функцией хэширования для некоторой части сообщения и/или состояния
ISAKMP. С помощью этого полезного груза можно проверить целостность дан-
ных в сообщении или аутентифицировать объекты, ведущие переговоры.
Полезный груз типа SIG (подпись) содержит данные, генерируемые функ-
цией цифровой подписи для некоторой части сообщения и/или состояния
ISAKMP. Этот полезный груз служит для проверки целостности данных в сооб-
щении и может использоваться в рамках сервиса, гарантирующего невозмож-
ность отказа от ответственности.
Полезный груз типа NONCE (оказия) включает случайные данные, обеспе-
чивающие гарантию выполнения процесса обмена в реальном времени и защиту
его от атак воспроизведения сообщений.
Глава 6. Защита IP
237
Полезный груз типа N (уведомление) содержит информацию или об ошиб-
ке, или о состоянии, связываемом с данной защищенной связью и данным про-
цессом согласования параметров защищенной связи. Определены следующие со-
общения ISAKMP об ошибках.
Invalid Payload Туре (неправильный тип полезного груза).
DOI Not Supported (неподдерживаемая область интерпретации).
Situation Not Supported (неподдерживаемая ситуация).
Invalid Cookie (неправильный рецепт).
Invalid Major Version (неправильный главный номер версии).
Invalid Minor Version (неправильный дополнительный номер версии).
Invalid Exchange Туре (неправильный тип обмена).
Invalid Flags (неправильные флаги).
Invalid Message ID (неправильный идентификатор сообщения).
Invalid Protocol ID (неправильный идентификатор протокола).
Invalid SPI (неправильный индекс параметров защиты).
Invalid Transform ID (неправильный идентификатор трансформации).
Attributes Not Supported (атрибуты не поддерживаются).
No Proposal Chosen (не выбрано никакого предложения).
Bad Proposal Syntax (неправильный синтаксис предложения).
Payload Malformed (неправильно сформированный полезный груз).
Invalid Key Information (неправильная информация о ключе).
Invalid Cert Encoding (неправильная кодировка сертификата).
Invalid Certificate (неправильный сертификат).
Bad Cert Request Syntax (неправильный синтаксис запроса сертификата).
Invalid Cert Authority (неправильный центр сертификации).
Invalid Hash Information (неправильная информация хэширования).
Authentication Failed (неудачно завершившаяся аутентификация).
Invalid Signature (неправильная подпись).
Address Notification (уведомление об адресе).
Единственным до сих пор определенным сообщением состояния ISAKMP
является состояние Connected (соединено). В дополнение к указанным сообще-
ниям уведомления ISAKMP используются специальные уведомления DOI. Для
IPSec определяются следующие дополнительные сообщения о состоянии.
• Responder-Lifetime. Продолжительность жизни защищенной связи, выбран-
ная отвечающей стороной.
• Replay-Status. Подтверждает положительное решение отвечающей стороны
по вопросу о применении средств обнаружения атак воспроизведения.
• Initial-Contact. Информирует другую сторону о том, что данная защи-
щенная связь является первой, создаваемой с удаленной системой. По-
лучатель такого уведомления может удалить все существующие защи-
щенные связи с системой-отправителем, предполагая, что система от-
правителя была перезагружена и больше не имеет доступа к старым
защищенным связям.
Полезный груз типа D (удаление) указывает одну или несколько защищен-
ных связей, которые предполагаются недействительными ввиду того, что отпра-
витель удалил их из своей базы данных.
238
Часть II. Приложения сетевой защиты
Обмен ISAKMP
Протокол ISAKMP обеспечивает каркас для обмена сообщениями, строи-
тельными блоками которых служат полезные грузы. Спецификации указывают
пять типов обмена, которые должны поддерживаться по умолчанию (табл. 6.4).
В таблице SA означает полезный груз защищенной связи с соответствующими
полезными грузами протокола и трансформации.
Таблица 6.4. Типы обмена ISAKMP
Сообщения обмена
Комментарий
а) базовый обмен
(1) I- >R: SA , NONCE Начинается согласование защищенной связи ISAKMP
(2) R- SA, NONCE Основные параметры защищенной связи согласованы
(3) I- >R: KE, ID, , AUTH Ключ сгенерирован, отвечающая сторона идентифициро- вала инициатора
(4) R- KE, IDr , AUTH Инициатор идентифицировал отвечающую сторону, ключ сгенерирован, защищенная связь установлена
б) обмен с защитой идентификации сторон
(1) I-) R: SA Начинается согласование защищенной связи ISAKMP
(2) R- >1: SA Основные параметры защищенной связи согласованы
(3) 1-> R: KE, NONCE Ключ сгенерирован
(4) R- >1: KE, NONCE Ключ сгенерирован
(5Р * R —>1: ID], AUTH Отвечающая сторона идентифицировала инициатора
(6Г * I- -»R: IDR , AUTH Инициатор идентифицировал отвечающую сторону, защи- щенная связь установлена в) обмен только данными аутентификации
(1) I ; • R: SA, NONCE Начинается согласование защищенной связи ISAKMP
(2) R- >1: SA, NONCE, IDr , AUTH Основные параметры защищенной связи согла- сованы, отвечающая сторона идентифицировала инициатора
(3) 1-э R: ID], AUTH Инициатор идентифицировал отвечающую сто- рону, защищенная связь установлена г) энергичный обмен
(1) 1—3 • R: SA , KE , NONCE , ID] Начинается согласование защищенной связи
и обмен ключами ISAKMP
(2) R-->I : SA , KE , NONCE , IDR , AUTH Отвечающая сторона идентифицировала ини-
циатора, ключ сгенерирован, основные пара-
метры защищенной связи согласованы
(3)* I—>R: AUTH Инициатор идентифицировал отвечающую сторону, защищенная
связь установлена
Глава 6. Защита IP
239
Окончание табл. 6.4
Сообщения обмена Комментарий
д) информационный обмен
(1)* I—>R: N/D Уведомление об ошибке или состоянии либо уведомление об удале-
нии связи
Обозначения:
I — инициатор,
R — отвечающая сторона,
* — полезный груз после заголовка ISAKMP шифруется.
Базовый обмен позволяет провести обмен ключами и данными аутенти-
фикации одновременно. Это сводит к минимуму число сообщений обмена за
счет отказа от защиты идентификации сторон. Два первых сообщения обес-
печивают обмен рецептами и создают защищенную связь с согласованными
протоколом и трансформациями; обе стороны используют оказии, чтобы за-
страховаться от атак воспроизведения сообщений. В оставшихся двух сооб-
щениях происходит обмен относящейся к ключам информацией и идентифи-
каторами пользователей, а полезный груз AUTH используется для аутенти-
фикации ключей, участвующих в обмене сторон и оказий из первых двух
сообщений.
Обмен с защитой идентификации сторон является расширением базово-
го обмена с целью защиты информации об участвующих в обмене сторонах.
Два первых сообщения создают защищенную связь. Два следующих сообще-
ния осуществляют обмен ключами и включают две оказии для защиты от
атак воспроизведения. Как только становится доступным сеансовый ключ,
стороны обмениваются шифрованными сообщениями, содержащими инфор-
мацию аутентификации, например цифровые подписи, и, если необходимо,
сертификаты открытых ключей.
Обмен только данными аутентификации используется для того, чтобы осу-
ществить взаимную аутентификацию без обмена ключами. Два первых сообще-
ния создают защищенную связь. Кроме того, отвечающая сторона использует
второе сообщение для того, чтобы передать свой идентификатор, и применяет
аутентификацию для защиты этого сообщения. Инициатор посылает третье со-
общение, чтобы передать свой аутентифицированный идентификатор.
Энергичный обмен сводит к минимуму число сообщений обмена за счет
отказа от защиты идентификации сторон. В первом сообщении инициатор
предлагает создать защищенную связь с набором предлагаемых протоколов и
трансформаций. Кроме того, инициатор начинает обмен ключами и высылает
свой идентификатор. Во втором сообщении отвечающая сторона указывает на
принятие защищенной связи с уже конкретными протоколом и трансформа-
цией, завершает обмен ключами и аутентифицирует переданную информа-
цию. В третьем сообщении инициатор передает результат аутентификации
полученной ранее информации, шифруя его с помощью общего секретного
сеансового ключа.
Информационный обмен предназначен для односторонней пересылки ин-
формации, касающейся параметров управления защищенной связью.
240 Часть II. Приложения сетевой защиты
6.7. РЕКОМЕНДУЕМЫЕ ИСТОЧНИКИ
ДОПОЛНИТЕЛЬНОЙ ИНФОРМАЦИИ
Протоколы IPv6 и IPv4 более подробно описаны в [STAL00]. Хорошее из-
ложение вопросов межсетевого взаимодействия и IPv4 можно найти в [СОМЕ95]
и [STEV94]. В [HUIT98] включено достаточно формальное описание документов
RFC, в совокупности составляющих спецификации IPv6; в книге обсуждается
назначение многих функций и операций протокола. В [CHEN98] предлагается
хорошее обсуждение структуры IPSec. Более подробным источником информа-
ции о IPSec является [DORA99].
i CHEN98 Cheng, Р., et al. “A Security Architecture for the Internet Protocol.” IBM
Systems JournaZ. Number 1,1998.
COME95 Comer, D. Internetworking with TCP/IP, Volume I: Principles, Protocols
and Architecture. Upper Saddle River, NJ: Prentice Hall, 1995.
! DORA99 Doraswamy, N., and Harkins, D. IPSec. Upper Saddle River. NJ: Prentice
Hall, 1999.
HUIT98 Huitema, C; IPv6: The New Internet Protocol. Upper Saddle River. NJ:
Prentice Hall, 1998.
i STALOO Stallings, W. Data and Computer Communications, 6th Edition. Upper
! Saddle River, NJ: Prentice Hall, 2000.
• STEV94 Stevens, W. TCP/IP Illustrated, Volume I: The Protocols. Reading, MA:
i Addison-Wesley, 1994.
Рекомендуемые Web-узлы
• Хартия протокола защиты IP (ipsec). Самые последние версии
документов RFC и проекты стандарта IPSec для Internet.
• Новости рабочей группы защиты IP. Документы рабочей груп-
пы, почтовые архивы, соответствующие технические статьи и
другие полезные материалы.
• Ресурсы защиты IP (IPSEC). Список компаний, предлагаю-
щих реализации IPSec, обзор реализаций и другие полезные
материалы.
6.8. ЗАДАЧИ
6.1. При обсуждении протокола АН было сказано, что не все поля в заголовке IP
участвуют в вычислении значения МАС.
а. Для каждого поля в заголовке IPv4 укажите, будет ли оно неизменным, из-
меняемым, но прогнозируемым, или просто изменяемым (значение последне-
го перед вычислением значения ICV должно обнуляться).
б. Сделайте то же самое для заголовка IPv6.
в. Выполните то же для заголовков расширений IPv6.
В каждом случае обоснуйте свой выбор для каждого из полей.
Глава 6. Защита IP
241
6.2. При использовании туннельного режима создается новый внешний заголовок IP.
Для IPv4 и IPv6 свяжите каждое поле внешнего заголовка IP и каждый заголовок
расширения во внешнем пакете с соответствующими полями или заголовками рас-
ширений внутреннего пакета IP. Другими словами, укажите, какие внешние значе-
ния задаются на основе внутренних значений, а какие создаются независимо.
6.3. При связи между двумя конечными системами желательны аутентификация и
шифрование. Изобразите, подобно тому, как это сделано на рис. 6.6 и 6.9, сле-
дующие структуры.
а. Транспортную смежность с шифрованием, применяемым до аутентификации.
б. Защищенную транспортную связь, вложенную в защищенную туннельную
связь, с шифрованием, применяемым до аутентификации.
в. Защищенную транспортную связь, вложенную в защищенную туннельную
связь, с аутентификацией, применяемой до шифрования.
6.4. В документе, описывающем архитектуру IPSec, утверждается, что в комбина-
ции двух защищенных связей в транспортном режиме с применением протоко-
лов АН и ESP для одного сквозного потока приемлемым оказывается только од-
но упорядочение протоколов защиты — использование протокола ESP до при-
менения протокола АН. Почему рекомендуется именно такой порядок, а не
аутентификация до шифрования?
6.5. а. Какой из типов обмена ISAKMP (см. табл. 6.4) соответствует энергичному
обмену ключами Oakley (см. рис. 6.11)?
б. Для сообщений энергичного обмена ключами Oakley укажите, к какому из
типов полезного груза ISAKMP относится каждый из параметров соответст-
вующего сообщения.
ДОПОЛНЕНИЕ 6.1. ПРОТОКОЛЫ
МЕЖСЕТЕВОГО ВЗАИМОДЕЙСТВИЯ
В этом дополнении предлагается краткий обзор протоколов межсетевого
взаимодействия. Мы начнем с выяснения роли этих протоколов в обеспечении
межсетевого обмена данными, а затем рассмотрим два главных протокола меж-
сетевого взаимодействия — IPv4 и IPv6.
Роль протокола межсетевого взаимодействия
Протокол межсетевого взаимодействия (IP) обеспечивает возможность свя-
зать конечные системы через множество сетей. Для этого IP реализуется в ко-
нечных системах и маршрутизаторах, являющихся устройствами, обеспечиваю-
щими связь между сетями. Данные высшего уровня в конечной системе-
отправителе инкапсулируются в протокольной единице данных (PDU) для пере-
дачи с использованием протокола IP. Протокольные единицы данных затем мо-
гут передаваться через несколько сетей с помощью связывающих эти сети мар-
шрутизаторов, чтобы в конце концов достичь конечной системы-адресата.
Маршрутизатор может справиться с целым рядом различий, существующих
между сетями, включая следующие.
* Схемы адресации. Сети могут иметь различные схемы представления адре-
сов устройств. Например, в локальной сети IEEE 802 для устройств преду-
242
Часть II. Приложения сетевой защиты
смотрены либо 16-битовые, либо 48-битовые двоичные адреса; открытая
сеть с коммутацией пакетов Х.25 использует 12-разрядные десятичные ад-
реса (закодированные по 4 бит на разряд, в результате чего получается 48-
битовый адрес). При этом требуется некоторая форма глобальной сетевой
адресации, а также служба каталогизации.
* Максимальные размеры пакетов. Может оказаться необходимым разделить
пакеты на части (что обычно называют фрагментацией) для того, чтобы пе-
редать их из одной сети в другую. Например, в Ethernet максимальным
размером пакета является 1500 байт, а в сетях Х.25 — 1000 байт. Пакету,
который передается по сети Ethernet и принимается маршрутизатором для
передачи в сеть Х.25, может потребоваться фрагментация.
* Интерфейсы. Аппаратные и программные интерфейсы разных сетей тоже
различаются. Маршрутизаторы не должны зависеть от таких различий.
* Степени надежности. Разные сетевые службы могут обеспечивать самые
разные уровни надежности — от надежного сквозного виртуального канала
до совершенно ненадежного сервиса. Работа маршрутизаторов не должна
зависеть от предположений о надежности сетей.
Как показано на рис. 6.13, работа маршрутизатора зависит от применяемо-
го протокола межсетевого взаимодействия. Для показанного на рисунке примера
соответствующая функция выполняется протоколом межсетевого взаимодейст-
вия (IP), использующим связку протоколов TCP/IP. При этом IP должен быть
реализован во всех конечных системах всех сетей, а также в маршрутизаторах.
Кроме того, все конечные системы для успешного взаимодействия должны иметь
совместимые протоколы над IP. Промежуточным маршрутизаторам при этом
достаточно быть согласованными только до уровня IP включительно.
Рассмотрим передачу блока данных от конечной системы X к конечной систе-
ме Y (рис. 6.13). Уровень IP в X получает блоки данных, которые следует пере-
слать системе У с использованием TCP в системе X. На уровне IP присоединяется
заголовок, который описывает глобальный межсетевой адрес системы Y. Такой ад-
рес состоит из двух частей: сетевого идентификатора и идентификатора конечной
системы. Назовем этот блок пакетом IP. Далее, IP выясняет, что адресат (У) нахо-
дится в другой подсети. Поэтому первым шагом должна быть пересылка пакета
маршрутизатору — в данном случае это маршрутизатор 1. Для этого IP передает
элемент данных ниже, на уровень LLC (Logical Link Control — управление логиче-
ским соединением) с соответствующей информацией адресации. LLC создает про-
токольную единицу данных LLC, которая передается ниже, на уровень МАС
(Media Access Control — управление доступом к среде). На уровне МАС создается
пакет МАС, заголовок которого содержит адрес маршрутизатора 1.
Затем пакет направляется по локальной сети к маршрутизатору 1. Маршру-
тизатор убирает заголовки и концевики пакета и LLC, а затем анализирует заго-
ловок IP, чтобы определить адрес конечного получателя данных (в данном слу-
чае — получателя У). Теперь маршрутизатору необходимо выбрать маршрут.
Существуют следующие возможности.
1. Конечная система адресата У находится непосредственно в одной из подсе-
тей, с которыми соединен маршрутизатор.
Глава 6. Защита IP
243
2. Чтобы достичь адресата, нужно использовать как минимум
еще один до-
полнительный маршрутизатор.
Конечная
системах
Маршрутизатор 1
Маршрутизатор 2
Локальная
или глобальная сеть
либо выделенная
связь
Конечная
система Y
Локальная сеть
Локальная сеть
Рис. 6.13. Пример конфигурации, использующей TPC/IP
В рассматриваемом нами примере пакет адресату можно доставить только через
маршрутизатор 2. Поэтому маршрутизатор 1 передает пакет IP маршрутизатору 2
через промежуточную сеть. Для этого используются протоколы промежуточной сети.
Например, если промежуточная сеть является сетью Х.25, элемент данных IP упа-
ковывается в пакет Х.25 с соответствующей информацией адресации, позволяющей
добраться до маршрутизатора 2. Когда пакет прибывает к маршрутизатору 2, заго-
ловок пакета убирается. Маршрутизатор выясняет, что данный пакет IP предназна-
чается для узла Y подсети, с которой данный маршрутизатор соединен непосредст-
венно. Поэтому маршрутизатор создает пакет с адресом Y и передает его в локальную
сеть. Данные наконец достигают Y, где уже можно снять заголовки и концевики па-
кета, LLC и протокола межсетевого взаимодействия.
Предлагаемый сервис IP является ненадежным, а это значит, что IP не гаран-
тирует, что все данные будут доставлены или что доставляемые данные прибудут в
пункт назначения в соответствующем порядке. За исправление возникающих при
передаче ошибок несет ответственность следующий, более высокий уровень, в дан-
ном случае — TCP. Такой подход обеспечивает немалую гибкость. Поскольку нет га-
рантий доставки, не выдвигается никаких специальных требований надежности и к
подсетям, по которым она выполняется. Таким образом, протокол должен работать
при любой комбинации подсетей. В связи с тем, что гарантированного порядка дос-
тавки пакетов не предполагается, следующие один за другим пакеты могут переда-
ваться разными маршрутами. Это позволяет протоколу реагировать на перегрузку и
отказы подсетей с помощью изменения маршрутов.
244
Часть II. Приложения сетевой защиты
IPv4
В течение десятилетий ключевым элементом архитектуры протоколов
TCP/IP был протокол межсетевого взаимодействия (IP) версии 4 (RFC 791). На
рис. 6.14, а показан формат заголовка IP, занимающего как минимум 20 байт,
или 160 бит. Этот заголовок имеет следующие поля.
• Версия (4 бит). Указывает номер версии, что позволяет учесть эволюцию
протокола; соответствующим значением в данном случае является 4.
• Длина заголовка межсетевого взаимодействия (Internet Header Length — IHL)
(4 бит). Длина заголовка в 32-битовых словах. Минимальным значением явля-
ется 5, что соответствует минимальной длине заголовка в 20 октетов.
• Тип сервиса (8 бит). Обеспечивает информацию об относительном приоритете
пакета модулям IP конечной системы и маршрутизаторам на пути следования.
• Общая длина (16 бит). Общая длина пакета IP в байтах.
• Идентификация (16 бит). Порядковый номер, который вместе с адресом ис-
точника, адресом назначения и протоколом пользователя используется для
однозначной идентификации пакета. Такой идентификатор должен быть
уникальным для данной комбинации адреса источника, адреса назначения
и протокола пользователя пакета на протяжении всего времени нахождения
пакета в межсетевом пространстве.
* Флаги (3 бит). Пока что определено только два бита этого поля. Когда па-
кет фрагментирован, бит More (еще) указывает, является ли данный фраг-
мент последним в оригинальном пакете. Установленный бит Not Fragment
(не фрагментировать) запрещает фрагментацию. Этот бит может оказаться
полезным тогда, когда известно, что адресат не имеет возможностей для по-
вторной сборки фрагментов. Однако, если этот бит установлен, пакет будет
отвергнут, если его длина превысит максимальный размер, разрешенный
для некоторой подсети на пути следования пакета. Таким образом, если бит
установлен, может оказаться целесообразным использовать маршрутизацию
источника, чтобы избежать переходов в подсети со слишком малыми мак-
симальными размерами пакетов.
• Смещение фрагмгента (13 бит). Указывает в 64-битовых единицах, где в
оригинальном пакете размещается данный фрагмент. Это значит, что для
фрагментов, не являющихся последними, длина поля данных должна быть
кратна 64 бит.
• Время жизни (8 бит). Указывает в секундах, как долго пакету разрешается
оставаться в межсетевом пространстве. Каждый маршрутизатор, обрабаты-
вающий пакет, должен уменьшить значение этого поля по крайней мере на
единицу, так что поле времени жизни отчасти подобно счетчику транзитов.
• Протокол (8 бит). Указывает протокол следующего более высокого уровня,
который должен принять поле данных в узле адресата; таким образом, это
поле указывает тип следующего заголовка в пакете после заголовка IP.
• Контрольная сумма заголовка (16 бит). Код обнаружения ошибок, приме-
няемый только к заголовку. Поскольку некоторые поля заголовка могут
измениться в ходе транзита (например, время жизни и связанные с сегмен-
Глава 6. Защита IP
245
тацией поля), они проверяются и их значения повторно вычисляются в ка-
ждом маршрутизаторе. Значением поля контрольной суммы является сумма
обратных кодов (16-битовых дополнений до единицы) всех 16-битовых слов
заголовка. Для определенности вычислений поле контрольной суммы ини-
циализируется нулевым значением.
• Адрес источника (32 бит). Кодируется, чтобы обеспечить возможность нуж-
ным образом задать биты, указывающие сеть и конечную систему, присое-
диненную к указанной сети (7 и 24 бит, 14 и 16 бит или 21 и 8 бит).
• Адрес назначения (32 бит). Имеет характеристики, аналогичные полю для
адреса источника.
• Опции (переменной длины). Это поле представляет параметры, запраши-
ваемые отправляющим пакет пользователем; они могут включать метку
грифа (секретности), исходную маршрутизацию, запись маршрутизации и
метки даты-времени.
• Заполнение (переменной длины). Служит для того, чтобы сделать длину за-
головка пакета кратной 32 бит.
IPv6
В 1995 году Проблемная группа проектирования Internet (IETF), которая
разрабатывает стандарты протоколов для Internet, опубликовала спецификации
новой версии IP, версии нового поколения, получившей название IPng
(RFC 1752). Эти спецификации привели к созданию стандарта, получившего на-
звание IPv6 (RFC 2460). По сравнению с существующим стандартом IP
(известным как IPv4) IPv6 имеет целый ряд функциональных усовершенствова-
ний, касающихся, в частности, возможности использования возросших скоро-
стей передачи данных современных сетей и комбинирования потоков данных,
включающих графику и видео, также получающих все большее распростране-
ние. Но главной движущей силой разработки нового протокола явилась необхо-
димость применения большего числа адресов. В IPv4 для описания источника
или адресата используется 32-битовый адрес. С бурным ростом Internet и част-
ных сетей, связанных с Internet, эта длина для адреса становится недостаточной.
Как показано на рис. 6.14, б, в протоколе IPv6 для адресов источника и адресата
предусмотрены 128-битовые поля. Предполагается, что в конце концов к IPv6
придут все построенные на использовании TCP/IP системы, но этот процесс мо-
жет занять много лет, если не десятилетия.
Заголовок IPv6
Заголовок IPv6 имеет фиксированную длину в 40 байт и формируется из
следующих полей (рис. 6.14, б).
• Версия (4 бит). Номер версии протокола межсетевого взаимодействия; ее
значением в данном случае является 6.
• Класс трафика (8 бит). Данное поле доступно для использования узлом ис-
точника и/или передающими маршрутизаторами с целью идентификации и
разделения на классы по приоритетам пакетов IPv6. Преимущества этого
поля пока не очень ясны.
246
Часть II. Приложения сетевой защиты
Бит: 0 4 8 16 19 31
/ X
Версия IHL Тип сервиса Общая длина г
&9 О Идентификация Флаги Смещение фрагмента /
О £ о Время ЖИЗНИ Протокол Контрольная сумма заголовка /
о сч Адрес источника
Адрес назначения
Опции + заполнение
а) заголовок IPv4
Бит:
Рис 6.14. Заголовки IP
б) заголовок IPv6
• Метка потока (20 бит). Позволяет пометить пакеты, для которых от мар-
шрутизаторов в сети требуется специальная обработка. Использование мет-
ки потока может сопровождать резервирование ресурсов и обработку потока
в режиме реального времени.
• Длина полезного груза (16 бит). Длина в байтах части пакета IPv6, сле-
дующей за заголовком. Другими словами, это общая длина всех заголовков
расширения плюс PDU (модуль данных протокола) транспортного уровня.
• Следующий заголовок (8 бит). Идентифицирует тип заголовка, следующего
непосредственно за заголовком IPv6. Это либо заголовок расширения IPv6,
либо заголовок высшего уровня, например TCP или UDP.
Глава 6. Защита IP
247
• Предельное число транзитов (8 бит). Оставшееся допустимое число транзи-
тов для данного пакета. Предел для числа транзитов устанавливается рав-
ным некоторому максимальному значению источником и уменьшается на 1
каждым узлом, передающим пакет далее. Пакет будет отвергнут, если зна-
чение поля предельного числа транзитов уменьшится до нуля.
• Адрес источника (128 бит). Адрес создателя пакета.
• Адрес назначения (128 бит). Адрес предполагаемого получателя пакета. На
самом деле, как объясняется ниже, это может и не быть адресом предпола-
гаемого конечного получателя, если присутствует заголовок расширения
маршрутизации.
Хотя заголовок IPv6 и длиннее обязательной порции заголовка IPv4 (40, а
не 20 байт), он содержит меньше полей (8, а не 12). Поэтому с заголовком IPv6
маршрутизаторы имеют меньше работы, что должно ускорить маршрутизацию.
Заголовки расширений IPv6
Пакет IPv6 формируется из только что приведенного заголовка IPv6 и не-
которого (возможно, нулевого) числа заголовков расширений. За пределами
IPSec определены следующие заголовки расширений.
• Заголовок параметров транзита. Определяет специальные параметры, тре-
буемые для транзита.
• Заголовок маршрутизации. Обеспечивает расширенные возможности мар-
шрутизации, подобные исходной маршрутизации IPv4.
• Заголовок фрагментации. Содержит информацию о фрагментации и по-
вторной сборке пакета.
• Заголовок аутентификации. Обеспечивает целостность и аутентификацию
пакета.
• Заголовок включающего защиту полезного груза. Обеспечивает секретность.
• Заголовок параметров адресата. Содержит необязательную информацию,
которая должна быть обработана в узле адресата.
При использовании нескольких заголовков расширений стандарт IPv6 ре-
комендует, чтобы заголовки IPv6 размещались в следующем порядке.
1. Заголовок IPv6. Обязателен, должен всегда размещаться первым.
2. Заголовок параметров транзита.
3. Заголовок параметров адресата. Предназначен для опций, которые должны
обрабатываться первым адресатом, указанным в поле адреса назначения
IPv6, а также адресатами, перечисленными в заголовке маршрутизации.
4. Заголовок маршрутизации.
5. Заголовок фрагментации.
6. Заголовок аутентификации.
7. Заголовок включающего защиту полезного груза.
8. Заголовок параметров адресата. Для опций, которые должны обрабатывать-
ся конечным адресатом пакета.
248
Часть II. Приложения сетевой защиты
На рис. 6.15 показан пример пакета IPv6, включающего по одному экземпляру
каждого из заголовков, кроме заголовков защиты. Обратите внимание на то, что в
заголовке IPv6 и каждом из заголовков расширений существует поле следующего за-
головка. В этом поле указан тип следующего заголовка. Если следующий заголовок
является заголовком расширения, это поле содержит идентификатор типа такого за-
головка. Иначе данное поле должно содержать идентификатор протокола верхнего
уровня, использующего IPv6 (обычно это протокол транспортного уровня). Исполь-
зуемые для этого поля значения аналогичны значениям поля Protocol (протокол)
IPv4. На рис. 6.15 протоколом верхнего уровня является TCP, так что пересылаемые
пакетом IPv6 данные верхнего уровня складываются из заголовка TCP и следующего
за ним блока данных приложения.
Байты:
40
Переменной длины
Переменной длины
8
Переменной длины
Переменной длины
20 (плюс необязательная часть переменной длины)
ЯНМНИ — поле следующего заголовка
Рис. 6.15. Пакет IPv6 с заголовками расширений (включая сегмент TCP)
Заголовок параметров транзита несет дополнительную информацию, кото-
рую, если она присутствует, должен обрабатывать каждый маршрутизатор на
пути следования пакета. Этот заголовок складывается из следующих полей.
• Следующий заголовок (8 бит). Указывает тип заголовка, следующего непо-
средственно за данным.
• Длина заголовка расширения (8 бит). Длина данного заголовка в 64-
битовых единицах длины, не включая первые 64 бит.
• Опции. Значения одной или нескольких опций. Каждая опция состоит из трех
подполей: признака, определяющего тип опции, длины и некоторого значения.
Глава 6. Защита IP
249
Пока что определена только одна опция: это признак очень большого по-
лезного груза, используемый тогда, когда требуется переслать пакет IPv6 с по-
лезными грузом, по длине превышающим 21б-1= 65535 байт. Значение поля па-
раметров данных этой опции, имеющее длину 32 бит, дает длину такого пакета
в байтах, исключая заголовок IPv6. Для таких пакетов значение поля длины
полезного груза в заголовке IPv6 следует установить равным нулю и исключить
заголовок фрагментации. С установленной указанной опцией IPv6 поддерживает
пакеты длиной около 4 Гбайт. Это дает возможность пересылать большие пакеты
с видеоданными и позволяет IPv6 выбрать лучшую пропускную способность в
любой передающей среде.
Заголовок маршрутизации содержит список промежуточных узлов, которые
должны быть посещены на пути к адресату пакета. Заголовок маршрутизации начи-
нается с 32-битового блока, состоящего из четырех 8-битовых полей, за которым
следуют данные маршрутизации, специфические для данного типа маршрутизации.
Четырьмя указанными 8-битовыми полями являются поле следующего заголовка,
поле длины заголовка расширения, а также два следующих поля.
• Тип маршрутизации. Идентифицирует конкретный вариант заголовка мар-
шрутизации. Если маршрутизатор не распознает значение типа маршрути-
зации, он должен отвергнуть пакет.
• Оставшиеся сегменты. Число явно указанных промежуточных вершин, ко-
торые еще осталось посетить до того, как пакет будет доставлен конечному
адресату.
В дополнение к этому общему определению заголовка спецификации IPv6
определяют заголовок маршрутизации типа 0. При использовании заголовка
маршрутизации типа 0 узел-источник не размещает адрес конечного получателя
в заголовке IPv6. Вместо этого такой адрес указывается в качестве последнего
адреса в списке заголовка маршрутизации, а в заголовок IPv6 помещается адрес
первого из маршрутизаторов на пути следования пакета. Заголовок маршрутиза-
ции не будет обработан до тех пор, пока пакет не достигнет узла, указанного в
заголовке IPv6. В этом узле содержимое заголовка IPv6 и заголовка маршрути-
зации изменяется и пакет передается дальше. При этом в заголовок IPv6 поме-
щается адрес следующего узла, который необходимо посетить, и на единицу
уменьшается значение поля оставшихся сегментов в заголовке маршрутизации.
Протокол IPv6 требует использовать IPv6 в узле, в котором может возник-
нуть необходимость вернуть пакет отправителю, чтобы узел мог восстановить
уже пройденный пакетом маршрут.
Заголовок фрагментации применяется источником при необходимости
фрагментации пакета. При использовании IPv6 предполагается, что фрагмента-
ция может быть выполнена только узлом источника, а не маршрутизаторами
вдоль маршрута доставки пакета. Чтобы воспользоваться всеми преимуществами
среды межсетевого взаимодействия, узел должен использовать алгоритм восста-
новления маршрута, чтобы выяснить наименьшее значение максимальной еди-
ницы передачи (MTU), поддерживаемой всеми подсетями вдоль маршрута. Дру-
гими словами, алгоритм восстановления маршрута дает узлу возможность выяс-
нить значение MTU “узких мест” маршрута. Выяснив это значение, узел
источника может подходящим образом фрагментировать пакет в зависимости от
адреса назначения. Иначе источнику придется ограничить длины всех пакетов
250 Часть II. Приложения сетевой защиты
;личиной в 1280 байт, что равно минимальному значению MTU, которое долж-
э поддерживаться любой подсетью.
Кроме поля следующего заголовка, заголовок фрагментации включает сле-
югцие поля.
• Смещение фрагмента (13 бит). Указывает, где в оригинальном пакете нахо-
дится полезный груз данного фрагмента. Измеряется в 64-битовых едини-
цах длины. Отсюда следует, что поля данных фрагментов (всех, кроме по-
следнего) должны быть кратными 64 бит.
• Резерв (2 бит). Зарезервировано для будущего использования.
• Флаг М (1 бит). 1 означает, что еще имеются фрагменты, а 0 — что это по-
следний фрагмент.
• Идентификация (32 бит). Поле предназначено для однозначной идентифи-
кации оригинального пакета. Идентификатор должен быть уникальным для
данных источника и адресата в течение всего времени, пока пакет остается
в межсетевом пространстве. Все фрагменты с одинаковыми идентификато-
рами и адресами источника получателя будут снова собраны вместе, чтобы
воссоздать оригинальный пакет.
Заголовок параметров адресата несет необязательную информацию, кото-
:ая, если она имеется, будет рассмотрена только в узле конечного получателя
:акета. Формат этого заголовка тот же, что и у заголовка параметров транзита.
' :ава 6. Защита IP
251
This page intentionally left blank
ГЛАВА
Защита Web
7.1. Проблемы защиты Web
7.2. Протоколы SSL и TLS
7.3. Протокол защищенных электронных транзакций
(SET)
7.4. Рекомендуемые источники дополнительной
информации
7.5. Задачи
Сегодня собственный Web-узел имеют не только практически все коммерче-
ские организации и большинство государственных учреждений, но и мно-
гие частные лица. Число индивидуальных и корпоративных пользователей
Internet растет очень быстро, и практически все они имеют Web-броузеры с гра-
фическим интерфейсом. Как следствие, коммерческие структуры с энтузиазмом
относятся к идее использования Web для организации электронной торговли.
Однако реальность такова, что Internet и Web оказываются достаточно уязви-
мыми с точки зрения угроз самого разного типа. Столкновение с действительно-
стью заставляет коммерческие структуры уделять все больше внимания средст-
вам обеспечения безопасности Web.
Тема защиты Web обширна сама по себе и вполне заслуживает отдельной книги
(в конце главы читателю рекомендуется несколько изданий, посвященных этой те-
ме). Мы же сначала обсудим основные требования безопасности Web, а затем перей-
дем к двум стандартным схемам защиты — SSL/TLS и SET, значение которых для
электронной коммерции очень велико уже сегодня и постоянно растет.
7.1. ПРОБЛЕМЫ ЗАЩИТЫ WEB
По сути, World Wide Web можно интерпретировать как приложение типа
клиент/сервер, работающее в сети Internet и внутренних сетях предприятий на
основе протокола TCP/IP. В такой интерпретации все упоминавшиеся в данной
книге методы защиты и соответствующие средства ее обеспечения применимы и
для защиты Web. Однако, как отмечено в [GARF97], в отношении Web возника-
ет и ряд новых проблем, не рассматриваемых в контексте компьютерной безо-
пасности и защиты обычных сетей.
• Сеть Internet допускает двусторонний обмен информацией. В отличие от
традиционных средств распространения информации, включая телетекст,
голосовую почту и автоматическую отправку факсов, Web оказывается уяз-
вимой к возможности проникновения в Web-узлы и изменения их содер-
жимого через Internet.
• Web все чаще используется для доступа к корпоративной информации и
информации о производимых компанией продуктах, а также для осуществ-
ления всевозможных транзакций. Поэтому нарушение работы Web-сервера
может отразиться не только на репутации компании, но и вылиться в зна-
чительный материальный ущерб.
• Использовать Web-броузеры совсем просто, настраивать и поддерживать
Web-серверы относительно нетрудно, да и для создания Web-страниц не
требуется особого мастерства, но сложность соответствующего программного
обеспечения исключительно высока. Такое сложное программное обеспече-
ние может содержать множество потенциальных недостатков с точки зре-
ния гарантии защиты. Весьма короткая история Web изобилует примерами
новых и новейших систем, оказавшихся весьма уязвимыми на практике.
• Web-сервер можно использовать как плацдарм для проникновения в любую
часть всего компьютерного комплекса компании или организации. Если ра-
бота Web-сервера соответствующим образом нарушена, нарушитель может
254
Часть II. Приложения сетевой защиты
получить доступ к данным и системам, не являющимся частью Web, а под-
ключенным к серверу в рамках локальной сети.
• Типичными потребителями услуг Web являются случайные и не имеющие
специальной подготовки (в области вопросов защиты) пользователи. Таких
пользователей, как правило, не волнует риск нарушения защиты, они не
имеют специальных средств и достаточных знаний для того, чтобы исполь-
зовать эффективные контрмеры.
Угрозы нарушения защиты Web
В табл. 7.1 перечислены основные типы угроз нарушения защиты, возни-
кающие при использовании Web-технологий. Один из подходов к классифика-
ции таких угроз заключается в разделении нарушений на пассивные и актив-
ные. К пассивным нарушениям защиты можно отнести перехват данных на пути
между броузером и сервером или получение доступа к закрытой информации на
Web-узле. К активным нарушениям относятся, например, попытки нарушителя
выдать себя за другого пользователя, изменение потока данных между клиентом
и сервером, модификация информации, составляющей содержимое Web-узла.
Таблица 7.1. Сравнительные характеристики угроз нарушения защиты Web [RUBI97]
Угрозы Последствия Контрмеры
Целостность • Изменение пользова- • Потеря информации. Криптогра-
тельских данных е Дискредитация компьютерной фические
• Внедрение “троянских системы контрольные
• • коней” е Изменение информа- ции в памяти Изменение потока со- общений на пути их передачи Уязвимость в отношении уг- роз нарушения защиты всех остальных типов суммы
Конфиденци- • Перехват данных в сети • Потеря информации Шифрование,
альность • • • • Кража информации, • хранимой сервером Кража информации, хранимой клиентом Получение информации о конфигурации сети Получение информа- ции о клиенте, обра- щающемся к серверу Нарушение тайны информации прокси- серверы Web
Доступность • Прекращение сеанса • доступа пользователя Разрушительные последствия для системы Трудно пре- дотвратить
• Перегрузка машины • потоком фальшивых , попыток доступа Раздражение пользователей Невозможность выполнения работы пользователями
Глава 7. Защита Web
255
Окончание табл. 7.1
Угрозы Последствия Контрмеры
Аутентифи- • Умышленное перепол- нение дискового про- странства или опера- тивной памяти • Изоляция системы пу- тем атак на DNS-сервер • Имитация легального • Неправильное представление Криптогра-
кация пользователя наруши- пользователей фические
телем • Фальсификация данных • Доверие к искаженным данным технологии
Другой подход к классификации угроз нарушения защиты основан на ис-
пользовании информации о месте их проявления: на Web-сервере, в броузере
или потоке данных между броузером и сервером. Вопросы обеспечения защиты
сервера и броузера относятся к вопросам безопасности компьютерных систем,
поэтому их можно рассматривать в контексте материала, изложенного в части
III книги, где рассматриваются общие вопросы защиты систем, но предлагаемые
там решения вполне применимы и для обеспечения защиты Web. Проблема за-
щиты потока данных относится к категории проблем защиты сети и будет ис-
следована в данной главе.
Способы защиты потока данных в Web
Существует несколько подходов к обеспечению защиты данных в Web. Все
они похожи с точки зрения предоставляемых возможностей и в некоторой сте-
пени с точки зрения используемых механизмов защиты, но различаются по об-
ластям применения и размещению соответствующих средств защиты в стеке
протоколов TCP/IP.
Эти различия схематически показаны на рис. 7.1. Один из методов защиты
данных в Web состоит в использовании протокола IPSec (рис. 7.1, а). Преимущество
использования IPSec заключается в том, что этот протокол прозрачен для конечного
пользователя и приложений и обеспечивает универсальное решение. Кроме того,
протокол IPSec включает средства фильтрации, позволяющие использовать его толь-
ко для той части потока данных, для которой это действительно необходимо.
HTTP FTP SMTP
TCP
IP/IPSec
а) сетевой уровень
б) транспортный уровень
S/MIME PGP
SET
Kerberos
SMTP
HTTP
UDP
TCP
в) прикладной уровень
Puc. 7.1. Размещение средств защиты в стеке протоколов TCP/IP
256
Часть II. Приложения сетевой защиты
Другим (в какой-то мере универсальным) решением является размещение
средств защиты сразу над протоколом TCP (рис. 7.1, б). Примером современной
реализации такого подхода являются стандарт SSL (Secure Socket Layer — про-
токол защищенных сокетов) и его более новая версия — стандарт TLS (Transport
Layer Security — протокол защиты транспортного уровня) безопасной передачи
данных в Internet. На этом уровне для практической реализации данного подхо-
да существует две возможности. Самым общим решением является внедрение
средств SSL (или TLS) в набор соответствующих протоколов, что обеспечивает
прозрачность средств защиты для приложений. В то же время средства SSL
можно встраивать и в прикладные программы. Например, броузеры Netscape и
Microsoft Internet Explorer, а также большинство Web-серверов имеют встроен-
ную поддержку SSL.
Различные средства защиты могут встраиваться и в приложения, как пока-
зано на рис. 7.1, в. Преимущество данного подхода состоит в том, что соответст-
вующие средства защиты могут быть настроены оптимальным образом в зависи-
мости от требований конкретного приложения. В контексте безопасности Web
важным примером реализации такого подхода является протокол SET (Secure
Electronic Transaction — протокол защиты электронных транзакций).1
7.2. ПРОТОКОЛЫ SSL И TLS
Протокол SSL был предложен компанией Netscape. Версия 3 данного про-
токола создавалась в условиях открытого обсуждения и с учетом предложений
пользователей, после чего протокол был опубликован в виде проекта стандарта
защиты данных в Internet. Впоследствии после достижения консенсуса протокол
был выдвинут на роль стандарта для Internet, и в рамках IETF была сформиро-
вана рабочая группа TLS, задачей которой является создание общепринятого
стандарта. В настоящее время цель работы группы — разработка первой версии
соответствующего стандарта Internet. Эта первая версия стандарта TLS должна в
своей основе совпадать с SSLv3.1 и быть очень близкой к SSLv3, а также иметь
свойства обратной совместимости с последней.
Большая часть материала данного раздела будет посвящена обсуждению
SSLv3, а в конце раздела мы обсудим основные различия между SSLv3 и TLS.
Архитектура SSL
Протокол SSL призван обеспечить возможность надежной защиты сквозной пе-
редачи данных с использованием протокола TCP. Строго говоря, SSL представляет
собой не один протокол, а два уровня протоколов, как показано на рис. 7.2.
Протокол записи SSL (SSL Record Protocol) обеспечивает базовый набор
средств защиты, применяемых протоколами более высоких уровней. Эти средст-
ва, в частности, может использовать протокол передачи гипертекстовых файлов
(HTTP), призванный обеспечить обмен данными при взаимодействии клиентов и
серверов Web. Частью SSL считаются и три протокола более высокого уровня:
1 На рис. 7.1, в протокол SET размещен над HTTP, так как именно такая реали-
зация является типичной. Но существуют и реализации, где SET размещается непо-
средственно над TCP.
Глава 7. Защита Web
257
протокол квитирования установления связи (Handshake Protocol), протокол из-
менения параметров шифрования (Change Cipher Spec Protocol) и протокол из-
вещения (Alert Protocol). Эти протоколы используются для управления обменом
данными SSL и рассмотрены ниже.
Протокол квитирования SSL Протокол изменения параметров шифрования SSL Протокол извещения SSL HTTP
Протокол записи SSL
TCP
IP
Рис. 7.2. Стек протоколов SSL
Работа протокола SSL описывается в терминах двух важных понятий — се-
анса SSL и соединения SSL.
• Соединение (connection). Соединением называется транспорт (в терминах
модели OSI), обеспечивающий сервис некоторого подходящего типа. В SSL
такие соединения представляют равноправные отношения между узлами.
Соединения являются временными. Каждое соединение ассоциируется
только с одним сеансом.
• Сеанс (session). Сеанс SSL — это связь между клиентом и сервером. Сеансы
создаются протоколом квитирования SSL (SSL Handshake Protocol). Сеанс
определяет набор параметров криптографической защиты, которые могут
использоваться несколькими соединениями. Сеансы позволяют избежать
необходимости ведения переговоров об установке параметров защиты для
каждого нового соединения.
Между любой парой сообщающихся сторон (например, между НТТР-
приложениями клиента и сервера) можно установить много защищенных соедине-
ний. Теоретически между сторонами можно установить и несколько одновременно
существующих сеансов, но на практике такая возможность не используется.
Каждый сеанс характеризуется тем или иным состоянием. Например, после
начала сеанса устанавливается рабочее состояние (operating state) для чтения и
записи (т.е. получения и отправки информации). А во время работы протокола
квитирования SSL создается состояние ожидания (pending state) чтения и запи-
си. После успешного завершения работы протокола квитирования SSL состояние
ожидания переходит в рабочее состояние.
Состояние сеанса определяется следующими параметрами (определения да-
ны по спецификации SSL).
258
Часть II. Приложения сетевой защиты
• Идентификатор сеанса (session identifier). Произвольная последователь-
ность байтов, генерируемая сервером для идентификации состояния актив-
ного или возобновляемого сеанса.
• Сертификат узла (peer certificate). Сертификат X509.v3 стороны, участ-
вующей в сеансе. Этот элемент состояния может быть пустым.
• Метод сжатия (compression method). Алгоритм сжатия данных перед их
шифрованием.
• Параметры шифрования (cipher spec). Задают алгоритм шифрования дан-
ных (например, null, DES и т.п.) и алгоритм хэширования (например, MD5
или SHA-1), используемый для вычисления значений МАС. Кроме того, оп-
ределяют криптографические атрибуты типа длины хэш-кода.
• Главный ключ (master secret). 48-байтовый секретный ключ, используемый
клиентом и сервером.
• Флаг возобновления (is resumable). Признак, разрешающий инициализа-
цию новых соединений в рамках данного сеанса.
Состояние соединения определяется следующими параметрами.
• Случайный идентификатор сервера и клиента. Последовательность байтов, ге-
нерируемая для идентификации каждого соединения сервером и клиентом.
• Ключ записи МАС сервера. Секретный ключ, применяемый сервером при
вычислении значений МАС для отправляемых им данных.
• Ключ записи МАС клиента. Секретный ключ, применяемый клиентом при
вычислении значений МАС для отправляемых им данных.
• Ключ записи сервера. Ключ традиционной схемы шифрования, используе-
мый сервером для шифрования данных и клиентом для их дешифрования.
• Ключ записи клиента. Ключ традиционной схемы шифрования, используе-
мый клиентом для шифрования данных и сервером для их дешифрования.
• Векторы инициализации. При блочном шифровании в режиме СВС (режим
сцепления шифрованных блоков) с каждым ключом связывается вектор
инициализации (IV). Первый раз это поле инициализируется протоколом
квитирования SSL, а затем для каждой следующей записи в качестве IV ис-
пользуется сохраненный текущий шифрованный блок.
• Порядковые номера. Каждая из сторон самостоятельно нумерует отправ-
ляемые и получаемые по каждому соединению сообщения. Когда одна из
сторон получает или отправляет сообщение об изменении параметров шиф-
рования, соответствующий порядковый номер устанавливается равным 0.
Порядковые номера не могут превышать значения 264 -1.
Протокол записи SSL
Протокол записи SSL (SSL Record Protocol) обеспечивает поддержку двух
следующих сервисов для соединений SSL.
• Конфиденциальность. Протокол квитирования SSL определяет общий для
клиента и сервера секретный ключ, который будет использоваться алгорит-
Глава 7. Защита Web
259
мом традиционной схемы для шифрования данных, передаваемых по про-
токолу SSL.
• Целостность сообщений. Помимо обеспечения конфиденциальности, протокол
квитирования SSL определяет общий секретный ключ для вычисления значе-
ний MAC (Message Authentication Code — код аутентичности сообщения).
На рис. 7.3 показана общая схема работы протокола записи SSL. Этот про-
токол, получив сообщение для отправки, сначала фрагментирует данные, разби-
вая их на блоки подходящего размера, при необходимости выполняет сжатие
данных, применяет алгоритм вычисления МАС, шифрует данные, добавляет за-
головок и передает полученные пакеты сегменту TCP. Что касается принимае-
мых данных, то они дешифруются, проверяются, распаковываются, собираются
вновь из фрагментов и передаются приложениям более высокого уровня.
Данные приложения
Рис. 7.3. Схема работы протокола записи SSL
Первым шагом является фрагментация. Сообщение, полученное от прило-
жения более высокого уровня, разделяется на блоки размером не более 214 байт
(16384 байт). Затем как необязательная возможность применяется сжатие. Такое
сжатие должно происходить без потерь и не должно увеличивать размер блока
более чем на 1024 байт.2 В спецификациях SSLv3 (а также в текущей версии
TLS) по умолчанию алгоритмы сжатия не применяются.
Следующим шагом является вычисление кода аутентичности сообщения
(значения МАС) для сжатых данных. Для этого служит общий секретный ключ.
Вычисления выполняются по следующей схеме.
2 Конечно, от сжатия ожидается сокращение, а не увеличение объема данных. Тем
не менее, для достаточно малых (по длине) блоков данных сжатие может привести и
к увеличению длины полученного в результате блока по сравнению с длиной исходного.
260
Часть II. Приложения сетевой защиты
hash(MAC_write_secret || pad_2 ||
hash(MAC_write_secret || pad_l || seq_num || SSLCompressed.type ||
SSLCompressed.length || SSLCompressed.fragment)),
где II MAC_write_secret hash . — операция конкатенации; — общий секретный ключ; — криптографический алгоритм хэширования (MD5 или SHA-1);
pad_l — байт 0x36 (000 ОНО), повторенный 48 раз (384 бит) при использовании MD5 или 40 раз (320 бит) при использовании SHA-1;
pad_2 — байт 0х5С (0101 1100), повторенный 48 раз для MD5 или 40 раз для SHA-1,
seq_num SSLCompressed.type — порядковый номер данного сообщения; — протокол более высокого уровня, используемый для обработки данного фрагмента;
SSLCompressed.length SSLCompressed.fragment — длина сжатого фрагмента; — сжатый фрагмент (если сжатие не применялось, то фрагмент в виде открытого текста).
Обратите внимание на то, что этот алгоритм очень похож на алгоритм
НМАС, описанный в главе 3. Различие состоит в том, что в SSLv3 заполнители
связываются операцией конкатенации, а в НМАС — операцией XOR
исключающее “ИЛИ”). Дело в том, что алгоритм вычисления МАС в SSLv3
опирается на спецификации оригинального проекта стандарта Internet для
НМАС, в котором предлагалось использование конкатенации. В окончательной
версии НМАС, определенной документом RFC 2104, используется XOR.
Затем сжатое сообщение вместе с добавленным к нему значением МАС
шифруется с использованием симметричной схемы шифрования. Шифрование
тоже не должно увеличивать длину блока более чем на 1024 байт, поэтому об-
щий размер блока не может превысить 214 + 2048 байт. Допускается применение
следующих алгоритмов шифрования.
Блочное шифрование Поточное шифрование
Алгоритм Длина ключа Алгоритм Длина ключа
IDEA 128 RC4-40 40
RC2-40 40 RC4-128 128
DES-40 40
DES 56
3DES 168
Fortezza 80
Алгоритм Fortezza может использоваться в схемах шифрования микропро-
цессорных карт (smart card).
В случае применения алгоритмов поточного шифрования шифруются только
сжатое сообщение и добавленное к нему значение МАС. (Обратите внимание на то,
Глава 7. Защита Web
261
что значение МАС вычисляется перед шифрованием и, таким образом, шифруется
вместе с открытым текстом или сжатым открытым текстом сообщения.)
При использовании алгоритмов блочного шифрования после значения МАС
может понадобиться добавить заполнитель. При этом непосредственно за байта-
ми заполнителя следует 1-байтовое значение, указывающее общую длину запол-
нителя. Для общей длины заполнителя выбирается наименьшее из значений,
при котором длина блока данных, подлежащих шифрованию (открытый текст +
МАС + заполнитель), оказывается кратной длине блока шифра. Рассмотрим
пример, когда длина открытого текста (или сжатого открытого текста, если
применяется сжатие) равна 58 байт, длина значения МАС — 20 байт (алгоритм
SHA-1), а алгоритм шифрования (например DES) использует блоки длиной 8
байт. С учетом байта, указывающего длину заполнителя (padding.length), общий
размер блока составит 79 байт. Чтобы размер блока был кратен 8, в данном слу-
чае необходимо добавить один байт заполнителя.
Завершающим шагом в работе протокола записи SSL является создание за-
головка, состоящего из следующих полей.
• Тип содержимого (8 бит). Определяет протокол лежащего выше уровня, с
помощью которого должен обрабатываться данный фрагмент.
• Главный номер версии (8 бит). Указывает главный номер версии исполь-
зуемого протокола SSL. Для SSLv3 это поле содержит значение 3.
• Дополнительный номер версии (8 бит). Указывает дополнительный номер вер-
сии применяемого протокола SSL. Для SSLv3 это поле содержит значение 0.
• Длина сжатого фрагмента (16 бит). Длина в байтах данного фрагмента от-
крытого текста (или сжатого фрагмента, если используется сжатие). Мак-
симально допустимое значение равно 214 + 2048 .
Для типа содержимого предусмотрено использование значений
change_cipher_spec, alert, handshake и application_data. Первые три
значения обозначают протоколы стека SSL и будут описаны ниже. Обратите
внимание на то, что между приложениями, которые могут использовать SSL
(например HTTP), различий не делается: для SSL созданные такими прило-
жениями данные имеют совершенно одинаковое значение.
Формат записи, получаемой на выходе SSL, показан на рис. 7.4.
Протокол изменения параметров шифрования
Протокол изменения параметров шифрования (Change Cipher Spec Protocol)
является самым простым из трех протоколов высшего уровня в стеке протоколов
SSL. Протокол изменения параметров шифрования генерирует однобайтовое со-
общение, содержащее значение 1 (рис. 7.5, а). Единственной целью этого сооб-
щения является указание копировать параметры состояния ожидания в текущее
состояние, в результате чего обновляется комплект шифров, используемых для
данного соединения.
262
Часть II. Приложения сетевой защиты
Рис. 7.4. Формат записи SSL
1 байт
1 байт 3 байт > 0 байт
Тип Длина Содержимое
в) протокол квитирования
а) протокол изменения
параметров шифрования
1 байт 1 байт
> 1 байт
Уровень Извещение
Любое содержимое
б) протокол извещения
г) другой вышележащий протокол (например HTTP)
Рис. 7.5. Формат полезного груза протокола записи SSL
Протокол извещения
Протокол извещения (Alert Protocol) предназначен для передачи другой
частвующей в обмене данными стороне извещений, касающихся работы SSL.
лак и данные любого другого приложения, использующего SSL, сообщения про-
сэкола извещения сжимаются и шифруются в соответствии с параметрами те-
кущего состояния.
Любое сообщение, генерируемое в рамках данного протокола, состоит из
;зух байтов (рис. 7.5, б). Первый байт содержит значение, обозначающее соот-
ветственно уровень предупреждения (1) или уровень неустранимой ошибки (2).
Если указан уровень неустранимой ошибки, протокол SSL немедленно разрывает
Глава 7. Защита Web
263
соединение. Другие соединения данного сеанса могут продолжать существовать,
но установить новое соединение для данного сеанса будет уже невозможно. Вто-
рой байт содержит код, обозначающий конкретный смысл извещения. Сначала
перечислим извещения, указывающие на неустранимую ошибку (в соответствии
со спецификациями SSL).
• unexpected_message. Получено непригодное для обработки сообщение.
• bad_record_mac. Получено неправильное значение МАС.
• decompression_failure. Функция распаковки сжатых данных получила не-
правильные входные данные (т.е. данные невозможно распаковать или дли-
на получаемых в результате распаковки данных оказывается больше мак-
симально допустимой).
• handshake_failure. Отправитель не смог согласовать с получателем парамет-
ры защиты на основе имеющихся возможностей.
• illegal_parameter. Значение поля в сообщении квитирования выходит за рамки
допустимого диапазона или не согласуется со значениями других полей.
Кроме указанных, имеются следующие извещения.
• close_notify. Извещает получателя о том, что отправитель больше не будет
отправлять сообщения с использованием данного соединения. Чтобы кор-
ректно закрыть режим записи любого соединения, отправить извещение
close_notify перед закрытием соединения должна каждая из сторон.
• no_sertificate. Может отправляться в ответ на запрос о наличии сертифика-
та, если у отвечающей стороны соответствующего сертификата нет.
• bad_sertificate. Полученный сертификат поврежден (т.е. содержит подпись,
верификацию которой выполнить не удалось).
• unsupported_sertificate. Тип полученного сертификата не поддерживается.
• sertificate_revoked. Сертификат был отозван подписавшим его объектом.
• sertificate_expired. Срок годности сертификата истек.
• sertificate_unknown. При обработке сертификата возникли какие-то другие
проблемы, вследствие чего его использование оказывается невозможным.
Протокол квитирования
Самым сложным в стеке протоколов SSL является протокол квитирования
(Handshake Protocol). Этот протокол позволяет серверу и клиенту выполнить
взаимную аутентификацию, а также согласовать алгоритмы шифрования, вы-
числения МАС и криптографические ключи, которые будут применяться для
защиты данных, пересылаемых в записи SSL. Протокол квитирования должен
использоваться до начала пересылки данных прикладных программ.
В рамках протокола квитирования генерируется несколько сообщений, ко-
торыми обмениваются клиент и сервер. Все они имеют формат, показанный на
рис. 7.5, в. Любое такое сообщение содержит три следующих поля.
• Тип (1 байт). Указывает один из 10 допустимых типов сообщения. Допус-
тимые типы сообщений приведены в табл. 7.2.
264
Часть II. Приложения сетевой защиты
• Длина (3 байт). Длина сообщения в байтах.
• Содержимое (> 1 байта). Параметры, связываемые с сообщением данного
типа (см. табл. 7.2).
Таблица 7.2. Типы сообщений протокола квитирования
Тип сообщения Параметры
hello_request Нет
client_hello Версия, случайные значения, идентификатор сеанса, комплект шифров, метод сжатия
server_hello Версия, случайные значения, идентификатор сеанса, комплект шифров, метод сжатия
certificate Цепочка сертификатов X.509v3
server_key_exchange Параметры, подпись
certificate_request Тип сертификата, названия уполномоченных объектов
server_done Нет
certificate_verify Подпись
cl ient_key_exchange Параметры, подпись
finished Хэш-код
На рис. 7.6 показана схема обмена сообщениями при установке логического
соединения между клиентом и сервером. Процесс обмена можно представить со-
стоящим из следующих четырех основных этапов.
Этап 1. Определение характеристик защиты
На этом этапе приводится инициализация логического соединения и оп-
ределяются связанные с ним характеристики защиты. Процесс инициируется
клиентом, который отправляет серверу сообщение client_hello со следующими
параметрами.
• Версия. Наивысший номер версии SSL, поддерживаемый клиентом.
• Случайное значение. Генерируемая клиентом случайная структура, со-
держащая 32-битовый штамп даты/времени и 28 байт, полученных с по-
мощью защищенного генератора случайных чисел. Эти значения исполь-
зуются в качестве оказий во время обмена ключами с целью защиты от
атак воспроизведения.
• Идентификатор сеанса. Идентификатор переменной длины для данного се-
анса. Ненулевое значение говорит о намерении клиента обновить параметры
имеющегося соединения или создать новое соединение в рамках того же се-
анса. Нулевое значение говорит о том, что клиент намерен создать новое со-
единение в новом сеансе.
• Комплект шифров. Список, содержащий наборы криптографических алго-
ритмов, поддерживаемых клиентом, перечисленные в порядке убывания их
приоритета. Каждый элемент списка (каждый комплект шифров) определя-
Глава 7. Защита Web
265
ет алгоритм обмена ключами и спецификации шифра (CipherSpec), кото-
рые будут описаны ниже.
• Метод сжатия. Список методов сжатия, поддерживаемых клиентом.
Клиент
Сервер
Определяют характеристики защиты,
включая номер версии протокола,
идентификатор сеанса, комплект шифров,
метод сжатия и исходные случайные числа.
Время
Сервер может передать сертификат,
сообщение обмена ключами и запрос
сертификата. Сервер сигнализирует
об окончании фазы приветственного
сообщения.
Клиент передает сертификат, если он
был запрошен. Клиент передает
сообщение обмена ключами.
Клиент может передать сообщение
верификации сертификата.
Смена комплекта шифров
и завершение работы
протокола квитирования.
Замечание. Серым цветом отмечены
сообщения, являющиеся необязательными
зависящими от ситуации, а потому не всегд;
посылаемые в ходе рассматриваемого
здесь обмена данными.
Рис. 7.6. Схема работы протокола квитирования
После отправки сообщения client_hello (приветствие клиента) клиент ожидает
от сервера сообщения serverjiello (приветствие сервера), которое содержит те же
параметры, что и сообщение client_hello. Для сообщения server_hello действуют
следующие соглашения. Поле Version (версия) содержит номер низшей версии,
266
Часть II. Приложения сетевой защиты
поддерживаемой клиентом, и высшей версии, поддерживаемой сервером. Поле
Random (случайное значение) генерируется сервером и не связано со значением
поля Random в сообщении клиента. Если значение поля SessionlD
(идентификатор сеанса) в сообщении клиента было отличным от нуля, то же
значение использует и сервер. В противном случае поле SessionlD в сообщении
сервера содержит значение идентификатора для нового сеанса. В поле
CipherSuite (комплект шифров) определяется один комплект шифров, выбран-
ный сервером из списка, предложенного клиентом. В поле Compression
(сжатие) определяется метод сжатия, выбранный сервером из списка, предло-
женного клиентом.
Первым элементом поля CipherSuite определяется метод обмена ключами
(т.е. метод, на основе которого будет происходить обмен ключами для схем тра-
диционного шифрования и вычисления значений МАС). Протокол SSL поддер-
живает следующие методы обмена ключами.
• RSA. Секретный ключ шифруется с помощью открытого ключа RSA полу-
чателя. Для этого отправителю должен быть доступен сертификат открыто-
го ключа получателя.
• Метод Диффи-Хеллмана с фиксированными параметрами (Fixed Diffie-
Hellman). Метод обмена ключами по схеме Диффи-Хеллмана, при котором
сертификат сервера содержит открытые параметры алгоритма Диффи-
Хеллмана, подписанные центром сертификации. Иными словами, соответ-
ствующий сертификат содержит параметры открытого ключа алгоритма
Диффи-Хеллмана. Клиент сообщает свои параметры открытого ключа алго-
ритма Диффи-Хеллмана либо в сертификате, если требуется аутентифика-
ция клиента, либо в сообщении обмена ключами.
• Метод Диффи-Хеллмана с одноразовыми параметрами (Ephemeral Diffie-
Hellman). Этот метод применяется для создания “эфемерных” (временных,
одноразовых) секретных ключей. В этом случае стороны обмениваются от-
крытыми ключами Диффи-Хеллмана, подписанными личным ключом (RSA
или DSS) отправителя. Получатель для проверки подписи может использо-
вать соответствующий открытый ключ. Для аутентификации открытых
ключей применяются сертификаты. Этот метод является самым безопасным
из трех указанных здесь вариантов метода Диффи-Хеллмана, так как в ре-
зультате получается временный аутентифицированный ключ.
• Анонимный метод Диффи-Хеллмана (Anonymous Diffie-Hellman). Предпо-
лагает использование базового алгоритма Диффи-Хеллмана, но аутентифи-
кация не выполняется. Иными словами, каждая из сторон отправляет свои
открытые параметры для алгоритма Диффи-Хеллмана другой стороне без
аутентификации. Данный подход оказывается уязвимым к атакам
“внедрения посредника”, когда с обеими сторонами по анонимному методу
Диффи-Хеллмана обмен ключами проводит противник.
• Fortezza. Метод, используемый в схеме шифрования Fortezza.
Затем следует элемент CipherSpec (параметры шифрования), состоящий из
следующих полей.
Глава 7. Защита Web
267
• CipherAlgoritm. Алгоритм шифрования: любой из ранее упоминавшихся ал-
горитмов (RC4, RC2, DES, 3DES, DES40, IDEA, Fortezza).
• MACAlgorithm. Алгоритм вычисления MAC: MD5 или SHA-1.
• CipherType. Тип шифра: Stream (поточный) или Block (блочный).
• IsExportable. Признак экспортируемости: True (истина) или False (ложь).
• HashSize. Длина хэш-кода; 0, 16 (для MD5) или 20 (для SHA-1) байт.
• Key Material. Параметры вычисления ключей: последовательность байтов,
содержащих данные, используемые при генерировании ключей записи.
• IV Size. Длина инициализационного значения для шифрования в режиме
СВС (режим сцепления шифрованных блоков).
Этап 2. Аутентификация и обмен ключами сервера
Данный этап начинается с отправки сервером его сертификата, если требу-
ется аутентификация сервера. Отправляемое сообщение содержит сертификат
Х.509 или цепочку таких сертификатов. Сообщение certificate (сертификат) тре-
буется для любого из предлагаемых методов обмена ключами, кроме анонимного
метода Диффи-Хеллмана. Обратите внимание на то, что при использовании ме-
тода Диффи-Хеллмана с фиксированными параметрами сообщение сертификата
играет роль сообщения обмена ключами, поскольку в нем содержатся предла-
гаемые сервером открытые параметры алгоритма Диффи-Хеллмана.
Затем при необходимости может быть отправлено сообщение
server_key_exchange (обмен ключами сервера). Отправка такого сообщения не
требуется в двух случаях: (1) когда сервер отправил сертификат для метода
Диффи-Хеллмана с фиксированными параметрами, и (2) когда предлагается
использовать схему обмена ключами RSA. Сообщение server_key_exchange не-
обходимо тогда,, когда используются следующие схемы.
• Анонимный метод Диффи-Хеллмана. Сообщение содержит два глобальных
значения, необходимые для использования метода Диффи-Хеллмана
(некоторое простое число и его первообразный корень), а также открытый
ключ сервера для алгоритма Диффи-Хеллмана (см. главу 3; рис. 3.10).
• Метод Диффи-Хеллмана с одноразовыми параметрами. Сообщение содер-
жит такие же три параметра, как и в анонимном методе Диффи-Хеллмана,
а кроме того, подпись для этих параметров.
• Обмен ключами по схеме RSA, когда сервер имеет ключ RSA только для
подписи. В этом случае у клиента нет возможности сразу передать секрет-
ный ключ, зашифрованный открытым ключом сервера. Сервер должен соз-
дать временную пару ключей RSA (открытый/личный ключи) и использо-
вать сообщение server_key_exchange, чтобы передать открытый ключ клиенту.
Сообщение включает два параметра временного открытого ключа RSA
(значения показателя степени и модуля; см. главу 3, рис. 3.8), а также под-
пись для этих параметров.
• Fortezza.
268
Часть II. Приложения сетевой защиты
Здесь необходимо сказать еще несколько слов о подписи. Обычно подпись
создается с помощью вычисления хэш-кода сообщения с последующим ее шиф-
рованием открытым ключом отправителя. В данном случае хэширование опре-
деляется формулой
hash(ClientHello.random || ServerHello.random || ServerParams).
Функция хэширования вычисляется для аргумента, включающего не только пара-
метры Диффи-Хеллмана или RSA, но и обе оказии из оригинальных сообщений
приветствия. Это обеспечивает защиту от атак воспроизведения сообщений и атак
фальсификации ответа. Для подписи DSS хэш-код вычисляется с помощью алгорит-
ма SHA-1. Если применяется подпись RSA, вычисляется два хэш-кода (и с помощью
MD5, и с помощью SHA-1), а затем используется конкатенация полученных хэш-
кодов (36 байт), которая шифруется с помощью открытого ключа сервера.
После этого неанонимный сервер (т.е. сервер, не использующий анонимный
метод Диффи-Хеллмана) может запросить сертификат клиента. Сообщение
certificate_request (запрос сертификата) включает два параметра: certificate..type (тип
сертификата) и certificate_authorities (центры сертификации). Тип сертификата ука-
зывает применяемый алгоритм шифрования с открытым ключом и может быть
следующим.
• RSA, только для подписи.
• DSS, только для подписи.
• RSA для метода Диффи-Хеллмана с фиксированными параметрами (в этом
случае подпись обеспечивает только аутентификацию, выполняемую с по-
мощью отправки сертификата, подписанного по методу RSA).
• DSS для метода Диффи-Хеллмана с фиксированными параметрами (тоже
обеспечивает только аутентификацию).
• RSA для метода Диффи-Хеллмана с одноразовыми параметрами.
• DSS для метода Диффи-Хеллмана с одноразовыми параметрами.
• Fortezza.
Вторым параметром сообщения certificate_request является список имен до-
пустимых центров сертификации.
Последним (и единственным обязательным) сообщением второго этапа явля-
ется сообщение server_done, свидетельствующее о завершении фазы приветствия
сервера. Это сообщение не имеет параметров. После отправки этого сообщения
сервер переходит в режим ожидания ответа клиента.
Этап 3. Аутентификация и обмен ключами клиента
Получив сообщение server_done, клиент должен убедиться в том, что сервер пре-
доставил действительный сертификат (если это требуется), и что параметры сообще-
ния server_hello являются приемлемыми. Если проверка завершается успешно, клиент
оправляет серверу одно или несколько сообщений, речь о которых пойдет ниже.
Если сервер запросил сертификат, клиент начинает данный этап с отправки
серверу сообщения certificate. Если у клиента подходящего сертификата нет, кли-
ент отправляет вместо него уведомление no_certificate (нет сертификата).
Глава 7. Защита Web
269
Следующим идет сообщение client_key_exchange (обмен ключами клиента),
которое для этого этапа является обязательным. Содержимое этого сообщения
зависит от выбранного метода обмена ключами и может быть следующим.
• RSA. Клиент генерирует 48-байтовый предварительный, ключ и шифрует
его с помощью открытого ключа из сертификата сервера или с помощью
временного ключа RSA из сообщения server_key_exchange. Этот предваритель-
ный ключ позволяет вычислить главный ключ, как будет показано ниже.
• Метод Диффи-Хеллмана с одноразовыми параметрами, или анонимный
метод Диффи-Хеллмана. Отправляются открытые параметры клиента для
метода Диффи-Хеллмана.
• Метод Диффи-Хеллмана с фиксированными параметрами. В данном случае
открытые параметры клиента для метода Диффи-Хеллмана уже были от-
правлены в сообщении certificate, поэтому содержимое данного сообщения
оказывается пустым.
• Fortezza. Отправляются параметры клиента для алгоритма Fortezza.
В завершение данного этапа клиент может отправить сообщение
certificate_verify (проверка сертификата), чтобы обеспечить средства прямой
верификации сертификата клиента. Это сообщение отправляется вслед за
сертификатом клиента, поддерживающим подпись (т.е. вслед за любым сер-
тификатом клиента, кроме тех, которые содержат параметры Диффи-
Хеллмана с фиксированными параметрами). Сообщение включает подпись
хэш-кода предыдущего сообщения, вычисленную следующим образом.
CertificateVerify.signature.md5_hash
MD5(master_secret || pad_2 || MD5(handshake_messages || master_secret || pad_l)),
Certivicate. signature. sha_hash
SHA(master_secret || pad_2 || SHA(handshake_messages || master_secret || pad_l)),
где pad_l и pad_2 представляют значения, определенные выше для МАС,
handshake_messages обозначает все сообщения протокола квитирования, отправ-
ленные и полученные с момента отправки сообщения client_hello (за исключением
самого этого сообщения), a master_secret — секретный ключ, вычисляемый по
схеме, которая будет приведена ниже. Если личный ключ пользователя является
ключом DSS, он используется для шифрования хэш-кода SHA-1. Если же лич-
ный ключ является ключом RSA, то такой ключ используется для шифрования
результата конкатенации хэш-кодов MD5 и SHA-1. В любом случае цель — про-
верить наличие у клиента личного ключа его сертификата. Если даже кто-то и
воспользуется сертификатом клиента, он не сможет отправить такое сообщение.
Этап 4. Завершение
Этот этап завершает создание защищенного соединения. Клиент отправляет
сообщение change_cipher_spec (изменение параметров шифрования) и копирует
параметры CipherSpec состояния ожидания в поле CipherSpec текущего со-
стояния. Обратите внимание на то, что это сообщение не считается частью про-
токола квитирования, а отсылается в рамках протокола изменения параметров
шифрования (Change Cipher Spec Protocol). В ответ клиент немедленно отправ-
ляет сообщение finished, шифрованное новым алгоритмом с новыми ключами и
270
Часть II. Приложения сетевой защиты
секретными значениями. Сообщение finished подтверждает, что процессы обмена
ключами и аутентификации завершились успешно. Содержимое сообщения
finished представляет собой конкатенацию следующих двух значений хэш-кода.
MD5(master_secret || pad_2 || MD5(handshake_messages || Sender || master_secret || pad_l)),
SHA(master_secret || pad_2 || SHA(handshake_messages |l Sender || master_secret || pad_l)),
где Sender обозначает код, указывающий на то, что отправителем является кли-
ент, a handshake_messages включает все сообщения квитирования, за исключением
данного сообщения.
В ответ на эти два сообщения сервер посылает свое сообщение
change__cipher_spec, переводит параметры CipherSpec состояния ожидания в те-
кущее состояние и посылает свое сообщение finished. На этом процесс квитирова-
ния завершается, и теперь клиент и сервер могут начать обмен данными на
уровне приложения.
Криптографические вычисления
Следующими представляющими интерес вопросами являются создание в
ходе обмена ключами общего главного секретного ключа и генерирование с по-
мощью этого ключа криптографических параметров.
Создание главного секретного ключа
Совместно применяемый главный секретный ключ представляет собой од-
нократно используемое 48-байтовое значение (384 бит), генерируемое для данно-
го сеанса в ходе защищенного обмена ключами. Создание главного ключа состо-
ит из двух этапов. На первом этапе согласуется значение предварительного клю-
ча (pre_master_secret), а на втором обе стороны вычисляют значение главного
ключа (master_secret). Для передачи друг другу значения pre_master_secret у сторон
имеется два варианта.
• RSA. Генерируемый клиентом 48-байтовый ключ pre_master_secret шифруется
с помощью открытого ключа RSA сервера и отправляется клиентом серве-
ру. Сервер дешифрует полученный шифрованный текст с помощью своего
личного ключа и восстанавливает значение pre_master_secret.
• Метод Диффи-Хеллмана. И клиент, и сервер генерируют открытые ключи
для алгоритма Диффи-Хеллмана. После обмена этими ключами каждая
сторона выполняет определенные вычисления по методу Диффи-Хеллмана,
в результате которых получается совместно используемое значение
pre_master_secret.
Теперь обе стороны могут вычислить значение master_secret по схеме
master_secret - MD5(pre_master_secret || SHA('A' |[ pre_master_secret ||
ClientHello.random || ServerHello.random)) ||
MD5(pre_master_secret || SHAfBB' || pre_master_secret ||
ClientHello.random || ServerHello.random)) ||
MD5(pre_master_secret || SHA('CCC || pre_master_secret ||
ClientHello.random || ServerHello.random)),
Глава 7. Защита Web
271
где ClientHello.random и ServerHello.random являются значениями оказий, входящих
в оригинальные сообщения приветствия сторон.
Генерирование криптографических параметров
Для поля CipherSpecs требуются секретный ключ МАС клиента для запи-
си, секретный ключ МАС сервера для записи, ключ клиента для записи, ключ
сервера для записи, вектор инициализации клиента для записи и вектор ини-
циализации сервера для записи. Все эти параметры генерируются из главного
ключа с помощью применения функции хэширования к главному ключу для по-
лучения защищенной последовательности байтов достаточной длины.
Процедура генерирования ключей из главного ключа аналогична процедуре
генерирования главного ключа из предварительного и показана ниже.
key_block = MD5(master_secret || SHA('A' || master_secret ||
ServerHello.random || ClientHello.random)) ||
MD5(master_secret || SHA('BB' || master_secret||
ServerHello.random||ClientHello.random)) ||
MD5(master_secret || SHA('CCC' || master_secret ||
ServerHello.random || ClientHello.random)) || ...
Процедура выполняется до тех пор, пока не будет сгенерирована последователь-
ность достаточной длины. Эта алгоритмическая структура представляет собой
псевдослучайную функцию. Значение master_secret можно рассматривать как ини-
циализирующее значение для этой функции. Сгенерированные клиентом и сер-
вером случайные числа можно рассматривать как значения модификаторов (salt
values), используемых с целью усложнения криптоанализа (подробнее использо-
вание модификаторов описано в главе 9).
Защита транспортного уровня
Протокол TLS представляет результат инициативы IETF, целью которой
является разработка стандарта SSL для Internet. Текущая версия проекта стан-
дарта TLS, определенная в документе RFC 2246, очень похожа на SSLv3. В сле-
дующих разделах мы рассмотрим различия между TLS и SSLv3.
Номер версии
Формат записи TLS аналогичен формату записи SSL (см. рис. 7.4), и поля
заголовка имеют те же смысл и назначение. Единственное различие состоит в
представлении значений, задающих номера версии. Для текущего проекта стан-
дарта TLS значением поля главного номера версии (Major Version) является 3, а
значением поля дополнительного номера версии (Minor Version) — 1.
Код аутентичности сообщения
Схемы вычисления значений МАС протоколов SSLv3 и TLS отличаются по
двум параметрам: применяемому алгоритму и области данных, для которых вы-
числяется значение МАС. В протоколе TLS используется алгоритм НМАС, опре-
деленный в RFC 2104. Вспомните, обратившись к главе 3, что алгоритм НМАС
определяется формулой
272
Часть II. Приложения сетевой защиты
НМАСК = Н[(К+ © opad) || Н[(К+ © ipad) || MJ] ,
где
Н — встроенная функция хэширования (для TLS это MD5 или SHA-1),
М — сообщение, подаваемое на вход алгоритма НМАС,
К+ — секретный ключ, дополненный слева нулями, чтобы в результате
длина полученного значения равнялась длине блока хзш-кода (для
MD5 и SHA-1 длина блока равна 512 бит),
opad — значение 00110110 (равное 36 в шестнадцатеричном формате), по-
вторенное 64 раза (512 бит),
ipad — значение 01011100 (равное 5С в шестнадцатеричном формате), по-
вторенное 64 раза (512 бит).
В протоколе SSLv3 применяется такой же алгоритм, но байты заполнителя
добавляются к секретному ключу с помощью операции конкатенации, а не свя-
зываются с дополненным до нужной длины секретным ключом с помощью опе-
рации XOR (исключающее “ИЛИ”). Уровень защищенности в обоих случаях ока-
зывается одинаковым.
В TLS процесс вычисления МАС охватывает поля, указанные в следующем
выражении.
HMAC_hash(MAC_write_secret, seq_num || TLSCompressed.type ||
TLSCompressed.version || TLSCompressed.length || TLSCompressed.fragment)).
Здесь для вычисления значения МАС используются все поля, задействован-
ные при вычислении МАС в протоколе SSLv3, а также поле TLSCompressed.version,
указывающее версию применяемого протокола.
Псевдослучайная функция
В протоколе TLS применяется псевдослучайная функция, обозначаемая PRF
(pseudorandom function) и предназначенная для размещения в блоках данных
секретных значений, используемых при генерировании ключей или проверке их
подлинности. Целью ее применения является получение относительно небольшо-
го по длине совместно используемого сторонами секретного значения для гене-
рирования более длинных блоков данных, защищенных от определенных типов
атак на функции хэширования и вычисления значений МАС. В основе функции
PRF лежит следующая схема расширения данных (рис. 7.7):
P_hash(secret, seed) = HMAC_hash(secret, A(l) || seed) ||
HMAC_hash(secret, А(2) || seed) ||
HMAC_hash(secret, А(3) || seed) || ...,
где А() определяется как
А(0) = seed,
А(<) = HMAC_hash(secret, А(< -1)),
seed обозначает инициализирующее значение, a secret — секретное значение.
Глава 7. Защита Web
273
Seed
Длина равна длине хэш-кода
Рис. 7.7. Функция P_hash(secret, seed) протокола TLS
Функция расширения данных использует алгоритм НМАС с лежащей в его ос-
нове функцией хэширования (MD5 или SHA-1). Как видно из приведенной выше
схемы, функцию P_hash можно итерировать необходимое число раз до получения
блока данных нужной длины. Например, если для получения 64-байтового блока
данных применяется P_SHA-1, то для получения 80 байт данных, из которых 16 по-
следних байтов будут отброшены, эту функцию нужно будет использовать повторно
4 раза. В такой же ситуации при использовании P_MD5 также потребуется четыре
итерации, но в результате будет получено ровно 64 байт данных. Обратите внимание
на то, что на каждой итерации алгоритм НМАС выполняется дважды и каждый раз
дважды выполняется лежащий в его основе алгоритм хэширования.
Для того чтобы сделать функцию PRF защищенной в максимальной мере, в
ней предусмотрено два разных алгоритма хэширования, что гарантирует защи-
щенность данной функции, пока по крайней мере один из этих алгоритмов оста-
ется защищенным. Функция PRF определена следующим образом.
PRF(secret, label, seed) = P_MD5(S1, label || seed) ® P_SHA-1(S2, label || seed).
274
Часть II. Приложения сетевой защиты
На вход функции PRF поступает секретное значение, идентифицирующая мет-
ка и инициализирующее значение, а на выход подается блок данных любой подхо-
дящей длины. Выходное значение получается путем разделения секретного значения
на две части (S1 и S2) и применения к каждой из этих частей функции P_hash, при-
чем при обработке одной части используется алгоритм MD5, а другой части — SHA.
Два полученных значения связываются операцией XOR (исключающее “ИЛИ”), в
результате чего получается выходное значение (чтобы для связывания операцией
XOR получились блоки данных одинаковой длины, обычно для P_MD5 требуется ис-
пользовать большее число итераций, чем для P_SHA-1).
Коды извещений
Протокол TLS поддерживает все типы извещений, определенные для SSLv3,
за исключением извещения no_certificate (нет сертификата). Но для TLS определен
целый ряд дополнительных кодов извещения. Следующие дополнительные коды
всегда означают неустранимую ошибку.
• decription__failed. Шифрованный текст дешифрован неправильно: либо его
длина оказалась не кратной заданной длине блока, либо при проверке вы-
яснилось, что некорректны значения заполнителя.
• record_pverflow. Получена запись TLS с полезным грузом (шифрованным
текстом), длина которого превышает 214 + 2048 байт, либо после дешифрова-
ния длина текста оказалась больше 2!4 + 1024 байт.
• unknown_ca. Получена достоверная цепочка сертификата или ее часть, но
сертификат не был признан, так как сертификат соответствующего центра
сертификации не был найден, или сертификат оказалось невозможным со-
поставить с известным надежным центром сертификации.
• access_denied. Получен действительный сертификат, но в процессе приме-
нения средств управления доступом отправитель принял решение не про-
должать переговоры.
• decode_error. Сообщение не может быть декодировано, так как одно из по-
лей содержит значение, выходящее за рамки допустимого диапазона, или
длина сообщения оказалась неправильной.
• export_restriction. В процессе переговоров было выявлено, что нарушаются
экспортные ограничения на длину ключа.
• protocol_version. Номер версии протокола, предложенного клиентом в про-
цессе переговоров, распознан, но не поддерживается.
• insufficient_security. Возвращается вместо handshake_failure (аварийное за-
вершение процесса квитирования) в тех случаях, когда переговоры завер-
шаются аварийно, поскольку сервер требует более защищенных шифров,
чем те, которые поддерживаются клиентом.
• internal_error. Возникла не связанная со второй стороной или коррект-
ностью работы протокола внутренняя ошибка, не позволяющая продол-
жить процесс.
Ниже перечислены остальные дополнительные извещения.
Глава 7. Защита Web
275
• decrypt_error. Аварийное завершение некоторой криптографической опера-
ции, выполняемой в ходе переговоров, например, операции проверки под-
писи, дешифрования данных обмена ключами или проверки подлинности
сообщения finished.
• user_cancelled. Процесс завершен по некоторой причине, не связанной с ра-
ботой протокола.
• no_renegotiation. Отсылается клиентом в ответ на запрос hello (приветствие)
или сервером в ответ на запрос hello клиента после инициализации процесса
переговоров. В обычной ситуации такой запрос приводит к возобновлению
переговоров, но получение данного извещения указывает на то, что его от-
правитель не может возобновить переговоры. Данное сообщение всегда яв-
ляется предупреждением.
Пакеты шифров
Протоколы SSLv3 и TLS имеют следующие небольшие различия в исполь-
зуемых ими комплектах шифров.
• Обмен ключами. TLS поддерживает все методы обмена ключами, реализо-
ванные в SSLv3, за исключением Fortezza.
• Алгоритмы симметричной схемы шифрования. В TLS включены все алго-
ритмы симметричной схемы шифрования, за исключением Fortezza.
Типы сертификатов клиента
Для TLS определены следующие типы сертификатов, запрашиваемых в со-
общении certificate_request (запрос сертификата): rsa_sign, dss_sign, rsa_fixed_dh и
dss_fixed_dh. Все эти типы определены и для SSLv3. Кроме того, протокол SSLv3
поддерживает типы rsa_ephemeral_dh, dss_ephemeral_dh и fortezza_kea. В алгоритме
Диффи-Хеллмана с одноразовыми параметрами предполагается подпись пара-
метров Диффи-Хеллмана с помощью RSA или DSS. В протоколе TLS этой функ-
ции соответствуют типы rsa_sign и dss_sign, поэтому вводить отдельный тип для
обозначения подписи параметров Диффи-Хеллмана не требуется. Схема Fortezza
протоколом TLS не поддерживается.
Сообщения certificate_verify и finished
В сообщении certificate_verify (проверка сертификата) протокола TLS хэш-
коды MD5 и SHA-1 вычисляются только для сообщений handshake_messages. На-
помним, что в SSLv3 при вычислении хэш-кода используются также главный
ключ и заполнители. Похоже, что добавление этих значений не увеличивает на-
дежность защиты.
Что касается сообщения finished (готово), то в TLS оно представляет со-
бой хэш-код, вычисленный с помощью совместно используемого сторонами
значения master_secret, предыдущих сообщений квитирования и метки, иден-
тифицирующей клиент или сервер. Вычисления происходят по следующей,
отличной от SSL, схеме:
PRF(master_secret, finished—label, MD5(handshake_messages) || SHA-1 (handshake_messages)),
276
Часть II. Приложения сетевой защиты
где finished_label обозначает строку “client finished” для клиента или “server finished”
для сервера.
Криптографические вычисления
Значение pre_master_secret (предварительный ключ) для TLS вычисляется так
же, как и для SSLv3. Как и в SSLv3, значение master_secret (главный ключ) для
TLS тоже вычисляется как хэш-код значения pre_master_secret и двух случайных
чисел из сообщений hello. Однако для TLS вычисления выполняются по другой
схеме, которая выглядит следующим образом:
master_secret =
PRF(pre_master_secret, "master_secret", ClientHello.random || ServerHello.random).
Алгоритм выполняется до тех пор, пока на выходе не будет получена псевдослу-
чайная последовательность длиной в 48 байт.
Вычисление блока ключей (секретные ключи МАС, сеансовые ключи шиф-
рования и векторы инициализации) выполняется по схеме
key_block -
PRF(master_secret, "key expansion",
SecurityParameters.server_random || SecurityParameters.client_random),
и вычисления продолжаются до тех пор, пока не будет сгенерирована последова-
тельность нужной длины. Как и в SSLv3, значение key_block представляет функ-
цию значения master_secret и случайных значений, сгенерированных клиентом и
сервером, но конкретный используемый для вычисления алгоритм в TLS оказы-
вается другим.
Заполнение
В SSL байты заполнителя добавляются к данным пользователя, подлежа-
щим шифрованию, в минимально необходимом количестве, достаточном для то-
го, чтобы получить общую длину данных для шифрования, кратную длине блока
шифра. В TLS разрешается добавлять любое число заполнителей (до 255 байт
включительно), лишь бы в результате длина блока данных получилась кратной
длине блока шифра. Например, если открытый текст (или сжатый открытый
текст при сжатии) вместе со значением МАС и байтом padding.length составляют
79 байт, то для заполнения может использоваться 1, 9, 17, ..., 249 байт. Изме-
няемую длину заполнения можно использовать для того, чтобы затруднить по-
пытки анализа длин передаваемых сообщений.
7.3. ПРОТОКОЛ ЗАЩИЩЕННЫХ
ЭЛЕКТРОННЫХ ТРАНЗАКЦИЙ (SET)
Протокол SET (Secure Electronic Transaction — протокол защищенных
электронных транзакций) представляет собой открытые спецификации шифро-
вания и защиты, разработанные с целью защиты транзакций, осуществляемых в
Internet с помощью пластиковых платежных карточек. Текущая версия прото-
кола, протокол SETvl, появилась в феврале 1996 года ввиду возникшей необхо-
Глава 7. Защита Web
277
димости создания стандарта защиты для кредитных карточек MasterCard и Visa.
В разработке оригинальных спецификаций участвовали многие известные ком-
пании, включая IBM, Microsoft, Netscape, RSA, Terisa и VeriSign. Начиная с
1996 года положенная в основу протокола концепция прошла тщательную про-
верку практикой, и к 1998 году на рынке появились первые продукты реализа-
ции протокола SET.
SET является не платежной системой, а набором протоколов защиты и форма-
тов данных, позволяющим некоторым защищенным образом использовать сущест-
вующую инфраструктуру платежных систем пластиковых карточек в открытых се-
тях типа сети Internet. По сути, SET обеспечивает следующие три вида сервиса.
• Создание защищенного коммуникационного канала, связывающего все уча-
ствующие в транзакции стороны.
• Обеспечение доверия с помощью цифровых сертификатов X509v3.
• Обеспечение секретности ввиду того, что информация оказывается доступной
только участникам транзакции и только тогда и там, где она необходима.
Полная спецификация SET описывается в трех книгах, опубликованных в
мае 1997 года.
• Книга 1. Описание возможностей применения (Business Description), 80 стр.
• Книга 2. Руководство программиста (Programmer’s Guide), 629 стр.
• Книга 3. Формальное определение протокола (Formal Protocol Definition),
262 стр.
Все вместе это составляет 971 страницу спецификаций. Для сравнения за-
метим, что спецификации SSLv3 занимают 63 страницы, а спецификации TLS —
71 страницу. Соответственно, в данном разделе будут приведены лишь самые
общие сведения о спецификациях SET.
Общие сведения о SET
Описание протокола SET лучше всего начать с обзора требований, выдвигае-
мых к SET, главных возможностей SET, а также роли участников транзакций,
выполняемых на основе SET.
Требования
В книге 1 спецификаций SET перечислены следующие требования, которые
должны соблюдаться при обработке платежей по кредитным картам в Internet и
других подобных сетях.
• Конфиденциальность платежа и информации о заказе. Необходимо гарантиро-
вать владельцам пластиковых карт, что данная информация надежно защище-
на и окажется доступной только тому, кому она предназначена. Конфиденци-
альность к тому же уменьшает риск обмана любой из участвующих в осуществ-
лении транзакции сторон или злоумышленных действий третьей стороны. Для
обеспечения конфиденциальности применяется шифрование.
• Гарантия целостности всех передаваемых данных означает, что в ходе переда-
чи информация, содержащаяся в сообщении SET, не претерпит никаких изме-
нений. Для обеспечения целостности служит механизм цифровой подписи.
278
Часть II. Приложения сетевой защиты
• Аутентификация предъявителя кредитной карточки как законного вла-
дельца соответствующего счета. Механизм, связывающий предъявителя
кредитной карточки с соответствующим номером счета, должен уменьшать
вероятность мошенничества и снижать общую стоимость обработки плате-
жей. Для проверки того, что предъявитель кредитной карточки является
законным владельцем соответствующего действительного счета, применяют-
ся такие средства, как цифровая подпись и сертификаты.
• Аутентификация продавца как лица, имеющего право принимать транзак-
ции по кредитным карточкам, с помощью выяснения его связи с соответ-
ствующей финансовой организацией. Это требование дополняет предыду-
щее. Владельцы платежных карт должны иметь возможность идентифици-
ровать продавцов, которым они могут направлять защищенные транзакции.
В этом случае тоже используются цифровые подписи и сертификаты.
• Гарантированное использование лучших конструктивных решений и методов
защиты для обеспечения наивысшей степени защиты всех легальных участни-
ков электронных коммерческих транзакций. Спецификации SET строятся на
применении криптографических алгоритмов и протоколов, имеющих высокий
уровень защищенности и хорошо в этом отношении проверенных.
• Независимость протокола от механизмов защиты транспортировки данных
при отсутствии каких-либо ограничений на использование таких механизмов.
SET может обеспечивать защиту, опираясь непосредственно и исключительно
на стек протоколов TCP/IP. Но при этом SET никак не влияет на работу других
механизмов защиты, таких как IPSec или SSL/TLS, и не зависит от них.
• Содействие и поддержка совместимости между прикладными программны-
ми и сетевыми продуктами разных поставщиков. Протоколы и форматы
SET не зависят от аппаратных платформ, операционных систем и про-
граммного обеспечения, предназначенного для работы в Web.
Главные возможности SET
Чтобы соответствовать описанным выше требованиям, в протоколе SET реа-
лизованы следующие возможности.
• Конфиденциальность информации. Информация о счете владельца карты и
платеже защищается во время пересылки по сети. Интересная и важная
особенность SET заключается в том, что продавец при этом не может выяс-
нить номер кредитной карточки ее владельца — эта информация оказыва-
ется доступной только выдавшему кредитную карточку банку. Для обеспе-
чения конфиденциальности используется шифрование по традиционной
схеме с помощью алгоритма DES.
• Целостность данных. Информация о платеже, посылаемая владельцем кар-
ты продавцу, содержит информацию о заказе, личные данные и инструкции
по осуществлению платежа. SET гарантирует, что содержимое соответст-
вующих сообщений не будет изменено в пути их следования. Целостность
данных достигается с помощью цифровых подписей RSA, использующих
хэш-коды SHA-1. Некоторые сообщения защищаются также с помощью ал-
горитма НМАС, использующего SHA-1.
Глава 7. Защита Web
279
• Аутентификация счета владельца карты. SET дает продавцу возможность про-
верить, является ли предъявитель кредитной карточки законным пользовате-
лем соответствующего действительного счета. Для этой цели в SET предусмот-
рено использование цифровых сертификатов X.509v3 с подписями RSA.
• Аутентификация продавца. SET позволяет владельцу карты проверить, имеет
ли продавец отношение к соответствующей финансовой организации и право
принимать платежи по кредитным карточкам. Для этой цели в SET предусмот-
рено использование цифровых сертификатов X.509v3 с подписями RSA.
Обратите внимание на то, что в отличие от IPSec и SSL/TLS протокол SET
для решения каждой конкретной задачи предлагает только по одному алгорит-
му. Это объясняется тем, что SET является единым приложением, соответст-
вующим вполне конкретному набору требований, тогда как IPSec и SSL/TLS от-
носятся к универсальным протоколам, предназначенным для поддержки широ-
кого спектра приложений.
Участники транзакций SET
Участниками транзакций, осуществляемых с помощью SET, являются сле-
дующие стороны (рис. 7.8).
• Владелец платежной карты. В среде электронных платежей индивидуаль-
ные и корпоративные потребители взаимодействуют с продавцами со своих
персональных компьютеров через Internet. Владельцем карты в данном
случае является любой зарегистрированный владелец пластиковой платеж-
ной карты (MasterCard, Visa и т.п.), выданной ему некоторым уполномо-
ченным эмитентом.
• Продавец. Продавец является лицом, у которого владелец карты может
приобрести товары или услуги. Обычно такие товары или услуги предлага-
ются на продажу на Web-узле или по электронной почте. Продавец, имею-
щий право принимать платежи по платежным картам, должен иметь соот-
ветствующие отношения с операционным центром.
• Эмитент платежной карточки. Финансовая организация (например банк),
выдавшая платежную карту соответствующему лицу (владельцу карты).
Как правило, открыть счет можно по почте или, явившись в офис эмитента,
лично. Всю ответственность по оплате задолженности владельца карты по
данной карте несет эмитент карты.
• Операционный центр (acquirer). Финансовая организация, ведущая расчеты с
продавцом, выполняющая авторизацию платежных карт и осуществляющая
соответствующие платежи. Продавцы обычно готовы принимать кредитные
карты разных видов, но не хотят иметь дело с большим числом разных' банков-
ских ассоциаций или множеством отдельных эмитентов платежных карт. Опе-
рационный центр проводит для продавца проверку того, что счет кредитной
карты является действительным, и предлагаемая покупка по стоимости не вы-
ходит за рамки допустимого кредитного лимита. Операционный центр также
выполняет электронный перевод денежных сумм на счет продавца. Впоследст-
вии операционный центр получает за это определенную компенсацию от эми-
тента карты через банковскую платежную сеть.
280
Часть II. Приложения сетевой защиты
• Шлюз платежной сети (payment gateway). Совокупность средств, контролируе-
мых операционным центром или уполномоченной им третьей стороной и ис-
пользуемых для обработки платежных сообщений продавца. Шлюз платежной
сети связывает SET и существующие банковские платежные сети, выполняя
функции авторизации и передачи платежей. Продавец обменивается сообще-
ниями SET'с шлюзом платежной сети через Internet, а шлюз платежной сети
связан непосредственно или по внутренней сети с системой обработки финансо-
вых документов соответствующего операционного центра.
• Центр сертификации (Certification Authority — СА). Объект, которому доверя-
ется выдавать сертификаты X.509v3 открытых ключей владельцев карт, про-
давцов и шлюзов платежной сети. Успешная работа SET во многом зависит от
наличия хорошо организованной инфраструктуры сертификации, доступной
для использования в соответствующих целях. Как уже говорилось в предыду-
щих главах, обычно используется иерархия центров сертификации, так что
участники системы электронных платежей могут быть сертифицированы не
только главным центром сертификации непосредственно.
Рис. 7.8. Компоненты защищенной системы электронной коммерции
Теперь опишем вкратце последовательность событий, происходящих во
время транзакции, а затем остановимся подробнее на некоторых криптографиче-
ских деталях данного процесса.
1. Покупатель открывает счет. Покупатель открывает счет кредитной карточ-
ки (например, MasterCard или Visa) в банке, осуществляющем электронные
платежи и поддерживающем SET.
Глава 7. Защита Web
281
2. Покупатель получает сертификат. После установленной процедуры провер-
ки личности покупатель получает цифровой сертификат X.509v3, подпи-
санный банком. Этот сертификат удостоверяет открытый ключ RSA поку-
пателя и срок действия этого ключа. Он также устанавливает гарантиро-
ванное банком соответствие между парой ключей покупателя и его
кредитной карточкой.
3. Продавец получает свои сертификаты. Продавец, который собирается прини-
мать оплату по платежной карточке определенного типа, должен получить два
сертификата двух своих открытых ключей: один из них будет использоваться
для цифровой подписи, а второй — для обмена ключами. Продавцу также по-
требуется копия сертификата открытого ключа шлюза платежной сети.
4. Покупатель размещает заказ. Этот процесс может предполагать, что поку-
патель сначала должен посетить Web-узел продавца, чтобы выбрать подхо-
дящий товар и определить цену. После этого покупатель отправляет про-
давцу список нужных ему товаров, а продавец в ответ высылает бланк за-
каза с указанными в нем списком выбранных товаров, ценами, общей
стоимостью заказа и номером заказа.
5. Проверка продавца. Вместе с бланком заказа продавец высылает копию
своего сертификата, чтобы покупатель имел возможность убедиться в том,
что он действительно имеет дело с настоящим продавцом.
6. Заказ и платеж отправляются продавцу. Покупатель отправляет заказ и
платежную информацию продавцу, прилагая к ним свой сертификат. Заказ
подтверждает покупку товаров, указанных в бланке заказа. Платежная ин-
формация содержит необходимые данные кредитной карточки. Платежная
информация шифруется таким образом, чтобы продавец не смог ее про-
честь. Сертификат покупателя позволяет продавцу выполнить верификацию
покупателя.
7. Продавец запрашивает авторизацию платежа. Продавец отправляет пла-
тежную информацию шлюзу платежной сети с запросом подтверждения то-
го, что доступный покупателю кредит достаточен для осуществления данно-
го платежа.
8. Продавец подтверждает заказ. Продавец отправляет покупателю подтвер-
ждение заказа.
9. Продавец доставляет товары или предоставляет услуги. Продавец органи-
зует доставку товаров или выполнение услуг покупателю.
10. Продавец запрашивает получение платежа. Этот запрос отправляется шлю-
зу платежной сети, который обрабатывает все платежные поручения.
Дуальная подпись
Прежде чем перейти к рассмотрению деталей протокола SET, мы обсудим одно
важное нововведение SET — дуальную подпись (dual signature). Дуальная подпись
позволяет связать два сообщения, предназначенные двум разным получателям. В
данном конкретном случае покупателю требуется переслать информацию о заказе
(Order Information — 01) продавцу и платежную информацию (Payment
Information — PI) банку. Продавцу не нужно знать номер кредитной карточки поку-
пателя, а банку не нужны подробности заказа. Покупатель же, разделяя эти сведе-
282
Часть II. Приложения сетевой защиты
ния, обеспечивает тем самым дополнительную защиту своих прав с точки зрения не-
вмешательства в его личную жизнь. При этом требуется связать эти сведения так,
чтобы их можно было использовать при возникновении конфликта. Связь разделен-
ных сведений требуется для того, чтобы покупатель мог доказать, что данный пла-
теж предназначен для оплаты именно этого, а не какого-то другого заказа.
Чтобы понять необходимость такой связи, предположим, что покупатель от-
правляет продавцу два подписанных сообщения — 01 (заказ) и PI (платеж), а прода-
вец пересылает сообщение PI в банк. Если продавец получит от покупателя какой-то
другой заказ, то продавец сможет заявить, что данное сообщение PI оплачивает но-
вое, а не старое сообщение 01. Связывание исключает такую возможность.
PI — платежная информация
01 — информация о заказе
Н — функция хэширования (SHA-1)
11 — конкатенация
PIMD — профиль сообщения PI
OIMD — профиль сообщения 01
POMD — профиль комбинации сообщений заказа и платежа
Е — шифрование (RSA)
KRc — личный ключ подписи покупателя
Рис. 7.9. Создание дуальной подписи
На рис. 7.9 показана схема использования дуальной подписи для решения
только что сформулированной проблемы. Сначала покупатель, используя алгоритм
SHA-1, вычисляет хэш-коды для сообщений PI и 01. Два полученных хэш-кода свя-
зываются операцией конкатенации, и для результата связывания тоже вычисляется
хэш-код. Наконец, покупатель шифрует итоговый хэш-код с использованием своего
личного ключа цифровой подписи, в результате получая дуальную подпись. Вся
процедура формально может быть записана в следующем виде:
DS = EKRc[H(H(PI)||H(OI))],
где KRC обозначает личный ключ цифровой подписи покупателя. Теперь предполо-
жим, что продавец имеет дуальную подпись (Dual Signature — DS), сообщение 01 и
профиль сообщения PI (PI Message Digest — PIMD). Кроме того, у продавца есть от-
крытый ключ покупателя, который был извлечен из сертификата покупателя. В та-
ких условиях продавец может вычислить два следующих значения:
H(PIMD||H(OI)) и DKUc[DS],
Глава 7. Защита Web
283
где KUC обозначает открытый ключ цифровой подписи покупателя. Если оба
значения оказываются равными, продавец считает, что подпись проверена. Точ-
но так же, имея DS, PI, профиль сообщения 01 (0IMD) и открытый ключ поку-
пателя, банк может вычислить
H(H(PI)||OIMD) и DKUc[DS].
И вновь, если эти значения оказываются равными, банк считает, что подпись
покупателя проверена. Подводя итог, можно сказать следующее.
1. Продавец получает сообщение 01 и выполняет проверку подписи покупателя.
2. Банк получает сообщение PI и выполняет проверку подписи покупателя.
3. Сообщения 01 и PI оказываются связанными, и покупатель может доказать
их связь.
Предположим, что продавец решит заменить сообщение 01 данной транзак-
ции другим, в надежде извлечь из этого выгоду. Для этого ему придется найти
другое сообщение 01 с точно таким же хэш-кодом 0IMD. На сегодняшний день
при использовании алгоритма SHA-1 это является практически неразрешимой
задачей. Таким образом, у продавца нет возможности связать с данным сообще-
нием PI другое сообщение 01.
Обработка платежей
Типы транзакций, поддерживаемые SET, перечислены в табл. 7.3. В данном
разделе мы рассмотрим подробно только следующие типы транзакций.
• Требование на закупку (Purchase Request).
• Разрешение на оплату (Payment Authorization).
• Получение платежа (Payment Capture).
Таблица 7.3. Типы транзакций SET
Cardholder registration (регистрация владельца карты) Владельцы платежных карт должны зарегистрировать- ся в центре сертификации, чтобы иметь возможность отправлять сообщения SET продавцам
Merchant registration (регистрация продавца) Продавцы должны зарегистрироваться в центре сер- тификации, чтобы иметь возможность обмениваться сообщениями SET с покупателями и шлюзами пла- тежной сети
Purchase request (требование на закупку) Сообщение, отправляемое покупателем продавцу, со- держащее OI для продавца и PI для банка
Payment authorization (разрешение на оплату) Последовательность сообщений, которыми обменивает- ся продавец с шлюзом платежной сети для авторизации соответствующего платежа со счета соответствующей кредитной карточки
Payment capture (получение платежа) Позволяет продавцу запросить получение соответст- вующего платежа у шлюза платежной сети
284
Часть II. Приложения сетевой защиты
Окончание табл. 7.3
Certificate inquiry and status (запрос сертификата и его статуса) Г Если центр сертификации не может быстро обработать запрос на получение сертификата, в ответ покупателю или продавцу отправляется сообщение о том, что за- прашивающей стороне нужно обратиться за ответом на запрос повторно позже. Владелец платежной карточки или покупатель посылает сообщение Certificate Inquiry для того, чтобы выяснить состояние процесса обработки его запроса сертификата и получить сертификат, если запрос был удовлетворен
Purchase inquiry (запрос на поставку) Позволяет владельцу платежной карты проверить состоя- ние процесса обработки заказа после получения ответа на сообщение о размещении заказа. Обратите внимание на то, что это сообщение содержит информацию не о недопостав- ленных товарах, а только об авторизации, проводке пла- тежей и выяснении кредитных возможностей
Authorization reversal (отзыв запроса авторизации) Позволяет продавцу изменить ранее предъявленные за- просы на разрешение произвести платеж. Если заказ не может быть выполнен вообще, продавец отзывает все данные соответствующего запроса. Если же заказ не может быть выполнен частично (например, когда по- ставка части товаров откладывается), продавец отзыва- ет часть подлежащей авторизации суммы
Capture reversal (отзыв запроса на осуществле- ние платежа) Позволяет продавцу исправить ошибки в запросах на осуществление платежа, например, если по ошибке служащего была введена неправильная сумма
Credit (кредит) Позволяет продавцу открыть кредит в отношении счета владельца платежной карточки, например, при возвра- те товара покупателем или повреждении товара в про- цессе доставки. Обратите внимание на то, что инициа- тором сообщения Credit всегда является продавец, а не владелец платежной карточки. Весь обмен данными между владельцем платежной карточки и продавцом, в результате которого открывается кредит, происходит за рамками протокола SET
Credit reversal (отзыв запроса на кредит) Позволяет продавцу изменить параметры ранее запро- шенного кредита
Payment gateway certificate request (запрос сертификата шлюза платежной сети) Позволяет продавцу запросить сертификат шлюза пла- тежной сети и получить копии текущих сертификатов ключей обмена и цифровой подписи
Batch administration (пакетное администрирование) Позволяет продавцу обмениваться информацией с шлю- зом платежной сети по вопросам, касающимся групп платежей
Error message (сообщение об ошибке) Говорит о том, что отвечающая сторона отказала в приеме сообщения по причине неверного формата по- следнего или потому, что не удалось выполнить вери- фикацию содержимого сообщения
Глава 7. Защита Web
285
Требование на закупку
До того как начать обмен данными требования на закупку (Purchase Request),
владелец платежной карточки должен завершить просмотр списка доступных то-
варов, выбрать нужные и оформить заказ. Данный предварительный этап закан-
чивается отправкой продавцом бланка заказа покупателю. Все эти предваритель-
ные операции не связаны с SET.
Обмен данными требования на закупку состоит из четырех сообщений: Initiate
Request (инициирующий запрос), Initiate Response (ответ на инициирующий запрос),
Purchase Request (требование на закупку) и Purchase Response (ответ на требование
на закупку).
Чтобы владелец платежной карточки имел возможность отправлять сооб-
щения SET продавцу, необходимо получить копии сертификата продавца и сер-
тификата шлюза платежной сети. Запросы на получение этих сертификатов со-
держатся в сообщении Initiate Request (инициирующий запрос), которое поку-
патель отправляет продавцу. Это сообщение содержит информацию о типе
кредитной карточки, используемой покупателем, идентификатор, назначенный
покупателем данной паре сообщений “запрос-ответ”, и значение оказии, при-
званное гарантировать оригинальность сообщения.
Продавец генерирует ответ и подписывает его своим личным ключом цифровой
подписи. Ответ должен включать значение оказии покупателя, другое значение ока-
зии, которое покупатель должен будет вернуть в следующем сообщении, а также
идентификатор данной транзакции. Кроме подписанного ответа, сообщение Initiate
Response (ответ на инициирующий запрос) содержит сертификат подписи продавца и
сертификат шлюза платежной сети для обмена ключами.
Владелец платежной карточки проверяет подлинность сертификатов про-
давца и шлюза платежной сети путем проверки подписей соответствующих цен-
тров сертификации, а затем создает сообщения 01 и PI. В оба эти сообщения по-
мещается идентификатор транзакции, сгенерированный продавцом. Сообщение
01 непосредственно не включает таких данных заказа, как количество или цена
товаров, а содержит ссылку на заказ, созданный в процессе обмена сообщениями
между продавцом и покупателем на этапе согласования еще до первого сообще-
ния SET. Затем владелец платежной карточки готовит сообщение Purchase
Request (требование на закупку); см. схему на рис. 7.10. Для этого владелец
платежной карточки генерирует одноразовый ключ Ks для схемы симметрично-
го шифрования. Это сообщение состоит из следующих блоков информации.
1. Информация о платеже. Пересылается продавцом шлюзу платежной сети и
содержит следующие данные.
• Данные PI.
• Дуальная подпись, вычисленная для совокупности PI и 01 и подписанная
с использованием личного ключа подписи покупателя.
• Профиль сообщения 01 (0IMD).
Значение 0IMD необходимо для того, чтобы шлюз платежной сети мог про-
верить дуальную подпись, как объяснялось выше. Все указанные элементы
шифруются с помощью Ks . Последним для данного блока информации яв-
ляется следующий элемент.
286
Часть II. Приложения сетевой защиты
+
Дуальная
подпись
OIMD
7777л
Сообщение запроса
Цифровой
PIMD
7777),
OI
подпись
Получателем
является
продавец
Сертификат
владельца
платежной
карточки
Пересылается
продавцом шлюзу
платежной
сети
PI — платежная информация
01 — информация о заказе
PIMD — профиль сообщения PI
OIMD — профиль сообщения 01
Е — шифрование (RSA для асимметричной
и DES для симметричной схем)
Ks — временный ключ симметричной
схемы шифрования
KL'b — открытый ключ банка для
обмена ключами
+
Рис. 7.10. Структура сообщения Purchase
отправляемого владельцем платежной карточки
Request (требование на закупку),
• Цифровой конверт. Формируется путем шифрования Ks с помощью от-
крытого ключа шлюза платежной сети, предназначенного для обмена
ключами. Этот элемент называется цифровым конвертом, поскольку для
того, чтобы получить возможность прочитать элементы, перечисленные
выше, этот конверт необходимо открыть (т.е. дешифровать).
Значение Ks остается продавцу неизвестным. Поэтому продавец не сможет
прочитать ничего из всей этой относящейся к платежу информации.
2. Информация о заказе. Эта информация требуется продавцу и содержит
следующие данные.
• Данные 01.
• Дуальная подпись, вычисленная для совокупности PI и 01 и подписанная
с использованием личного ключа подписи покупателя.
• Профиль сообщения PI (PIMD).
Значение PIMD необходимо для того, чтобы продавец мог проверить дуаль-
ную подпись. Заметим, что данные 01 отправляются в открытом виде.
Глава 7. Защита Web
287
3. Сертификат владельца платежной карточки. Содержит сертификат откры-
того ключа цифровой подписи владельца платежной карточки. Этот серти-
фикат необходим как продавцу, так и шлюзу платежной сети.
После получения сообщения Purchase Request продавец выполняет следующие
действия (рис. 7.11).
1. Проверяет сертификаты владельца платежной карточки с помощью содер-
жащихся в них подписей центров сертификации.
2. Проверяет дуальную подпись с помощью открытого ключа цифровой подпи-
си владельца платежной карточки. Это позволяет убедиться в том, что за-
каз не был изменен во время пересылки и был подписан владельцем пла-
тежной карточки.
3. Обрабатывает заказ и пересылает платежную информацию шлюзу платежной
сети для авторизации платежа (соответствующий процесс будет описан ниже).
4. Отправляет сообщение Purchase Response (ответ на требование на закупку)
владельцу платежной карточки.
Сообщение Purchase Response (ответ на требование на закупку) содер-
жит блок ответа, подтверждающий заказ и ссылающийся на соответствую-
щей номер транзакции. Этот блок подписывается продавцом с помощью его
личного ключа цифровой подписи. После этого блок вместе с подписью, а
также сертификат подписи продавца отправляются владельцу платежной
карточки.
Когда программное обеспечение, установленное на компьютере владельца
платежной карточки, получает сообщение Purchase Response, оно проверяет снача-
ла сертификат продавца, а затем подпись блока ответа. В конце концов, в зави-
симости от содержания ответа, выполняется соответствующее действие, напри-
мер, отображается на экране некоторое сообщение для пользователя или обнов-
ляется информация о состоянии заказа в базе данных.
Разрешение на оплату
Во время обработки заказа, поступившего от владельца платежной кар-
точки, продавец выполняет авторизацию транзакции (получение разрешения
на оплату) с помощью шлюза платежной сети. Такое получение разрешения
на оплату (авторизация платежа) означает санкционирование транзакции
эмитентом платежной карточки. Авторизация дает продавцу гарантию того,
что он получит плату за проданный товар, и поэтому продавец может выпол-
нить доставку товаров или услуг покупателю. Обмен данными для получения
разрешения на оплату формируется из двух сообщений: Authorization Re-
quest (запрос разрешения на оплату) и Authorization Response (ответ на за-
прос разрешения на оплату).
Сообщение Authorization Request (запрос разрешения на оплату), отправляемое
продавцом шлюзу платежной сети, состоит из следующих блоков информации.
1. Информация о платеже. Эта информация была получена от покупателя и
содержит следующие данные.
• Данные PI.
288
Часть II. Приложения сетевой защиты
• Дуальная подпись, вычисленная для совокупности PI и 01 и подписанная
с использованием личного ключа подписи покупателя.
• Профиль сообщения 01 (OIMD).
• Цифровой конверт.
Сообщение запроса
Пересылается
продавцом шлюзу
платежной сети
01 — информация о заказе
OIMD — профиль сообщения 01
POMD — профиль сообщения платежного поручения
D — шифрование (RSA)
Н — функция хэширования
KUC — открытый ключ подписи покупателя
> н
POMD
^ZZZZl
♦ и —WZZZA
---- OIMD
Дуальная
подпись
+
Сертификат
владельца
платежной
карточки
Сравнение
Рис. 7.11. Схема обработки сообщения Purchase Request продавцом
2. Информация авторизации. Эта информация генерируется продавцом и со-
держит следующие данные.
• Блок авторизации, включающий идентификатор транзакции, подписанный
личным ключом цифровой подписи продавца и шифрованный генерируемым
продавцом одноразовым ключом схемы симметричного шифрования.
• Цифровой конверт, сформированный путем шифрования одноразового
ключа с помощью открытого ключа шлюза платежной сети, предназна-
ченного для обмена ключами.
3. Сертификаты. Продавец включает в сообщение сертификат цифровой под-
писи владельца платежной карточки (служит для проверки дуальной под-
писи), сертификат ключа своей цифровой подписи (позволяет проверить
подпись продавца) и сертификат своего ключа для обмена ключами
(необходим для ответа шлюза платежной сети).
Глава 7. Защита Web
289
Получив эти данные, шлюз платежной сети выполняет следующие действия.
1. Проверяет все сертификаты.
2. Дешифрует сначала цифровой конверт блока данных авторизации, чтобы
получить ключ для схемы симметричного шифрования, а затем дешифрует
блок данных авторизации.
3. Проверяет подпись продавца для блока данных авторизации.
4. Дешифрует сначала цифровой конверт блока платежной информации, что-
бы получить ключ для схемы симметричного шифрования, а затем дешиф-
рует блок платежной информации.
5. Проверяет дуальную подпись блока платежной информации.
6. Проверяет совпадение идентификатора транзакции, полученного от продав-
ца, с идентификатором, включенным в состав данных PI, поступивших
(через продавца) от владельца платежной карточки.
7. Запрашивает и получает разрешение на оплату у эмитента платежной
карточки.
Получив разрешение на оплату у эмитента платежной карточки, платеж-
ный шлюз возвращает продавцу сообщение Authorization Response (ответ на
запрос разрешения на оплату). Это сообщение состоит из следующих блоков
информации.
1. Информация авторизации. Включает блок авторизации, подписанный лич-
ным ключом цифровой подписи шлюза платежной сети и шифрованный
сгенерированным шлюзом платежной сети одноразовым ключом для схемы
симметричного шифрования. Кроме того, включает цифровой конверт, со-
держащий этот одноразовый ключ, шифрованный с помощью открытого
ключа продавца, используемого для обмена ключами.
2. Информация мандата на получение платежа (capture token). Эта информа-
ция будет использована для осуществления платежа впоследствии. Данный
блок имеет ту же форму, что и предыдущий, т.е. содержит подписанный и
шифрованный мандат с цифровым конвертом. Этот мандат не обрабатывает-
ся продавцом, а должен быть просто возвращен им в том же виде шлюзу
платежной сети в запросе на оплату.
3. Сертификат. Сертификат цифровой подписи шлюза платежной сети.
Получив подтверждение авторизации платежа от шлюза платежной сети,
продавец может выполнить доставку товаров или услуг покупателю.
Получение оплаты
Чтобы получить плату за товары или услуги, продавец обращается к шлюзу
платежной сети с инициативой выполнения транзакции получения платежа, со-
стоящей из двух сообщений: сообщения запроса на получение оплаты и сообще-
ния ответа на запрос на получение оплаты.
Для сообщения Capture Request (запрос на оплату) продавец генерирует,
подписывает и шифрует блок данных запроса на оплату, включающий сумму
платежа и идентификатор транзакции. Данное сообщение должно также вклю-
чать ранее полученный (в сообщении Authorization Response) шифрованный
290
Часть II. Приложения сетевой защиты
мандат на получение платежа для данной транзакции и, кроме того, сертифика-
ты ключей продавца для цифровой подписи и обмена ключами.
Получив это сообщение, шлюз платежной сети дешифрует и проверяет блок
данных запроса на оплату, а также дешифрует и проверяет блок мандата на по-
лучение платежа. Затем проверяется соответствие между данными этих двух
блоков. После этого шлюз платежной сети создает расчетный запрос, отсылае-
мый эмитенту платежной карточки по закрытой платежной сети. В результате
этого запроса средства перечисляются на счет продавца.
Затем шлюз с помощью сообщения Capture Response (ответа на запрос
на оплату) извещает продавца о перечислении средств. Сообщение содержит
подписанный и шифрованный шлюзом блок данных ответа на запрос на оп-
лату. Кроме того, это сообщение содержит сертификат цифровой подписи
шлюза платежной сети. Программное обеспечение, установленное на компь-
ютере продавца, получив данное сообщение, сохраняет его для использова-
ния в программах учета и согласования денежных средств, поступающих от
операционного центра.
7.4. РЕКОМЕНДУЕМЫЕ ИСТОЧНИКИ
ДОПОЛНИТЕЛЬНОЙ ИНФОРМАЦИИ
Хорошими источниками информации по вопросам защиты Web являют-
ся [PUBI97] и [GARF97] (последний носит более формализованный харак-
тер). Наиболее подробным описанием SET является Книга 1 соответствующе-
го набора спецификаций, которую можно найти на Web-узлах MasterCard и
VISA, посвященных SET. Двумя другими прекрасными обзорами являются
[MACG97] и [DREW99].
DREW99 Drew, G. Using SET for Secure Electronic Commerce. Upper Saddle River.
NJ: Prentice Hall, 1999.
GARF97 Garfinkel, S., and Spafford, G. Web Security & Commerce. Cambridge, MA:
O’Reilly and Associates, 1997.
MACG97 Macgregor, R.; Ezvan, C.; Liguori, L.; and Han, J. Secure Electronic
Transactions: Credit Card Payment on the Web in Theory and Practice. IBM
RedBook SG24-4978-00, 1997. Доступна в Web по адресу:
www.redbooks.ibm.com/SG244978.
RUBI97 Rubin A.; Geer, D.; and Ranum, M. Web Security Sourcebook. New York:
Wiley, 1997.
Рекомендуемые Web-узлы
• Посвященная SSL страница Netscape. Содержит специфика-
ции SSL.
• Хартия защиты транспортного уровня (Transport Layer
Security Charter). Самые последние документы RFC и проекты
стандартов TLS.
• Посвященный SET узел MasterCard. Самые последние касающиеся
SET документы, словарь терминов и информация о приложениях.
Глава 7. Защита Web
291
• Узел Visa-Electronic Commerce. Информация, подобная той, которая пред-
ставлена на узле MasterCard.
7.5. ЗАДАЧИ
7.1. Почему в протоколах SSL и TLS предусмотрено использование отдельного
протокола изменения параметров шифрования (Change Cipher Spec Protocol), a
не просто сообщения change_cipher_spec в рамках протокола квитирования
(Handshake Protocol)?
7.2. Рассмотрите следующие угрозы безопасности Web и объясните, как каждая из
них устраняется теми или иными средствами SSL.
а. Криптоанализ на основе перебора всех вариантов. Перебор всех возможных
вариантов ключей алгоритма традиционного шифрования.
б. Анализ с использованием словаря известного открытого текста. Многие со-
общения содержат открытый текст определенного вида, например, команды
GET HTTP. Противник создает словарь, включающий все возможные вариан-
ты шифрования известного открытого текста. Перехватив шифрованное со-
общение, противник берет фрагмент шифрованного сообщения и ищет в нем
соответствующий шифрованный текст из словаря. Соответствующий текст
словаря и текст фрагмента должны быть зашифрованы одним и тем же сек-
ретным ключом. Если обнаружено несколько совпадений, предпринимаются
попытки дешифровать текст с каждым из соответствующих ключей, чтобы
выяснить, какой из них правильный. Этот метод анализа особенно эффекти-
вен при малой длине ключа (до 40 бит).
в. Воспроизведение сообщений. Противник воспроизводит ранее перехваченные
им сообщения квитирования SSL.
г. Внедрение посредника. Противник внедряется в линию обмена ключами ме-
жду клиентом и сервером как посредник, представляясь клиенту сервером, а
серверу — клиентом.
д. Кража пароля. Перехват пароля противником в потоке данных приложения
HTTP или иного приложения.
е. Фальсификация IP-адреса. Использование фальсифицированных IP-адресов в
попытке заставить главный узел принять ложные данные.
ж. Захват IP-связи. Отстранение одной из легальных сторон текущего аутенти-
фицированного соединения путем ее отключения с одновременным замеще-
нием ее противником.
з. Синхронная атака. Противник отправляет сообщения SYN (символ синхро-
низации) протокола TCP с запросом на установку соединения, но не отвечает
на завершающее сообщение, сохраняя тем самым соединение открытым.
Атакуемый модуль TCP обычно ожидает завершения процесса открытия
“полуоткрытого” соединения в течение некоторого времени, так что много-
кратно повторяющиеся сообщения SYN могут полностью парализовать работу
модуля TCP.
7.3. Основываясь на материале данной главы, можете ли вы утверждать, что полу-
чатель имеет возможность восстановить исходный порядок поступивших запи-
сей SSL, если они пришли с нарушением этого порядка? Если да, то как это
сделать? Если нет, то почему?
292
Часть II. Приложения сетевой защиты
ГЛАВА
8
Защита
сетевого
управления
8.1. Основные принципы работы SNMP
8.2. Объединения SNMPvl
8.3. SNMPv3
8.4. Рекомендуемые источники дополнительной
информации
8.5. Задачи
Сети и распределенные системы обработки данных играют исключительно
важную роль в сфере бизнеса, в правительственных и других организациях.
В рамках отдельных организаций наблюдается тенденция расширения и
усложнения сетей, поддерживающих все большее число приложений и обслужи-
вающих все большее число пользователей. По мере роста сетей становятся оче-
видными два следующих факта:
• сеть и объединяемые сетью ресурсы вместе с распределенными приложе-
ниями становятся крайне необходимыми для организации;
• возникает все больше сложностей и неполадок, которые приводят к отказам
частей сети или замедлению скорости работы сети до неприемлемого уровня.
Большая сеть просто не может быть настроена и управляться вручную.
Сложность системы заставляет использовать автоматизированные средства сете-
вого управления. Если в сети используется оборудование разных производите-
лей, необходимость применения таких средств становится еще более острой, а
задача нахождения необходимых средств управления усложняется. В связи с
этим были разработаны стандарты сетевого управления, касающиеся сервисов,
протоколов и информационных баз данных системы управления. Безусловно,
наиболее широко используемым стандартом такого типа является SNMP (Simple
Network Management Protocol — простой протокол сетевого управления).
Со времени его публикации в 1988 году, протокол SNMP находил свое при-
менение во все большем числе сетей и во все более сложных средах. По мере
распространения SNMP возникала необходимость в новых функциональных воз-
можностях, отражающих новые требования. В частности, стала очевидной важ-
ность обеспечения защиты как неотъемлемой части сетевого управления. С це-
лью расширения функциональных возможностей была разработана версия 2
протокола SNMP.1 Усовершенствования защиты были опубликованы в SNMPv3.
Эта глава описывает элементарные средства защиты, доступные в SNMPvl, а
также значительно более совершенные средства защиты, предлагаемые в SNMPv3.
8.1. ОСНОВНЫЕ ПРИНЦИПЫ РАБОТЫ SNMP
В этом разделе предлагается обзор базовой структуры SNMP.
Архитектура сетевого управления
Система сетевого управления представляет собой совокупность инструмен-
тальных средств сетевого мониторинга и управления, интегрированных в единое
целое и предлагающих решение следующих задач.
• Обеспечение единого рабочего интерфейса с широкими возможностями, но
дружественным набором команд, позволяющих выполнять большинство или
все задачи сетевого управления.
• Использование уже имеющегося оборудования путем внедрения в него допол-
нительных аппаратных средств и программного обеспечения управления сетью.
1 Версия 2 обозначается аббревиатурой SNMPv2. А чтобы отличать первую вер-
сию от второй, оригинальную версию теперь обозначают SNMPvl.
294 Часть II. Приложения сетевой защиты
Система сетевого управления состоит из дополнительных аппаратных средств и
программного обеспечения, используемых вместе с имеющимися сетевыми компо-
нентами. Программное обеспечение, выполняющее функции сетевого управления,
размещается в хостах и процессорах связи (например, коммуникационных процессо-
рах, терминальных групповых контроллерах). Система сетевого управления должна
отображать всю архитектуру сети с адресами и метками, присвоенными каждой точ-
ке сети, и конкретными атрибутами всех элементов и соединений, известных систе-
ме. Регулярное поступление информации о состоянии сети в центр сетевого управле-
ния обеспечивается активными элементами сети.
Модель сетевого управления, используемая для SNMP, состоит из следую-
щих ключевых элементов:
• станция управления,
• агент управления,
• информационная база системы управления,
• протокол сетевого управления.
Станция управления обычно представляет собой автономное устройство, но
может быть и набором возможностей, реализованных в общедоступной системе.
В любом случае станция управления выполняет роль интерфейса между челове-
ком в лице сетевого администратора и системой сетевого управления. Станция
управления должна иметь, как минимум, следующие возможности.
• Набор управляющих приложений для анализа данных, восстановления по-
сле сбоев и т.п.
• Интерфейс, с помощью которого сетевой администратор может осуществ-
лять мониторинг сети и управление сетью.
• Возможность перевода требований сетевого администратора в реальные дей-
ствия мониторинга и управления в удаленных точках сети.
• Наличие базы данных с информацией, извлеченной из информационных баз
систем управления всех управляемых объектов сети.
Объектами стандартизации SNMP являются только два последних элемента это-
го списка.
Другим активным элементом системы сетевого управления является агент
управления. Ключевые элементы платформы, такие как хосты, мосты, маршру-
тизаторы и концентраторы, могут поддерживать SNMP, чтобы ими можно было
управлять со станции управления. Агент управления отвечает на запросы ин-
формации, исходящие со стороны станции управления, реагирует на запросы
действия станции управления и может асинхронно обеспечить станцию управле-
ния важной информацией без соответствующего запроса.
Для управлении ресурсами в сети каждый ресурс считается объектом. Объект,
по сути, является переменной, представляющей один из аспектов управляемого
агента. Совокупность объектов называется информационной базой системы управ-
ления (Management Information Base — MIB). База MIB рассматривается станцией
управления как совокупность точек доступа к агенту. Объекты этой базы данных
стандартны для всех систем одного класса (например, все мосты поддерживают одни
и те же объекты управления). Станция управления осуществляет мониторинг, из-
Глава 8. Защита сетевого управления
295
влекая соответствующие значения объектов MIB. Станция управления может ини-
циировать выполнение определенных действий агентом или же изменить конфигу-
рацию агента путем изменения значений конкретных объектов.
Станция управления и агенты связываются протоколом сетевого управле-
ния. Протокол, используемый для управления сетями TCP/IP, называется SNMP
(Simple Network Management Protocol — простой протокол сетевого управления).
Этот протокол предлагает следующие ключевые возможности.
• Get (получение). Позволяет станции управления выяснять значения объек-
тов в агенте.
• Set (установка). Позволяет станции управления устанавливать значения
объектов в агенте.
• Notify (уведомление). Позволяет агенту известить станцию управления о
наступлении важных событий.
Архитектура протокола сетевого управления
Спецификации SNMP были опубликованы в 1988 году и быстро преврати-
лись в основной стандарт сетевого управления. Некоторые поставщики предла-
гают автономные рабочие станции сетевого управления на базе SNMP, а очень
многие поставщики мостов, маршрутизаторов, рабочих станций и персональных
компьютеров предлагают пакеты агентов SNMP, позволяющих управлять соот-
ветствующими продуктами со станций управления SNMP.
В соответствии со своим названием SNMP является простым средством се-
тевого управления. Этот стандарт определяет ограниченную и легко реализуемую
информационную базу данных системы управления (MIB), состоящую из ска-
лярных переменных и двумерных таблиц, а также соответствующий протокол,
дающий администратору возможность получать и устанавливать переменные
MIB, а агенту — генерировать извещения, называемые прерываниями, которые
создаются без запроса. Эта простота и является основным преимуществом SNMP.
SNMP легко реализуется и потребляет минимум процессорных и сетевых ресур-
сов. Структуры протокола и MIB тоже достаточно просты, что позволяет относи-
тельно просто достичь согласованности действий между станциями управления и
программным обеспечением агентов самых разных производителей.
Тремя основными спецификациями являются следующие.
• Структура и идентификация информации системы управления для сетей
на базе TCP/IP (документ RFC 1155). Описывает способ определения управ-
ляемых объектов MIB.
• Информационная база системы управления для межсетевой среды на базе
TCP/IP: MIB-П (документ RFC 1213). Определяет управляемые объекты MIB.
• Простой протокол сетевого управления (документ RFC 1157). Определяет
протокол, используемый для управления этими объектами.
SNMP является протоколом прикладного уровня в составе набора протоколов
TCP/IP. Он предназначен для работы над UDP, как определено в документе
RFC 768. Для автономной станции управления процесс администратора управляет
доступом к центральной структуре MIB в системе станции управления и обеспечива-
ет сетевому администратору интерфейс доступа. Процесс администратора дает воз-
296
Часть II. Приложения сетевой защиты
можность управлять сетью с помощью реализации SNMP над UDP, IP и соответст-
вующими специальными сетевыми протоколами (например, Ethernet, FDDI, Х.25).
Каждый агент тоже должен поддерживать SNMP, UDP и IP. Кроме того,
имеется процесс агента, интерпретирующий сообщения SNMP и управляющий
структурой MIB агента. Для устройства-агента, поддерживающего другие при-
ложения (например FTP), наряду с UDP может потребоваться поддержка TCP.
На рис. 8.1 показано содержимое протокола SNMP. В системе станции
управления от приложения управления исходит три типа сообщений SNMP:
GetRequest, GetNextRequest и SetRequest. Первые два сообщения являются
вариантами функции Get. Все три сообщения подтверждаются агентом в форме
сообщения GetResponse, передаваемого приложению управления. Кроме того,
агент может генерировать сообщение прерывания в ответ на событие, изменяю-
щее MIB и воздействующее на соответствующие управляемые ресурсы.
Поскольку SNMP опирается на UDP, который является протоколом, не
предполагающим установления соединений, SNMP тоже не предполагает соеди-
нений. Не поддерживается никаких исходящих соединений между станцией
управления и ее агентами. Вместо этого каждый обмен сообщениями между
станцией управления и агентом рассматривается как отдельная транзакция.
Модули-посредники
В SNMPvl все агенты (так же, как и станции управления) должны поддержи-
вать UDP и IP. Это ограничивает возможности прямого управления только такими
Глава 8. Защита сетевого управления
297
устройствами и не позволяет управлять другими (например, некоторыми мостами и
модемами, не поддерживающими набор протоколов TCP/IP). Кроме того, в сети мо-
жет существовать много малых систем (персональных компьютеров, рабочих стан-
ций, программируемых контроллеров), использующих TCP/IP для поддержки своих
приложений, но для которых оказывается нецелесообразным нести дополнительный
груз поддержки SNMP, логики агента и сопровождения MIB.
Чтобы использовать устройства, не поддерживающие SNMP, было предло-
жено задействовать механизм посредничества (от английского proxy — доверен-
ность, заместитель, уполномоченный). В соответствующей схеме в качестве
уполномоченного агента одного или сразу нескольких устройств выступает неко-
торый агент SNMP, т.е. агент SNMP действует как посредник от имени пред-
ставляемых им устройств.
На рис. 8.2 показана схема архитектуры протокола, используемая чаще
всего. Станция управления посылает запросы, касающиеся состояния некоторого
устройства, уполномоченному агенту-посреднику. Агент-посредник конвертирует
каждый запрос в сообщение, соответствующее протоколу управления, исполь-
зуемому этим устройством. Получив ответ на запрос, агент передает этот ответ
станции управления. Точно так же при получении агентом от соответствующего
устройства извещения о каком-либо событии, агент-посредник посылает станции
управления соответствующее извещение в виде прерывания.
Станция
управления
Процесс
администратора
SNMP
UDP
IP
Внутренние
протоколы сети.
Агент-посредник
Функция отображения
Процесс агента Архитектура протокола, используемого представляемым устройством
SNMP
UDP
IP
Внутренние протоколы сети Внутренние протоколы сети
Представляемое
устройство
Процесс
управления
Архите ктура
протокола,
используемого
представляемым
устройством
Внутренние
протоколы сети
Рис. 8.2. Конфигурация модуля-посредника (система proxy)
SNMPv2 допускает использование не только набора протоколов TCP/IP. В
частности, SNMPv2 может использоваться в рамках набора протоколов OSI
(Open System Interconnection — взаимодействие открытых систем). Поэтому
SNMPv2 применяется для управления самыми разными сетями. Что касается
посредничества, то любое устройство, не поддерживающее SNMPv2, может
управляться только средствами proxy, и это касается даже устройств SNMPvl.
Таким образом, если в устройстве реализовано программное обеспечение агента
SNMPvl, доступ к нему может быть получен со стороны администратора
SNMPv2 только через устройство-посредник, в котором реализованы агент
SNMPv2 и программное обеспечение администратора SNMPvl.
298
Часть II. Приложения сетевой защиты
Случаи, о которых шла речь в предыдущем абзаце, в документации
SNMPv2 называются внешними отношениями посредничества (foreign proxy
relationship). Кроме того, SNMPv2 поддерживает внутренние отношения по-
средничества (native proxy relationship), при которых представляемое устройст-
во на самом деле поддерживает SNMPv2. В этом случае администратор SNMPv2
обращается к узлу SNMPv2, выступающему в качестве агента. Такой узел затем
выступает в качестве администратора при доступе к представляемому им устрой-
ству, которое теперь играет роль агента SNMPv2. Причина поддержки такого
непрямого обращения к устройствам заключается в необходимости дать пользо-
вателям возможность строить иерархические децентрализованные системы сете-
вого управления, о чем пойдет речь ниже.
SNMPv2
Привлекательность протокола SNMP заключается в его простоте. SNMP
предлагает базовый набор средств сетевого управления в рамках пакета, который
оказывается легко в реализовать и настроить. Однако по мере роста популярно-
сти протокола SNMP в сфере управления постоянно расширяющимися сетями с
постоянно растущей нагрузкой его недостатки стали совершенно очевидными.
Эти недостатки можно разделить на следующие три категории:
• отсутствие поддержки распределенного сетевого управления,
• функциональные недостатки,
• недостатки защиты.
Недостатки, относящиеся к первым двум категориям, были исправлены в
SNMPv2, описание которого было опубликовано в 1993 году, а исправленная
версия — в 1996 (сегодня это документы RFC с номерами 1901, 1904-1908,
2578 и 2579). SNMPv2 быстро нашел поддержку, и целый ряд поставщиков
объявил о выходе поддерживающих этот протокол продуктов всего через не-
сколько месяцев после публикации стандарта. Недостатки защиты были ис-
правлены в SNMPv3.
В оставшейся части этого раздела мы вкратце рассмотрим новые возможно-
сти, обеспечиваемые SNMPv2. Возможности защиты SNMPvl и SNMPv3 будут
рассмотрены подробно в разделах 8.2 и 8.3, соответственно.
Распределенное сетевое управление
В традиционной централизованной схеме сетевого управления один глав-
ный компьютер играет роль станции сетевого управления (возможно существо-
вание еще одной-двух станций управления, выполняющих роль резервных).
Остальные устройства сети содержат программное обеспечение агента и ин-
формационной базы системы управления (MIB), позволяющее осуществлять
мониторинг состояния устройств и управление ими со станции управления. По
мере расширения сети и роста интенсивности трафика такая централизованная
система в конце концов становится совершенно непригодной для использова-
ния на практике. Слишком большая нагрузка падает на станцию управления и
слишком интенсивный поток данных образуют сообщения с запросами и отве-
тами, идущими от каждого отдельного агента через всю сеть к центру управ-
ления. При таких условиях децентрализованный распределенный подход ока-
Глава 8. Защита сетевого управления
299
зывается лучшим решением (см., например, рис. 8.3). Децентрализованная
схема сетевого управления допускает наличие множества станций управления
высшего уровня, которые можно назвать серверами управления. Каждый та-
кой сервер может осуществлять непосредственное управление некоторой ча-
стью общего набора агентов. Но для большинства этих агентов сервер управле-
ния делегирует ответственность управления некоторому промежуточному ад-
министратору. Промежуточный администратор берет на себя ответственность
за осуществление мониторинга и управления агентами. Но он также играет
роль агента, обеспечивая информацией сервер управления высшего уровня и
подчиняясь его управлению. Этот тип архитектуры распределяет нагрузку бо-
лее равномерно и снижает общую интенсивность сетевого трафика.
Агент
Рис. 8.3. Пример конфигурации системы распределенного сетевого управления
SNMPv2 поддерживает или строго централизованную стратегию сетевого
управления, или распределенную. В последнем случае некоторые системы вы-
ступают как в роли администратора, так и в роли агента. В роли агента такая
система принимает команды вышестоящей системы управления. При этом одни
команды имеют отношение к локальной структуре MIB в системе агента, а дру-
гие команды требуют, чтобы агент выступал в качестве посредника при обраще-
нии к удаленным устройствам. Агент-посредник сначала играет роль админист-
ратора для доступа к информации удаленного агента, а затем — роль агента при
передаче этой информации администратору высшего уровня.
300
Часть II. Приложения сетевой защиты
Функциональные усовершенствования
В табл. 8.1 предлагается список функциональных усовершенствований,
предлагаемых SNMPv2. Обе версии протокола определяются в терминах наборов
команд, формирующих при обмене протокольные единицы данных (Protocol
Data Unit — PDU). В SNMPvl таких команд пять. Команда Get исходит от ад-
министратора к агенту с целью получения значений объектов MIB. Команда
GetNext использует то, что объекты MIB образуют древовидную структуру. Ко-
гда некоторый объект указывается в команде GetNext, агент находит в дереве
следующий объект и возвращает соответствующее значение. Команда GetNext
оказывается полезной потому, что дает возможность администратору “бродить”
по дереву агента, когда не известен точный набор объектов, поддерживаемых со-
ответствующим агентом. Команда Set позволяет администратору менять значе-
ния в системе агента, а также создавать и удалять строки в таблицах. Команда
GetResponse используется агентом для реагирования на команды администра-
тора. Наконец, команда Trap дает агенту возможность послать информацию ад-
министратору, не дожидаясь управляющего запроса. Например, агент может
быть настроен так, чтобы сообщение Trap посылалось при аварийном заверше-
нии связи или тогда, когда интенсивность трафика превышает заданный порог.
Таблица 8.1. Сравнение протокольных единиц обмена (PDU) SNMPvl и SNMPv2
SNMPvl PDU SNMPv2 PDU Направление Описание
GetRequest GetRequest От администратора к агенту Запрос значения для ка- ждого из указанных объ- ектов
GetNextRequest GetNextRequest От администратора к агенту Запрос следующего зна- чения для каждого из указанных объектов
— GetBulkR equest От администратора к агенту Запрос множества значе- ний
SetRequest SetRequest От администратора . к агенту Установка значения для каждого из указанных объектов
— InformRequest От администратора к администратору Передача информации без запроса
GetResponse Response От агента к администра- тору или от администра- тора к администратору (SNMPv2) Ответ на запрос админи- стратора
Trap SNMPv2-Trap От агента к администратору Передача информации без запроса
SNMPv2 включает все команды, имеющиеся в SNMPvl, и две новые.
Наиболее важной из них является команда Inform. Эта команда посылается
одной станцией управления другой и, подобно прерыванию, несет информа-
цию, имеющую отношение к условиям или событиям в системе отправителя.
Преимущество команды Inform заключается в том, что ее можно использовать
для создания конфигурации, в рамках которой существует возможность взаи-
Глава 8. Защита сетевого управления
301
модействия множества администраторов, разделяющих общие обязанности
управления в большой сети.
Вторая новая команда, GetBulk, позволяет администратору сразу получить
большой блок данных. В частности, с ее помощью можно пересылать заполнен-
ные данными таблицы.
И еще одно отличие: команда Get является атомарной в SNMPvl, но не яв-
ляется таковой в SNMPv2. Если команда Get SNMPvl содержит список объек-
тов, для которых запрашиваются значения, и оказывается, что по крайней мере
один из этих объектов в системе агента не существует, то будет отвергнута вся
команда. В SNMPv2 могут возвращаться частичные результаты. Не являющаяся
атомарной команда Get обеспечивает возможность более эффективного использо-
вания сетевых ресурсов администратором.
SNMPvl, как определено в документе RFC 1157, предлагает лишь элемен-
тарные средства защиты, основанные на использовании объединений.
Объединения и имена объединений
Подобно другим распределенным приложениям, сетевое управление предпо-
лагает взаимодействие ряда прикладных компонентов, поддерживающих опре-
деленный протокол. В сетевом управлении SNMP прикладными компонентами
являются приложения администратора и агента, использующие протокол SNMP.
Сетевое управление SNMP имеет некоторые особенности по сравнению с
другими распределенными приложениями. Данное приложение предполагает на-
личие отношения типа “один-множество” между администратором и множест-
вом агентов: администратор может получать и устанавливать значения объектов
агентов, а также получать прерывания от агентов. Поэтому, с точки зрения ра-
ботоспособности и управляемости системы, администратор “управляет” множест-
вом агентов. Может существовать несколько администраторов, управляющих
всеми агентами или некоторым подмножеством всех агентов. Подмножества мо-
гут при этом пересекаться.
Необходимо также иметь возможность представлять сетевое управление
SNMP как отношение типа “один-множество” между одним агентом и множест-
вом администраторов. Каждый агент управляет своей собственной локальной ба-
зой MIB и должен контролировать ее использование администраторами. Такое
управление состоит из следующих компонентов.
• Сервис аутентификации. Агент может ограничить доступ к MIB, разрешив
его только авторизованным администраторам.
• Политика доступа. Агент может определить разные привилегии доступа
разным администраторам.
• Сервис посредничества (proxy). Агент может выступать в качестве посред-
ника перед другими агентами. Это может означать использование сервиса=
аутентификации и/или политики доступа для других агентов в системе по-
средника.
302
Часть II. Приложения сетевой защиты
Все эти составляющие управления имеют отношение к защите. Если ответ-
ственность за сетевые компоненты распределяется между несколькими админи-
стративными объектами, то агентам приходится защищать себя и свои базы MIB
от нежелательного или несанкционированного доступа. Как утверждается в до-
кументе RFC 1157, SNMP при этом предлагает только примитивные и ограни-
ченные возможности защиты — использование объединений.
Объединение SNMP является отношением между агентом SNMP и множе-
ством администраторов SNMP, определяющим возможности аутентификации и
управления доступом, а также характеристики посредничества. Объединение —
это локальное понятие, определенное в системе агента. Агент устанавливает по
одному объединению для каждой необходимой комбинации аутентификации,
управления доступом и характеристик посредничества. Каждое объединение по-
лучает уникальное (в рамках этого агента) имя, и администраторы в рамках это-
го объединения должны использовать соответствующее имя объединения при
выполнении всех операций get и set. Агент может установить несколько объе-
динений, причем каждый администратор не обязательно должен входить только
в одно из таких объединений.
Поскольку объединения определяются агентом локально, одно и то же имя
может использоваться разными агентами. Совпадение имен при этом не имеет
никакого значения и не указывает на какое бы то ни было сходство между кон-
кретными объединениями. Поэтому администратор должен следить за именем
или именами объединений для всех агентов, к которым администратору необхо-
димо иметь доступ.
Сервис аутентификации
Цель службы аутентификации SNMPvl — предоставить получателю гаран-
тии в том, что сообщение SNMPvl исходит от указанного в сообщении источни-
ка. SNMPvl предусматривает только тривиальную схему аутентификации. Каж-
дое сообщение (запрос get или set), направляемое от администратора к агенту,
включает имя объединения. Это имя служит паролем, и сообщение считается
подлинным, если отправитель знает этот пароль.
При такой ограниченной форме аутентификации многие сетевые админист-
раторы неохотно решаются на использование средств, отличных от мониторинга,
для которого требуются только операции get и trap. Сетевое управление с ис-
пользованием операции set, очевидно, весьма уязвимо с точки зрения безопас-
ности. Имя объединения может использоваться для активизации процедуры ау-
тентификации, и тогда оно выполняет функции пароля первой линии защиты.
Процедура аутентификации может предполагать применение шифрова-
ния/дешифрования, чтобы обеспечить более надежную защиту. Эти вопросы ос-
таются за пределами темы документа RFC 1157.
Политика доступа
С помощью определения объединения агент разрешает доступ к своей
структуре MIB только избранному множеству администраторов. Используя не-
сколько объединений, агент может обеспечить разным администраторам разные
права доступа к MIB. Такое управление доступом характеризуется следующими
двумя аспектами.
Глава 8. Защита сетевого управления
303
• Представление SNMP MIB. Подмножество объектов внутри MIB. Для каждого
объединения могут определяться свои представления MIB. Набор объектов в
представлении не обязан принадлежать одному и тому же поддереву MIB.
• Режим доступа SNMP. Элемент из множества {READ-ONLY, READ-WRITE}
(только для чтения, чтение и запись). Режим доступа определяется для ка-
ждого объединения.
Комбинация представления MIB и режима доступа называется профилем
объединения SNMP. Таким образом, профиль объединения складывается из оп-
ределенного подмножества MIB в системе агента и режима доступа к соответст-
вующим объектам. Режим доступа SNMP применяется одновременно ко всем
объектам данного представления MIB. Так, если выбран режим доступа READ-
ONLY, то это относится ко всем объектам представления и ограничивает доступ
администраторов в рамках этого представления только операциями чтения.
Профиль объединения получает каждое объединение, определенное агентом.
Комбинация объединения SNMP и профиля объединения SNMP называется по-
литикой доступа SNMP. На рис. 8.4 приводится иллюстрация только что обсуж-
давшихся концепций.
Группа
Агент администраторов
SNMP SNMP
Представление Режим
MIB SNMP доступа SNMP
Объединение SNMP
(имя объединения)
Профиль объединения
SNMP
Политика доступа
SNMP
Рис. 8.4. Принципы администрирования SNMPvl
Сервис посредничества
Понятие объединения оказывается полезным и для поддержки сервиса по-
средничества. Напомним, что посредником является агент SNMP, выступающий
от имени других устройств. Обычно другие устройства являются инородными,
т.е. не поддерживают TCP/IP и SNMP. В некоторых случаях представляемая
система может поддерживать SNMP, и тогда посредничество используется для
того, чтобы свести к минимуму взаимодействие между представляемым устрой-
ством и системами сетевого управления.
Для каждого устройства, представляемого системой-посредником, эта сис-
тема реализует соответствующую политику доступа SNMP. Таким образом, сис-
тема-посредник знает, какие объекты MIB могут использоваться для управления
представляемой системой (представление MIB) и каков режим доступа к ним.
304
Часть II. Приложения сетевой защиты
8.3. SNMPv3
В 1998 году рабочая группа IETF по созданию SNMPv3 опубликовала набор
предлагаемых стандартов Internet. Соответствующие спецификации нашли свое
отражение в документах RFC с номерами от 2570 до 2575. Этот набор докумен-
тов определяет схему использования средств защиты в рамках общих возможно-
стей SNMPvl или SNMPv2. Эти документы определяют также некоторый кон-
кретный набор возможностей сетевой защиты и управления доступом.
Важно осознавать, что SNMPv3 — это не просто замена SNMPvl и/или
SNMPv2. SNMPv3 определяет возможности использования средств защиты в сово-
купности со средствами SNMPv2 (предпочтительно) или SNMPvl. Кроме того, доку-
мент RFC 2571 описывает архитектуру, в рамках которой должны рассматриваться
все текущие и будущие версии SNMP. Документ RFC 2575 описывает средства
управления доступом, которые, как предполагается, должны действовать независимо
от возможностей ядра SNMPv3. В этом разделе мы предлагаем обзор возможностей,
определяемых в документах RFC с номерами от 2570 до 2575.
На рис. 8.5 с помощью соответствующих форматов показана связь между
различными версиями SNMP. Обмен информацией между станцией управления
и агентом происходит в форме сообщений SNMP. Связанная с защитой обработка
данных происходит на уровне сообщения. Так, например, SNMPv3 определяет
модель USM (User Security Model — пользовательская модель защиты), предпо-
лагающую использование полей заголовка сообщения. Полезным грузом сообще-
ния SNMP является протокольная единица обмена (PDU) SNMPvl или SNMPv2.
PDU указывает тип действия (например, получение или установка значений
управляемого объекта) и список переменных, связанных с этим действием.
Обработка PDU
(SNMPvl hmiSNMPv2)
SNMP PDU
Обработка сообщения
(модель USM SNMPvS)
|УЗ-МН| SNMP PDU
UDP
IP
I UDP-h|V3-MH I SNMP PDU~
| IP-H | UDP-H|V3-MH | SNMP PDU
IP-H — заголовок IP
UDP-H — заголовок UDP
V3-MH — заголовок сообщения SNMPv3
PDU — протокольная единица обмена
Рис. 8.5. Архитектура протокола SNMP
Документы RFC с номерами от 2570 до 2575 описывают общую архитекту-
ру, а также структуру конкретных сообщений и возможности защиты, но не оп-
ределяют новый формат SNMP PDU. Таким образом, в рамках новой архитекту-
Глава 8. Защита сетевого управления
305
ры может использоваться существующий формат протокольной единицы обмена
SNMPvl или SNMPv2. Реализация протокола, называемая SNMPv3, складыва-
ется из средств защиты и особенностей архитектуры, определяемых в докумен-
тах RFC с номерами от 2570 до 2575, а также формата PDU и соответствующих
функциональных возможностей, определяемых в документах SNMPv2. В доку-
менте RFC 2570 это формулируется так: “SNMPv3 можно воспринимать как
SNMPv2 с дополнительными возможностями защиты и администрирования”.
Оставшаяся часть этого раздела имеет следующую организацию. Сначала
предлагается краткое обсуждение архитектуры SNMP, определенной документом
RFC 2571. Затем описываются средства обеспечения конфиденциальности и ау-
тентификации, предлагаемые в рамках модели USM SNMPv3. Наконец, обсуж-
даются возможности управления доступом и модель доступа, основанная на ис-
пользовании представлений (модель VACM — View-Based Access Control Model).
Архитектура SNMP
Архитектура SNMP, как это представлено документом RFC 2571, состоит из
распределенной совокупности взаимодействующих объектов SNMP. Каждый объект
реализует некоторую порцию возможностей SNMP и может выступать в качестве уз-
ла-агента, узла-администратора или некоторой их комбинации. Все объекты SNMP
состоят из совокупности модулей, взаимодействующих друг с другом с целью пре-
доставления требуемого сервиса. Такое взаимодействие можно представить в виде
модели, состоящей из множества абстрактных примитивов и параметров.
Архитектура RFC 2571 отражает ключевое требование, лежащее в основе
разработки SNMPv3, — модульность архитектуры, которая должна (1) допускать
реализацию в широком диапазоне операционных сред, когда в одних случаях
могут предполагаться минимальные по функциональным возможностям и наи-
менее дорогие решения, а в других — поддержка дополнительных функциональ-
ных возможностей для управлении большими сетями; (2) позволять продвигать
по пути стандартизации отдельные блоки архитектуры, если не будет достигнуто
консенсуса для всей структуры в целом; и (3) допускать возможность использо-
вания альтернативных моделей защиты.
Объект SNMP
Каждый объект SNMP включает свой процессор SNMP (SNMP engine). Та-
кой процессор реализует возможности отправки и приема сообщений, их аутен-
тификации и шифрования/дешифрования, а также управления доступом к
управляемым объектам. Соответствующие функции предоставляются в виде сер-
висов одному или нескольким приложениям, настроенным для работы с процес-
сором SNMP, и формируют так называемый объект SNMP.
И процессор SNMP, и поддерживаемые им приложения определяются в ви-
де совокупности отдельных модулей. Такая архитектура имеет целый ряд пре-
имуществ. Во-первых, роль объекта SNMP определяется теми модулями, кото-
рые реализованы в рамках этого объекта. При этом для агента SNMP требуется
один набор модулей, а для администратора SNMP — другой (хотя эти наборы и
перекрываются). Во-вторых, модульная структура спецификаций выливается в
соответствующую гибкость при определении различных версий каждого модуля.
Это, в свою очередь, позволяет (1) определить альтернативные или улучшенные
возможности для частей SNMP без необходимости перехода к новой версии всего
306
Часть II. Приложения сетевой защиты
стандарта в целом (например, к SNMPv4) и (2) сделать ясными стратегии пере-
хода к новым версиям и сосуществования таких версий.
Чтобы понять роль каждого модуля и их взаимосвязи, лучше всего рас-
смотреть использование этих модулей в рамках стандартных администраторов и
агентов SNMP. В данном случае термин стандартный оказывается эквивалент-
ным термину чистый и используется, чтобы подчеркнуть тот факт, что кон-
кретная реализация не обязана быть чисто администратором или агентом, а мо-
жет иметь модули, позволяющие объекту выполнять задачи как администрато-
ра, так и агента.
На рис. 8.6, в основу которого положен рисунок из документа RFC 2571,
показана блок-схема стандартного администратора SNMP. Стандартный адми-
нистратор SNMP взаимодействует с агентами SNMP с помощью отправки команд
(get, set) и приема сообщений прерываний (trap). Администратор может также
отправлять другим администраторам протокольные единицы обмена (PDU) с за-
просами Inform Request, несущими уведомления, и получать протокольные
единицы обмена с ответами Inform Response, подтверждающими прием сооб-
щений Inform Request. В соответствии с описанием SNMPv3 стандартный ад-
министратор SNMP включает три категории приложений. Приложение генерато-
ра команд осуществляет мониторинг и манипулирует данными управления уда-
ленных агентов (при этом используются PDU SNMPvl и/или SNMPv2, включая
команды Get, GetNext, GetBulk и Set). Приложение инициатора уведомлений
генерирует асинхронные сообщения (стандартный администратор для этого ис-
пользует InformRequest). Приложение получателя уведомлений обрабатывает
поступающие асинхронные сообщения, к которым относятся сообщения
InformRequest, SNMPv2-Trap и сообщения Trap SNMPvl. При поступлении
PDU типа InformRequest приложение получателя уведомлений реагирует от-
правкой PDU типа Response.
Все упомянутые выше приложения используют сервисы, предоставляемые
данному объекту процессором SNMP. Процессор SNMP выполняет следующие
общие функции.
• Принимает PDU, исходящие от приложений SNMP, выполняет необходи-
мую обработку, включая шифрование и добавление кодов аутентификации,
а затем инкапсулирует PDU в сообщения, передаваемые дальше.
• Принимает сообщения SNMP, поступающие с транспортного уровня, вы-
полняет необходимую обработку, включая аутентификацию и дешифрова-
ние, затем извлекает PDU из сообщений и передает PDU соответствующему
приложению SNMP.
В стандартном администраторе процессор SNMP содержит диспетчер, подсистему
обработки сообщений и подсистему защиты. Диспетчер представляет собой про-
стую программу управления трафиком, принимающую PDU, исходящие от при-
ложений, и выполняющую следующие функции. Для PDU диспетчер определяет
тип требуемой обработки (SNMPvl, SNMPv2c или SNMPv3) и отправляет PDU
дальше соответствующему модулю обработки сообщений в подсистеме обработки
сообщений. Эта подсистема возвращает сообщение, содержащее PDU и вклю-
чающее подходящие заголовки. Затем диспетчер отображает это сообщение в
транспортный уровень для передачи.
Глава 8. Защита сетевого управления
307
Объект SNMP
Рис. 8.6. Стандартный администратор SNMP
Поступающие сообщения обрабатываются по аналогичному сценарию. Дис-
петчер принимает сообщения с транспортного уровня и выполняет следующие
функции. Посылает сообщение соответствующему модулю обработки сообщений.
Подсистема обработки сообщений возвращает PDU из сообщения. Затем диспет-
чер передает PDU соответствующему приложению.
Подсистема обработки сообщений принимает исходящие PDU от диспетчера
и готовит их к передаче, снабжая соответствующим заголовком сообщения и
возвращая диспетчеру. Подсистема обработки сообщений принимает от диспет-
чера входящие сообщения, обрабатывая все заголовки и возвращая диспетчеру
вложенные PDU. Реализация подсистемы обработки сообщений может поддер-
живать формат сообщений, соответствующий одной из версий SNMP (SNMPvl,
SNMPv2c, SNMPv3), или содержать несколько модулей, каждый из которых
поддерживает свою версию SNMP.
Подсистема защиты выполняет функции аутентификации и шифрова-
ния. Исходящее сообщение передается подсистеме защиты подсистемой обра-
308
Часть II. Приложения сетевой защиты
ботки сообщений. В зависимости от требуемого сервиса подсистема защиты
может шифровать вложенные PDU и, возможно, некоторые поля заголовка
сообщения, а также генерировать код аутентификации, добавляя последний
в заголовок сообщения. Обработанное сообщение затем возвращается подсис-
теме обработки сообщений. Точно так же подсистема обработки сообщений
передает подсистеме защиты каждое входящее сообщение. Если необходимо,
подсистема защиты проверяет код аутентификации и выполняет дешифрова-
ние, а затем возвращает обработанное сообщение подсистеме обработки со-
общений. Реализация подсистемы защиты может поддерживать одну или не-
сколько моделей защиты. До сих пор единственной определенной моделью
защиты остается модель USM (User-Based Security Model — модель защиты
на базе пользователя) для SNMPv3, описанная в документе RFC 2574.
На рис. 8.7, в основу которого положен рисунок из документа RFC 2571,
показана блок-схема стандартного агента SNMP. Стандартный агент может со-
держать три типа приложений. Приложения модуля ответа на команды обеспе-
чивают доступ к данным управления. Эти приложения реагируют на поступаю-
щие запросы, извлекая и/или устанавливая значения управляемых объектов с
последующим генерированием PDU типа Response. Приложение инициатора из-
вещений генерирует асинхронные сообщения (для стандартного агента это будут
PDU типа SNMPv2-Trap или Trap SNMPvl). Приложение посредника передачи
передает данные от объекта к объекту.
Процессор SNMP стандартного агента содержит все компоненты, аналогич-
ные компонентам процессора SNMP стандартного администратора, а кроме того,
подсистему управления доступом. Последняя обеспечивает сервис авторизации
для контроля доступа к структурам MIB при чтении и установке параметров
объектов управления. Все службы используются на основе содержимого PDU.
Реализация подсистемы управления доступом может поддерживать одну или не-
сколько моделей управления доступом. До сих пор единственной определенной
моделью управления доступом является модель VACM (View-Based Access Con-
trol Model — модель управления доступом на базе представлений), описанная в
документе RFC 2575.
Обратите внимание на то, что связанные с защитой функции организованы
в две отдельные подсистемы — защиты и управления доступом. Это дает пре-
красный пример удачного модульного решения: эти две подсистемы выполняют
совершенно разные функции, поэтому имеет смысл осуществлять стандартиза-
цию этих областей независимо. Подсистема защиты касается конфиденциально-
сти и аутентификации и оперирует с сообщениями SNMP. Подсистема управле-
ния доступом касается авторизации доступа к информации системы управления
и оперирует с протокольными единицами обмена SNMP.
Терминология
В табл. 8.2 представлены некоторые элементы SNMP, определенные в до-
кументе RFC 2571. С каждым объектом SNMP связывается уникальный иденти-
фикатор snmpEnginelD. Для управления доступом предполагается, что каждый
объект SNMP управляет некоторым набором контекстов информации управле-
ния, каждый из которых имеет свое имя contextName, уникальное в рамках со-
ответствующего объекта. Чтобы подчеркнуть, что в рамках каждого объекта су-
ществует отдельный администратор контекстов, каждый объект связывается с
Глава 8. Защита сетевого управления
309
уникальным идентификатором contextEnginelD, а так как процессор контек-
стов однозначно соответствует процессору SNMP данного объекта, значения
contextEnginelD и snmpEnginelD идентичны. Управление доступом осуществ-
ляется в зависимости от конкретного контекста, к которому пытаются получить
доступ, и от пользователя, требующего такой доступ. Пользователь здесь высту-
пает в качестве принципала и может быть как индивидуумом, так и приложени-
ем или группой индивидуумов или приложений.
Рис. 8.7. Стандартный агент SNMP
Таблица 8.2. Терминология SNMPv3
snmpEnginelD
Уникальный идентификатор процессора SNMP, а также объекта SNMP, соответст-
вующего этому процессору. Определяется текстовым правилом с синтаксисом Octet
String.
contextEnginelD
Однозначно идентифицирует объект SNMP, способный распознать экземпляр контек-
ста с конкретным именем contextName.
310
Часть II. Приложения сетевой защиты
Окончание табл. 8.2
contextName
Идентифицирует конкретный контекст в рамках процессора SNMP. Передается как
параметр диспетчеру и подсистеме управления доступом.
scopedPDU
Блок данных, состоящий из contextBnginelD, contextName и протокольной единицы
обмена SNMP. Передается как параметр подсистеме защиты или от нее.
snmpMessageProcessingModel
Уникальный идентификатор модели обработки сообщений подсистемы обработки со-
общений. Возможными значениями являются SNMPvl, SNMPv2c и SNMPv3. Опре-
деляется текстовым правилом с синтаксисом Integer.
snnlpS ecurity Model
Уникальный идентификатор модели защиты подсистемы защиты. Возможными зна-
чениями являются SNMPvl, SNMPv2c и USM. Определяется текстовым правилом с
синтаксисом Integer.
snmpSecurityLevel
Степень защиты отсылаемых сообщений SNMP или выполняемых операций, выра-
женная в терминах наличия или отсутствия требования аутентификации и/или обес-
печения конфиденциальности. Вариантами значений являются noAuthnoPriv,
authNoPriv и authPriv. Определяется текстовым правилом с синтаксисом Integer.
principal
Объект, в интересах которого предоставляется сервис или выполняется обработка.
Принципал может быть индивидуальным пользователем, играющим конкретную
роль, множеством индивидуумов, каждый из которых играет свою роль, приложени-
ем или набором приложений, а также любой комбинацией указанных возможностей.
securityName
Воспринимаемая человеком строка, представляющая принципала. Передается как
параметр всем примитивам SNMP (диспетчеру, обработчику сообщений, защите,
управлению доступом).
Другие важные термины связаны с обработкой сообщений. Так,
snmpMessageProcessingModel определяет формат сообщения и версию SNMP
для обработки сообщения, snmpSecurityModel определяет используемую модель
защиты, a snmpSecurityLevel — сервис защиты, запрошенный для данной
конкретной операции. Пользователь может запросить или только аутентифика-
цию, или аутентификацию вместе с секретностью (шифрованием), или ничего.
Приложения SNMPv3
Сервис для модулей внутри объекта SNMP определяется в документах RFC
в терминах примитивов и параметров. Примитив определяет функцию для вы-
полнения, а параметры используются для передачи данных и контроля инфор-
мации. Эти примитивы и параметры можно рассматривать как формальный спо-
соб определения сервиса SNMP. Конкретная форма примитива зависит от реали-
зации — например, это может быть вызов процедуры. В контексте следующего
ниже обсуждения полезным оказывается рис. 8.8, в основу которого положен
рисунок из документа RFC 2571 и который показывает, как примитивы связы-
ваются вместе. На рис. 8.8, а показана последовательность событий, в результате
наступления которых приложения генератора команд или инициатора уведомле-
Глава 8. Защита сетевого управления
311
ний запрашивают отправку PDU. Впоследствии соответствующим приложениям
возвращаются ответы (эти события происходят в администраторе). На
рис. 8.8, б, показаны события, происходящие в системе агента. Иллюстрация
поясняет, как PDU из поступающего сообщения переправляется диспетчером
приложению, и как ответ приложения отражается в исходящем сообщении. Об-
ратите внимание на то, что некоторые стрелки диаграммы имеют ярлыки с име-
нами примитивов, представляющих вызов. Непомеченные стрелки представляют
возвращающиеся ответы на эти вызовы, а затенение указывает на соответствие
между вызовом и ответом.
Генератор
команд
Диспетчер
Модель
обработки
сообщений
Модель
защиты
sendPdu .
prepareOutgoingMsg
Отправка
запрос a SXMP
Прием
ответа
processResponsePdu
———-
prepare DataElements
а) генератор команд или инициатор уведомлений
Рис. 8.8. Поток SNMPv3
generate RequestMsg
------------►
-Ч--------——
processIncomingMsg
--------------►
----------
Модуль Модель
ответа обработки Модель
б) модуль ответа на команды
ч-
Документ RFC 2573 дает общее определение процедур, выполняемых при-
ложениями любого типа при генерировании PDU для отправки или обработки
входящих PDU. Эти процедуры определяются в терминах взаимодействия с дис-
петчером посредством примитивов диспетчера.
Приложение генератора команд использует примитивы диспетчера sendPdu и
processResponsePdu. При этом SendPdu обеспечивает диспетчера информацией об
адресате, параметрах защиты и PDU. Чтобы подготовить сообщение, диспетчер вы-
зывает модель обработки сообщений, которая, в свою очередь, вызывает модель за-
щиты. Диспетчер передает подготовленное сообщение на транспортный уровень
(например UDP) для передачи. Если подготовка сообщения завершается аварийно,
возвращенное значение примитива sendPdu, установленное диспетчером, укажет на
ошибку. Если подготовка сообщения завершается успешно, диспетчер приписывает
PDU идентификатор sendPduHandle и возвращает это значение генератору команд.
Генератор команд сохраняет sendPduHandle, чтобы впоследствии его можно было
сравнить с PDU ответа на исходный запрос.
312
Часть II. Приложения сетевой защиты
Диспетчер доставляет поступающие PDU ответов соответствующим прило-
жениям генератора команд, используя примитив processResponsePdu.
Приложение ответа на команды использует четыре примитива диспетчера
(registerContextEnginelD, unregisterContextEnginelD, processPdu,
returnResponsePdu) и один примитив подсистемы управления доступом
(isAccessAl lowed).
Примитив registerContextEnginelD позволяет приложению ответа на
команды ассоциироваться с процессором SNMP с целью обработки PDU опреде-
ленных типов для процессора контекстов. После регистрации модуля ответа на
команды все асинхронно полученные сообщения, содержащие соответствующую
комбинацию поддерживаемых contextEnginelD и pduType, отсылаются моду-
лю ответа на команды, зарегистрированному для поддержки такой комбинации.
Модуль ответа на команды может отменить ассоциацию с процессором SNMP,
используя примитив unregisterContextEnginelD.
Диспетчер доставляет входящие PDU запросов соответствующему приложе-
нию ответа на команды, используя примитив processPdu. Затем модуль ответа
на команды выполняет следующие шаги.
• Модуль ответа на команды проверяет содержимое PDU запроса. Тип опера-
ции должен соответствовать одному из типов, зарегистрированных этим
приложением.
• Модуль ответа на команды определяет, позволен ли доступ к операции управ-
ления, запрошенной PDU. Для этого вызывается примитив isAccessAllowed.
Параметр securityModel указывает, какую модель защиты должна использо-
вать подсистема управления доступом, отвечая на этот вызов. Подсистема
управления доступом определяет, имеет ли вызывающий принципал
(securityName) на этом уровне защиты (securityLevel) право запросить дан-
ную операцию управления (viewType) в отношении управляемого объекта
(variableName) в данном контексте (contextName).
• Если доступ разрешен, модуль ответа на команды выполняет операцию управ-
ления и генерирует PDU ответа. Если при доступе возникает ошибка, модуль
ответа на команды генерирует PDU ответа, сигнализирующий об отказе.
• Модуль ответа на команды с помощью примитива returnResponsePdu вы-
зывает диспетчера для отправки PDU ответа.
Приложение генератора извещений следует тому же набору общих проце-
дур, что и приложение генератора команд. Если необходимо послать PDU типа
Inform Request (информация запроса), используются примитивы sendPdu и
processResponsePdu, точно так же, как это было в приложении генератора ко-
манд. Если необходимо послать PDU типа прерывания, используется только
примитив sendPdu.
Приложение получателя извещений следует подмножеству набора общих
процедур, используемому приложением модуля ответа на команды. Получатель
извещений должен сначала зарегистрироваться для получения PDU типа Inform
(информация) и/или trap (прерывание). Оба типа PDU принимаются с помощью
примитива processPdu. В PDU типа Inform для ответа используется примитив
returnResponsePdu.
Глава 8. Защита сетевого управления
313
Приложение посредника передачи использует примитивы диспетчера для
передачи сообщений SNMP дальше. Посредник передачи обрабатывает следую-
щие четыре типа сообщений.
• Сообщения, содержащие типы PDU приложения генератора команд. По-
средник передачи определяет, является ли процессор SNMP конечным по-
лучателем или это процессор SNMP, ближайший или просто более близкий
к конечному получателю, и посылает PDU запроса соответствующего вида.
• Сообщения, содержащие типы PDU приложения инициатора извещений.
Посредник передачи определяет, какие процессоры SNMP должны получить
данное извещение и посылает PDU извещения соответствующего вида.
• Сообщение, содержащее PDU типа Response (ответ). Посредник передачи
определяет, какое из ранее переданных сообщений запроса или извещения
(если таковое вообще имеется) соответствует данному ответу, и посылает
PDU ответа соответствующего вида.
• Сообщения, содержащие указания отчета. PDU типа Report (отчет) исполь-
зуются в SNMPv3 для обмена данными между процессорами. Посредник
передачи определяет, какое из ранее переданных сообщений запроса или
извещения (если таковое вообще существует) соответствует данному указа-
нию отчета, и передает указание отчета источнику запроса или извещения.
Модель обработки сообщений и защиты пользователя
Для обработки сообщений используются модель обработки сообщений обще-
го назначения и конкретная модель защиты. Их связь показана на рис. 8.8.
Модель обработки сообщений
В документе RFC 2572 определяется модель обработки сообщений общего
назначения. Эта модель отвечает за прием PDU от диспетчера, инкапсуляцию
PDU в сообщения и вызов USM (модель защиты пользователя) для добавления в
заголовок сообщения параметров, связанных с защитой. Модель обработки со-
общений также принимает входящие сообщения, вызывает USM для обработки
связанных с защитой параметров в заголовке сообщения и доставляет инкапсу-
лированные PDU диспетчеру.
На рис. 8.9 показана структура сообщения. Первые пять полей генерируют-
ся моделью обработки сообщений для исходящих сообщений и обрабатываются
моделью обработки сообщений для входящих. Следующие шесть полей указы-
вают параметры защиты, используемые USM. Наконец, PDU вместе со значе-
ниями contextEnginelD и contextName составляют обрабатываемую область
PDU, используемую при обработке PDU.
Первые пять полей таковы.
• msgVersion. Устанавливается равным snmpv3 (3).
• msgID. Уникальный идентификатор, используемый двумя объектами SNMP
для координации сообщений запроса и ответа, а также процессором сооб-
щений для координации обработки сообщения различными моделями под-
систем в рамках имеющейся архитектуры. Значения идентификатора нахо-
дятся в диапазоне от 0 до 231 -1.
314
Часть II. Приложения сетевой защиты
msgVersion
msgID______________
msgMaxSize
_________msgFlags
msgSecurityModel
msgAuthoritativeEnginelD
msgAiithoritativeEngineBoots
msgAuthoritativeEngineTime
_______msgUserName__________
msgAuthenticationParameters
msgPrivacyParameters
______contextEnginelD_______
contextName
PDU
Г енерируются / обрабатываются
моделью обработки сообщений
Г еиерируются / обрабатываются
моделью защиты пользователя
(USM)
)> Обрабатываемая область PDU
(в открытой или
шифрованной форме)
Рис. 8.9. Формат сообщения SNMPv3, использующего USM
• msgMaxSize. Указывает максимальный размер сообщения в байтах, под-
держиваемый отправителем сообщения, с областью значений от 484 до
23i-l. Это максимальный размер сегмента, который отправитель может
принять от другого процессора SNMP (в ответе или в сообщении какого-то
другого типа).
• msgFlags. Строка байтов, содержащая три флага в трех младших разрядах:
reportableFlag, privFlag, authFlag. Если reportableFlag = 1, то при
условиях, которые могут вызвать генерирование PDU типа Report, отпра-
вителю возвращается PDU типа Report (отчет). Если этот флаг равен нулю,
то PDU типа Report может не посылаться. Отправитель устанавливает
ReportableFlag равным 1 в сообщениях, содержащих запрос (Get, Set), и
сообщениях типа Inform, и равным 0 в сообщениях, содержащих PDU типа
Response (ответ), Trap (прерывание) или Report. Флаг reportableFlag
является вспомогательным средством определения необходимости отправки
сообщения типа Report. Он используется только тогда, когда порцию PDU
сообщения декодировать не удается (например, когда дешифрование завер-
шается неудачей из-за неправильного ключа). Флаги PrivFlag и authFlag
используются отправителем для указания степени защиты сообщения. Зна-
чение privFlag = 1 говорит о применении средств шифрования, а значение
authFlag =1 — об использовании средств аутентификации. Разрешаются
все комбинации, кроме privFlag = 1 AND authFlag = 0, т.е. шифрование
без аутентификации не допускается.
Глава 8. Защита сетевого управления
315
• msgSecurityModel. Идентификатор с областью значений от 0 до 231 — 1, ука-
зывающий модель защиты, применявшуюся отправителем при подготовке
этого сообщения, и, следовательно, модель защиты, которую следует ис-
пользовать получателю для обработки этого сообщения. Зарезервированны-
ми значениями являются 1 для SNMPvl, 2 для SNMPv2c (SNMPv2 с воз-
можностями объединений SNMPvl) и 3 для SNMPv3.
Модель защиты пользователя
В документе RFC 2574 определяется модель USM (User Security Model —
модель защиты пользователя). USM обеспечивает сервис аутентификации и сек-
ретности в рамках SNMP. Модель USM разрабатывалась с целью защиты от уг-
роз следующих типов.
• Модификация информации. По пути следования сообщения, сгенерирован-
ного авторизованным объектом, некоторый другой объект может изменить
это сообщение, чтобы выполнить несанкционированные операции управле-
ния (например, установив соответствующие значения объекта управления).
Суть угрозы заключается в том, что несанкционированный объект может
изменить любые параметры управления, включая параметры конфигура-
ции, выполняемых действий и контроля.
• Имитация. Объект может пытаться выполнить не разрешенные для него
операции управления, отождествляя данный объект с некоторым авторизо-
ванным объектом.
• Модификация потока сообщений. Протокол SNMP предназначен для работы
над транспортным протоколом, не предполагающим установку соединений.
Существует угроза переупорядочения, задержки или воспроизведения
(дублирования) сообщений SNMP для несанкционированного управления.
Например, можно скопировать и впоследствии воспроизвести сообщение,
вызывающее перезапуск устройства.
• Разглашение информации. Наблюдая за потоком обмена данными между
администратором и агентом, объект может выяснить значения управляемых
объектов и распознать подлежащие регистрации события. Например, на-
блюдение за набором команд, изменяющих пароли, может позволить ата-
кующему узнать новые пароли.
Модель USM не предполагает защиту от угроз следующих двух типов.
• Блокирование сервиса. Противник может не допустить обмен данными ме-
жду администратором и агентом.
• Анализ трафика. Противник может анализировать общую структуру тра-
фика между администраторами и агентами.
Отсутствие средств противостояния угрозе блокирования сервиса объясняет-
ся следующими двумя причинами. Во-первых, атаки блокирования сервиса во
многих случаях неотличимы от отказов сети, с которыми обычно приходится
иметь дело любому реальному приложению сетевого управления. Во-вторых,
атака блокирования сервиса, вероятнее всего, разорвет все типы обмена данны-
ми, т.е. такая атака должна быть проблемой общих средств защиты, а не только
протокола сетевого управления. Что касается анализа трафика, то целый ряд
316
Часть II. Приложения сетевой защиты
структур такого трафика вполне прогнозируем (например, объекты могут управ-
ляться командами SNMP, генерируемыми с определенной регулярностью одной
или несколькими станциями управления), поэтому нет особой необходимости
защищаться от возможности наблюдения этих структур.
Криптографические функции
Для модели USM определяются две криптографические функции — аутентифи-
кация и шифрование. Для поддержки этих функций процессору SNMP требуются
ключ секретности (privKey) и ключ аутентификации (authKey). Поддержка значе-
ний этих двух ключей осуществляется для следующих пользователей.
• Локальные пользователи. Любой принципал в рамках данного процессора
SNMP, авторизованный для выполнения операций управления.
• Удаленные пользователи. Любой принципал удаленного процессора SNMP,
которому требуется связь.
Эти значения являются сохраняемыми атрибутами пользователя. Значения
privKey и authKey недоступны в рамках средств SNMP.
Модель USM допускает использование одного из двух альтернативных протоко-
лов аутентификации — HMAC-MD5-96 или HMAC-SHA-96. Алгоритм НМАС, опи-
санный в главе 3, использует защищенную функцию хэширования и секретный
ключ для получения кода аутентичности сообщения. В HMAC-MD5-96 в качестве
функции хэширования в алгоритме НМАС используется MD5, а на вход алгоритма
подается 16-байтовое (128-битовое) значение authKey. Алгоритм порождает 128-
битовый вывод, который усекается до 12 байт (96 бит). В HMAC-SHA-96 функцией
хэширования является SHA-1, а значение authKey имеет длину 20 байт. Алгоритм
порождает 20-байтовый вывод, который тоже усекается до 12 байт.
В модели USM для шифрования используется режим СВС (режим сцепле-
ния шифрованных блоков) алгоритма DES. На вход протокола шифрования по-
дается 16-байтовое значение privKey. Первые 8 байт (64 бит) privKey исполь-
зуются в качестве ключа DES. Поскольку для DES требуется 56-битовый ключ,
младший разряд каждого байта игнорируется. Для режима СВС требуется 64-
битовый вектор инициализации (IV). Последние 8 байт privKey содержат значе-
ние, используемое для генерирования IV.
Авторитетные и неавторитетные процессоры
При любой передаче сообщений один из двух объектов, отправитель или
получатель, рассматривается как авторитетный процессор SNMP в соответствии
со следующими правилами.
• Если сообщение SNMP содержит полезный груз, для которого требуется от-
вет (например, PDU типа Get, GetNext, GetBulk, Set или Inform), то ав-
торитетным является получатель сообщения.
• Если сообщение SNMP содержит полезный груз, для которого не ожидается
ответа (например, PDU типа SNMPv2-Trap, Response или Report), то авто-
ритетным является отправитель сообщения.
Так, для сообщений, отсылаемых от имени генератора команд, и для сооб-
щений Inform инициатора извещений авторитетным процессором является по-
Глава 8. Защита сетевого управления
317
лучатель. Для сообщений, отсылаемых от имени модуля ответа на команды, и
для сообщений Trap инициатора извещений авторитетным процессором является
отправитель. Это понятие вводится со следующей целью.
• Своевременность сообщения определяется в сравнении с часами, поддержи-
ваемыми системой авторитетного процессора. Когда авторитетный процес-
сор посылает сообщение (Trap, Response, Report), оно содержит текущее
значение его часов, чтобы неавторитетный получатель мог синхронизиро-
вать свое время с этими часами. Когда неавторитетный процессор посылает
сообщение (Get, GetNext, GetBulk, Set, Inform), он включает в сообщение
оценку текущего значения времени в точке назначения, что позволяет оце-
нить своевременность сообщения адресату.
• Процесс локализации ключей, который будет описан позже, дает возмож-
ность одному принципалу владеть ключами, хранимыми множеством про-
ч цессоров; эти ключи локализуются авторитетным процессором таким обра-
зом, что принципал отвечает только за один ключ, избегая необходимости
хранить множество экземпляров одного и того же ключа в распределенной
сети (последнее, очевидно, повышает риск нарушения защиты).
Получателя PDU генератора команд и PDU типа Inform имеет смысл счи-
тать авторитетным процессором, а следовательно, и ответственным за проверку
своевременности сообщений. Если ответ или прерывание оказываются задержан-
ными или воспроизведенными, опасность не слишком велика. Но PDU генерато-
ра команд и, отчасти, PDU типа Inform инициируют операции управления —
например, чтение или установку значений объектов MIB. Поэтому важно гаран-
тировать, что такие PDU не задерживаются и не воспроизводятся, чтобы исклю-
чить нежелательные действия.
Параметры сообщений USM
Когда процессор сообщений передает подсистеме USM исходящее сообще-
ние, подсистема USM заполняет связанные с защитой параметры в заголовке со-
общения. Когда процессор сообщений передает подсистеме USM входящее сооб-
щение, USM обрабатывает значения, содержащиеся в соответствующих полях. С
защитой связаны следующие параметры.
• msgAuthoritativeEnginelD. Значение snmpEnginelD авторитетного процес-
сора SNMP, вовлеченного в процесс обмена данного сообщения. Таким обра-
зом, это значение ссылается на источник в сообщениях Trap, Response или
Report, и на адресата — в Get, GetNext, GetBulk, Set или Inform.
• msgAuthoritativeEngineBoots. Значение snmpEngineBoots авторитетного
процессора SNMP, вовлеченного в процесс обмена данного сообщения. Объ-
ект snmpEngineBoots является целым числом из диапазона от 0 до 231-1 ,
представляющим число инициализаций и реинициализаций этого процессо-
ра SNMP с момента установки начальной конфигурации.
• msgAuthoritativeEngineTinie. Значение snmpEngineTime авторитетного
процессора SNMP, вовлеченного в процесс обмена данного сообщения. Объ-
ект snmpEngineTime является целым числом из диапазона от 0 до 231-1,
представляющим время в секундах, прошедшее с момента последнего уве-
318
Часть II. Приложения сетевой защиты
личения значения объекта snmpEngineBoots данным авторитетным процес-
сором SNMP. Каждый авторитетный процессор SNMP отвечает за увеличе-
ние своего значения snmpEngineTime раз в секунду. Неавторитетный про-
цессор отвечает за приращение своего представления snmpEngineTime для
каждого удаленного авторитетного процессора, с которым открыта связь.
• msgUserName. Пользователь (принципал), от имени которого происходит
обмен сообщениями.
• msgAuthenticationParameters. Пусто, если аутентификация для этого про-
цесса обмена не используется. Иначе представляет собой параметр аутенти-
фикации. В соответствии с используемым определением USM параметр ау-
тентификации представляет собой код аутентичности сообщения НМАС.
• msgPrivacyParameters. Пусто, если средства обеспечения секретности для
этого процесса обмена не используются. Иначе представляет собой параметр
секретности. В соответствии с существующим определением USM параметр
секретности представляет собой значение, используемое для генерирования
начального значения (IV) в режиме СВС алгоритма DES.
На рис. 8.10 показана схема функционирования USM. Перед отправкой сооб-
щения, если это необходимо, выполняется шифрование. Обрабатываемая область
PDU шифруется и размещается в блоке полезного груза сообщения, а значение
msgPrivacyParameters устанавливается равным значению, которое требуется для
генерирования IV. Затем при необходимости выполняется аутентификация. Все
сообщение, включая обрабатываемую область PDU, подается на вход алгоритма
НМАС, а полученный в результате код аутентичности помещается в
msgAuthenticationParameters. Для входящих сообщений сначала, если необхо-
димо, выполняется аутентификация. Система USM сравнивает значение МАС с
вычисленным значением МАС и, если эти два значения совпадают, сообщение счи-
тается аутентифицированным (т.е. пришедшим из соответствующего источника и
не измененным в пути следования). Затем USM проверяет, попадает ли сообщение
в рамки допустимого окна времени, что будет поясняться немного позже. Если со-
общение оказывается несоответствующим времени, оно отбрасывается как фаль-
шивое. Наконец, если обрабатываемая область PDU была зашифрована, USM вы-
полняет дешифрование и возвращает открытый текст.
Глава 8. Защита сетевого управления
319
а) передача сообщения
Рис. 8.10. Обработка сообщения в модели USM
Извлечение
параметров
сообщения
Требуется
утентификация?
Нет
Вычисление значения МАС;
сравнение с
msgAuthenticationParameters
Сверка времени ।
сообщения с допустимым
диапазоном времени '
Дешифрование scopedPdu
Нет
Требуется
секретность?
б) прием сообщения
Механизмы контроля времени USM
Модель USM включает набор механизмов контроля времени для противо-
стояния попыткам задержки и воспроизведения сообщений. Каждый процессор
SNMP, который может действовать как авторитетный процессор, должен под-
держивать два объекта, snmpEngineBoots и snmpEngineTime, ссылающиеся на
локальное время процессора. Когда процессор SNMP инициализируется, значе-
ния этих двух объектов устанавливаются равными 0. В дальнейшем значение
snmpEngineTime постоянно увеличивается на одну единицу в секунду. Когда
snmpEngineTime достигает максимального значения (231 -1), получает прираще-
ние значение snmpEngineBoots, как при перезапуске системы, а значение
snmpEngineTime устанавливается равным 0 и начинает увеличиваться снова.
Используя механизм синхронизации, неавторитетный процессор оценивает зна-
чения времени для каждого авторитетного процессора, с которым необходимо
поддерживать связь. Эти оценочные значения содержатся в каждом исходящем
сообщении и позволяют принимающему авторитетному процессору определить,
своевременно поступило сообщение или нет.
Механизм синхронизации работает следующим образом. Неавторитетный
процессор хранит локальную копию следующих трех переменных для каждого
известного ему авторитетного процессора SNMP.
• snmpEngineBoots. Самое последнее значение snmpEngineBoots для удален-
ного авторитетного процессора.
320
Часть II. Приложения сетевой защиты
• snmpEngineTime. Представление snmpEngineTime данного процессора для
удаленного авторитетного процессора. Это значение синхронизируется с
удаленным авторитетным процессором с помощью описываемого ниже про-
цесса синхронизации. Между событиями синхронизации это значение авто-
матически увеличивается на одну единицу в секунду для приблизительной
синхронизации с удаленным авторитетным процессором.
• latestReceivedEngineTime. Наибольшее значение
msgAuthoritativeEngineTinie, полученное данным процессором от уда-
ленного авторитетного процессора. Это значение обновляется каждый раз,
когда прибывает большее значение msgAuthoritativeEngineTinie. Назна-
чением этой переменной является защита от атак воспроизведения сообще-
ний, когда предпринимаются попытки не допустить увеличения значений
представления snmpEngineTime неавторитетного процессора SNMP.
Каждому процессору необходимо поддерживать по одному набору этих трех
переменных для каждого удаленного авторитетного процессора, с которыми су-
ществует связь. На практике для этих значений выделяется своего рода кэш, где
данные индексируются по уникальным значениям snmpEnginelD удаленных ав-
торитетных процессоров.
Чтобы предоставить неавторитетным процессорам возможность синхро-
низировать время, авторитетные процессоры вставляют свои текущие значе-
ния загрузки (boot) и времени (time) вместе со значением идентификатора
snmpEnginelD в поля msgAuthoritativeEngineBoots,
msgAuthoritativeEngineTinie и msgAuthoritativeEnginelD каждого исхо-
дящего сообщения типа Response, Report или Trap. Если сообщение при-
знается подлинным и попадает в рамки допустимого окна времени, то при-
нимающие неавторитетные процессоры обновляют свои локальные перемен-
ные (snmpEngineBoots, snmpEngineTime и latestReceivedEngineTime) для
соответствующего удаленного процессора по следующим правилам.
1. Обновление происходит, если по крайней мере одно из двух следующих ус-
ловий оказывается истинным:
• (msgAuthoritativeEngineBoots > snmpEngineBoots) ИЛИ
• [(msgAuthoritativeEngineBoots — snmpEngineBoots)И
(msgAuthoritativeEngineTinie > latestReceivedEngineTime)]
Первое условие говорит о том, что обновление должно быть выполнено, ес-
ли значение числа загрузок, полученное от авторитетного процессора, увеличи-
лось со времени последнего обновления. Второе условие говорит о том, что если
значение числа загрузок не возросло, то обновление должно быть выполнено, ес-
ли поступившее значение времени больше значения времени, полученного непо-
средственно перед этим. Поступившее значение времени будет меньше предыду-
щего, если сообщения прибудут в неверном порядке (что вполне возможно) или
при атаке воспроизведения. В любом случае принимающий процессор обновле-
ние выполнять не будет.
Глава 8. Защита сетевого управления
321
2. В результате вызова процедуры обновления происходят следующие изменения:
• значение snmpEngineBoots устанавливается равным значению
msgAuthoritativeEngineBoots,
• значение snmpEngineTime устанавливается равным значению
msgAuthoritativeEngineTime,
• значение latestReceivedEngineTime устанавливается равным значению
msgAuthoritativeEngineTime,
Если обратить указанную выше логику, мы увидим, что обновления не
происходит, например, когда msgAuthoritativeEngineBoots <
snmpEngineBoots. Такое сообщение считается фальсифицированным и должно
игнорироваться. Если msgAuthoritativeEngineBoots = snmpEngineBoots, но
msgAuthoritativeEngineTime < latestReceivedEngineTime, то обновления
тоже не происходит. В этом случае сообщение может быть подлинным, но при-
шедшим с нарушением порядка следования, а при этом обновление
snmpEngineTime оказывается сомнительным.
Обратите внимание на то, что синхронизация должна выполняется только то-
гда, когда для сообщения используется сервис аутентификации, и подлинность со-
общения проверена с помощью алгоритма НМАС. Это ограничение существенно, по-
скольку область действия аутентификации включает msgAuthoritativeEngineTD,
msgAuthoritativeEngineBoots и msgAuthoritativeEngineTime, гарантируя дос-
товерность этих значений.
SNMPv3 требует, чтобы сообщение было доставлено с разумной задержкой
во времени, чтобы исключалась возможность проведения атак задержки и вос-
произведения сообщений. Окно времени должно при этом быть минимальным с
учетом точности имеющихся часов, задержек связи и частоты, с которой проис-
ходит синхронизация часов. Если окно времени слишком мало, аутентичные со-
общения часто будут отвергаться, как фальсифицированные. С другой стороны,
при слишком большом окне времени повышается уязвимость системы в отноше-
нии злонамеренных задержек сообщений.
Рассмотрим более важный случай авторитетного получателя (проверка свое-
временности сообщений неавторитетным получателем в данном случае выполня-
ется аналогично лишь с незначительными вариациями). Для каждого входящего
сообщения, успешно прошедшего аутентификацию, у которого значение
msgAuthoritativeEnginelD совпадает со значением snmpEnginelD данного
процессора, процессор сравнивает значения msgAuthoritativeEngineBoots и
msgAuthoritativeEngineTime из поступившего сообщения со значениями
snmpEngineBoots и snmpEngineTime, поддерживаемыми этим процессором. По-
ступившее сообщение считается вышедшим за рамки допустимого окна времени
при выполнении любого из следующих условий:
• snmpEngineBoots = 231-1 ИЛИ
• msgAuthoritativeEngineBoots * snmpEngineBoots ИЛИ
• значение msgAuthoritativeEngineTime отличается от значения
snmpEngineTime более чем на ±150 секунд.
322
Часть II. Приложения сетевой'защиты
Первое условие гласит, что, если snmpEngineBoots достигает своего макси-
мального значения, ни одно из поступающих сообщений не может считаться
подлинным. Второе условие говорит о том, что сообщение должно содержать
значение числа загрузок равное значению числа загрузок локального процессора.
Например, если локальный процессор был перезагружен, а удаленный процессор
с тех пор не был с ним синхронизирован, то сообщения такого удаленного про-
цессора не будут считаться аутентичными. Последнее условие означает, что вре-
мя во входящем сообщении должно отличаться от локального времени не более,
чем на 150 секунд в любую сторону.
Если сообщение выходит за рамки допустимого окна времени, то считается,
что сообщение не является подлинным, и вызывающему модулю возвращается
указание на ошибку (not InTimeWindow).
Как и при синхронизации, контроль времени осуществляется только при
использовании сервиса аутентификации и при условии аутентичности сообще-
ния, когда гарантируется достоверность полей заголовка сообщения.
Локализация ключей
Требование использования сервиса аутентификации и секретности в
SNMPv3 таково, что для любой связи между принципалом в неавторитетном
процессоре и удаленным авторитетным процессором секретные ключи аутенти-
фикации и шифрования должны использоваться совместно. Эти ключи дают
возможность пользователю в системе неавторитетного процессора (обычно это
система управления) применять аутентификацию и секретность в удаленных ав-
торитетных системах, которыми он управляет (обычно это системы-агенты). До-
кумент RFC 2574 содержит общие рекомендации по поводу использования таких
ключей — их создания, обновления и управления ими.
Чтобы упростить процесс управления ключами, возлагаемый на прин-
ципала, каждому принципалу требуется поддерживать только один ключ ау-
тентификации и один ключ шифрования. Эти ключи не хранятся в структуре
MIB и не доступны в рамках SNMP. Мы рассмотрим сначала технологию
создания этих ключей из пароля. Затем обсудим понятие локализации клю-
чей, в результате которой принципал получает возможность использовать
ключи аутентификации и шифрования, уникальные для каждого удаленного
процессора. При этом необходимо поддерживать только одну пару ключей
аутентификации и шифрования локально. Две технологии, о которых идет
речь, были предложены в [BLUM97a].
Пользователю требуется 16-байтовый ключ секретности и 16- или 20-
байтовый ключ аутентификации. Для человека желательно, чтобы это были не
произвольные строки битов, а слова, которые можно прочитать. Поэтому в до-
кументе RFC 2574 определяется алгоритм отображения паролей пользователя в
16- или 20-байтовые ключи. Модель USM сама по себе не предполагает каких-
либо ограничений на пароль, но локальные политики управления требуют, что-
бы пользователи выбирали пароли, которые угадать нелегко.
Пароль при создании ключей используется следующим образом.
• На основе пароля пользователя генерируется строка байтов длиной в 220
октетов (1048576 байт) путем многократного повторения значения пароля и
усечения (при необходимости) последнего значения. Эта строка называется
Глава 8. Защита сетевого управления
323
digestO. Например, для получения digestO из 8-символьного пароля (23
байт) необходимо связать конкатенацией 217 одинаковых значений пароля.
• Если нужен 16-байтовый ключ, используется хэш-код MD5 строки digestO,
в результате чего получается digestl. Если же необходим 20-байтовый
ключ, то для получения digestl к строке digestO применяется алгоритм
хэширования SHA-1. Выводом при этом является ключ пользователя.
Одно из преимуществ этой технологии заключается в том, что сущест-
венно увеличивается время, необходимое на проведение атаки перебора всех
вариантов по словарю, когда противнику приходится проверять множество
различных потенциальных паролей, генерируя ключ для каждого из них и
выясняя, годится ли он для аутентификации или шифрования. Например,
перехватив аутентифицированное сообщение, противник может попытаться
генерировать значения НМАС с помощью самых разных ключей пользовате-
ля. Обнаружив совпадение, противник может считать, что пароль найден.
Описанный выше процесс существенно увеличивает время, необходимое для
такой атаки.
Другое преимущество этой технологии заключается в том, что она отде-
ляет ключи пользователя от системы сетевого управления (Network Manage-
ment System — NMS). Для системы сетевого управления нет необходимости
хранить значения ключей пользователя. Вместо этого, ключ пользователя
генерируется из пароля этого пользователя тогда, когда это действительно
нужно. В [BLUM97b] приводится следующий список причин, по которым ис-
пользование паролей, независимых от системы сетевого управления, оказы-
вается более предпочтительным.
• Если ключ приходится хранить, а не генерировать из пароля, то можно ис-
пользовать для этого централизованное хранилище секретных ключей. Но
это снижает общую надежность системы и затрудняет поиск неисправно-
стей, если такое хранилище окажется недоступным.
• С другой стороны, поддержка резервных хранилищ ослабляет защиту, по-
скольку у атакующего появляется больше потенциальных целей для прове-
дения атак.
• Централизованные или резервные хранилища должны размещаться в за-
щищенных местах. Это может создавать трудности в “пожарных” ситуациях
(когда сегменты сети остаются неработоспособными и/или недоступными в
течение непрогнозируемого периода времени).
Один пароль может использоваться для генерирования и ключа аутентифи-
кации, и ключа шифрования, но более надежной схемой является использование
двух паролей: одного для генерирования ключа аутентификации, а другого —
для ключа шифрования.
Локализованный ключ определяется в RFC 2574 как секретный ключ, ис-
пользуемый совместно пользователем и одним авторитетным процессором SNMP.
Целью является возможность для пользователя поддерживать только один ключ
(или только два ключа, если требуются как аутентификация, так и секретность),
и, следовательно, помнить только один пароль (или только два). Секретные зна-
чения, используемые совместно конкретным пользователем с разными автори-
тетными процессорами SNMP, в действительности оказываются различными.
324
Часть II. Приложения сетевой защиты
Процесс, в результате которого единственный ключ пользователя превращается
во множество уникальных ключей, по одному для каждого удаленного процессо-
ра SNMP, называется локализацией ключей. В [BLUM97a] предлагается приве-
денная ниже мотивация такой стратегии.
Можно определить следующие цели управления ключами.
• Каждая система агента SNMP в распределенной сети имеет собственный
уникальный ключ для каждого пользователя, авторизованного для управ-
ления этим агентом. Если управление позволено множеству пользователей,
агент имеет по уникальному ключу аутентификации и уникальному ключу
шифрования для каждого пользователя. Таким образом, если ключ одного
пользователя скомпрометирован, ключи других пользователей останутся
надежными.
• Ключи для одного пользователя в системах различных агентов отличаются.
Поэтому если некоторый агент скомпрометирован, то будут скомпрометиро-
ваны только ключи пользователя этого агента, но не ключи этого пользова-
теля для других агентов.
• Сетевое управление может осуществляться из любой точки сети, независимо
от доступности предварительно настроенной системы сетевого управления.
Это дает пользователю возможность выполнять функции управления с лю-
бой станции управления. Сама возможность обеспечивается описанным вы-
ше алгоритмом перевода паролей в ключи.
Можно также отметить следующие моменты, которых следует избегать.
• Пользователю необходимо запоминать (или обрабатывать каким-то иным
способом) большое число ключей, и это число растет по мере добавления
новых агентов, которыми необходимо управлять.
• Противник, который узнает ключ для одного агента, с этого момента может
имитировать любого другого агента перед любым пользователем или любого
пользователя перед любым другим агентом.
Чтобы решить все указанные проблемы, единственный ключ пользователя
отображается посредством необратимой односторонней функции (т.е. защищен-
ной функции хэширования) в разные локализованные ключи для разных аутен-
тифицированных процессоров (различных агентов). Процедура такова.
• Формируется строка digest2 с помощью конкатенации digestl (описанной
ранее), значения snmpEnginelD авторитетного процессора и digestl.
• Если необходим 16-байтовый ключ, применяется хэш-код MD5 строки
digest2. Если нужен 20-байтовый ключ, используется хэш-код SHA-1
строки digest2. Выводом является локализованный ключ пользователя.
Получающийся в результате локализованный ключ может быть затем раз-
мещен в системе агента некоторым защищенным способом. Благодаря односто-
ронней природе MD5 и SHA-1 противник не сможет открыть ключ пользователя,
даже выяснив значение локализованного ключа.
Схема процесса локализации ключей показана на рис. 8.11.
Глава 8. Защита сетевого управления
325
Хэширование
ключа пользователя
и удаленного
EnginelD
Локализованный
ключ
Рис. 8.11. Локализация ключей
Управление доступом на основе представлений
Управление доступом является функцией защиты, выполняемой на уровне
PDU. Документ управления доступом задает механизмы выяснения возможности
доступа к управляемому объекту в локальной структуре MIB со стороны удаленного
принципала. Могут быть определены также механизмы мультидоступа. Документы
SNMPv3 определяют модель VACM (View-Based Access Control Model — модель
управления доступом на основе представлений). Модель VACM использует структуру
MIB, на основе которой определяется политика управления доступом для данного
агента и становится возможным удаленное управление конфигурацией.
VACM имеет следующие две важные характеристики.
• VACM определяет, разрешен ли удаленному принципалу доступ к управ-
ляемому объекту в локальной структуре MIB.
• VACM использует структуру MIB, которая:
• определяет политику управления доступом для данного агента;
• делает возможным использование удаленной конфигурации.
Элементы модели VACM
В документе RFC 2575 определяется пять элементов, формирующих мо-
дель VACM, — это группа, степень защиты, контекст, представление MIB и
политика доступа.
Группа определяется как набор пар <securityModel, securityName>
(возможно, являющийся пустым), в рамках которого может осуществляться дос-
туп к объектам управления SNMP. Значение securityName указывает принци-
пала, а права доступа для всех принципалов одной группы идентичны. С каждой
326
Часть II. Приложения сетевой защиты
группой связывается уникальное значение groupName. Понятие группы оказыва-
ется полезным средством классификации администраторов по правам доступа.
Например, администраторы высшего уровня могут иметь один набор прав досту-
па, а администраторы промежуточного уровня — другой.
Любая данная комбинация securityModel и securityName может принад-
лежать не более, чем одной группе. Это значит, что для данного агента принци-
пал, чьи связи защищаются в соответствии с данным значением securityModel,
может входить только в одну группу.
Права доступа для группы могут отличаться в зависимости от степени за-
щиты сообщения, содержащего запрос. Например, агент может разрешить дос-
туп только для чтения запросу в сообщении, не прошедшем аутентификацию, но
требовать аутентификации для получения права записи. Далее, для особо защи-
щаемых объектов агент может требовать, чтобы и запрос, и ответ передавались с
использованием сервиса секретности.
Контекст MIB представляет собой именованное подмножество экземпляров
объектов в локальной структуре MIB. Контексты обеспечивают полезное средст-
во объединения объектов в семейства с различными политиками доступа.
Понятие контекста относится к сфере управления доступом. Когда станция
управления взаимодействует с агентом с целью получения доступа к информа-
ции управления агента, взаимодействие осуществляется между принципалом
администратора и процессором SNMP агента, а привилегии управления доступом
выражаются в виде представления MIB, применимого к этому принципалу и
данному контексту. Контексты имеют следующие ключевые характеристики.
• Объект SNMP, однозначно идентифицируемый значением contextEnginelD,
может поддерживать несколько контекстов.
• Объект или экземпляр объекта может появляться в нескольких контекстах.
• Если существуют множественные контексты, то для идентификации от-
дельного экземпляра объекта в дополнение к типу объекта и типу экземп-
ляра требуется идентификация значений contextName и contextEnginelD.
Для определенных групп бывает необходимо ограничить доступ к некото-
рому подмножеству управляемых объектов в системе агента. С этой целью дос-
туп к контексту осуществляется с помощью представления MIB, определяющего
конкретное множество управляемых объектов (а если необходимо, то и конкрет-
ные экземпляры объектов). Модель VACM использует мощную и гибкую техно-
логию определения представлений MIB, основанную на понятиях поддеревьев и
семейств представлений. Представление MIB определяется в терминах коллек-
ций или семейств поддеревьев, где каждое поддерево должно либо включаться в
представление, либо исключаться из него.
Управляемые объекты в локальной базе данных подчиняются иерархии, об-
разуя дерево на основе идентификаторов объектов. Такая локальная база данных
охватывает подмножество всех типов объектов, определенных в соответствии со
стандартом Internet для структур SMI (Structure of Management Information —
структура информации управления), и включает экземпляры объектов, иденти-
фикаторы которых соответствуют соглашениям SMI.
В SNMPv3 используется понятие поддерева. Поддерево представляет собой
просто вершину в иерархии имен MIB вместе со всеми подчиненными этому
имени элементами. Более формально поддерево может быть определено как
Глава 8. Защита сетевого управления
327
множество всех объектов и экземпляров объектов, которые имеют в своих име-
нах общий префикс идентификатора объекта на языке ASN.l (Abstract Syntax
Notation One — абстрактная синтаксическая нотация версии 1). Наибольший
общий префикс всех экземпляров объектов в поддереве является идентификато-
ром объекта корневой вершины этого поддерева.
С каждым элементом таблицы vacmAccessTable ассоциируются три представ-
ления MIB — для доступа чтения, записи и извещения. Каждое представление MIB
складывается из набора поддеревьев представлений. Каждое поддерево представле-
ний в представлении MIB характеризуется как включенное или исключенное. Это
значит, что любое представление MIB должно или включать, или не включать сразу
все экземпляры объектов, содержащиеся в данном поддереве. Кроме того, определя-
ется маска представления, чтобы уменьшить объем задающей конфигурацию ин-
формации, когда необходимо использовать тонкие разграничения прав доступа
(например, управление доступом на уровне экземпляра объекта).
Модель VACM дает процессору SNMP возможность определить конкретный
набор прав доступа, формирующий политику доступа. На определение прав дос-
тупа влияют следующие факторы.
• Принципал, запрашивающий доступ. Модель VACM позволяет агенту назна-
чать разным пользователям различные привилегии доступа. Например, управ-
ляющая система, отвечающая за конфигурацию всей сети, может иметь широ-
кие полномочия по изменению элементов локальной структуры MIB, в то время
как администратору промежуточного уровня с задачами мониторинга может
предоставляться доступ только для чтения и только к некоторому подмножест-
ву локальной структуры MIB. Как уже упоминалось, принципалы объединяют-
ся в группы, которым присваиваются политики доступа.
• Степень защиты, которая требуется для запроса в сообщении SNMP. Обыч-
но агент требует использования идентификации для сообщений, содержа-
щих запрос установки параметров (операцию записи).
• Модель защиты, используемая для обработки сообщения запроса. Если в систе-
ме агента реализовано несколько моделей защиты, то агент может быть настро-
ен на предоставление разных уровней доступа запросам из сообщений, обраба-
тываемых в рамках разных моделей защиты. Например, некоторые элементы
могут быть доступными, если сообщение с запросом прошло через USM, и не-
доступными, если использовалась модель защиты SNMPvl.
• Контекст MIB дня данного запроса.
• Конкретный экземпляр объекта, для которого запрашивается доступ. Неко-
торые объекты по сравнению с другими содержат более важную или секрет-
ную информацию, поэтому политика доступа может зависеть от конкретно-
го экземпляра объекта, указанного в запросе.
• Тип доступа (чтение, запись, уведомление), запрашиваемый в сообщении. Чте-
ние, запись и уведомление являются разными операциями управления, и с ка-
ждой из них могут связываться разные политики управления доступом.
Управление доступом
Приложение SNMP вызывает модель VACM с помощью примитива
isAccessAllowed с параметрами securityModel, securityName, securityLevel,
328
Часть II. Приложения сетевой защиты
viewType, contextName и variableName. Все эти параметры необходимы для того,
чтобы принять решение, касающееся управления доступом. Другими словами, под-
система управления доступом является достаточно гибким средством, в котором сис-
тема принятия решения разделяется на шесть отдельных частей.
Схема на рис. 8.12, в основу которого положен рисунок из документа
RFC 2575, является удобным инструментом для выяснения роли вводимых пе-
ременных и внутренних таблиц MIB модели VACM, участвующих в процессе
принятия решения управления доступом.
• Кто? Комбинация securityModel (модель защиты) и securityName (имя
защиты) отвечает на вопрос: кто требует данную операцию. Эта комбина-
ция идентифицирует принципала, чья связь защищается данной моделью
защиты (securityModel). Комбинация принадлежит не более, чем одной
группе в данном процессоре SNMP. Имя группы (groupName) выясняется с
помощью таблицы (vacmSecurityToGroupTable) по данным значениям
securityModel и securityName.
• Где? Значение contextName (имя контекста) указывает, где следует искать
требуемый объект управления. При этом таблица vacmContextTable со-
держит список распознаваемых значений contextName.
• Как? Комбинация securityModel и securityLevel (степень защиты) оп-
ределяет, как защищается поступающий запрос или PDU типа Inform.
Комбинация объектов кто, где и как может не соответствовать никакому
или соответствовать только одному элементу таблицы vacmAccessTable
(таблица доступа).
• Зачем? Значение viewType (тип представления) указывает, зачем требуется
доступ: для чтения, записи или уведомления. Выбранный элемент таблицы
vacmAccessTable содержит по одному значению viewName (имя представ-
ления) MIB для каждого из этих трех типов действий, и viewType исполь-
зуется для выбора конкретного viewName. Это значение viewName задает
соответствующее представление MIB из таблицы
vacmViewTreeFamilyTable.
• Какой? Значение variableName (имя переменной) является идентификато-
ром объекта, префикс которого указывает тип объекта, а суффикс — его эк-
земпляр. Тип объекта говорит о том, какой тип информации управления
запрашивается.
• Который? Экземпляр объекта указывает, который из имеющихся элемен-
тов информации запрашивается.
Наконец, значение variableName рассматривается в рамках извлеченного
представления MIB. Доступ разрешается, если значение variableName соответ-
ствует элементу, включенному в данное представление MIB.
Мотивация
Понятия, используемые при построении модели VACM, приводят к доста-
точно сложному определению управления доступом. Причиной их введения яв-
ляется необходимость полного понимания связей, используемых при доступе к
информации управления, а также минимизации вычислительной нагрузки и
Глава 8. Защита сетевого управления
329
требований к памяти в агенте. Рассмотрим следующие аргументы. В SNMPvl
понятие объединения используется для того, чтобы представить следующую свя-
занную с защитой информацию:
• идентифицирующую запрашивающий объект (станция управления);
• идентифицирующую выполняющий объект (агент, действующий от своего
имени или от имени представляемого им объекта);
Рис. 8.12. Логика VACM
• идентифицирующую размещение информации управления, к которой требу-
ется доступ (агент или представляемый им объект);
• аутентификации;
• управления доступом (авторизация выполнения необходимой операции);
• представления MIB.
При объединении всех этих понятий в одной переменной теряется гиб-
кость и ограничиваются функциональные возможности. Модель. VACM по-
зволяет передать ту же связанную с защитой информацию с помощью ис-
пользования своей отдельной переменной для каждого элемента. Это оказы-
вается важным усовершенствованием в сравнении с SNMPvl, поскольку
различные понятия оказываются разделенными, и характеризующие их зна-
чения выбираются по отдельности.
330
Часть II. Приложения сетевой защиты
8.4. РЕКОМЕНДУЕМЫЕ ИСТОЧНИКИ
ДОПОЛНИТЕЛЬНОЙ ИНФОРМАЦИИ
Книга [STAL99] предлагает всеобъемлющий и достаточно подробный обзор
SNMP, SNMPv2 и SNMPv3. Кроме того, эта книга содержит обзор технологий
сетевого управления.
STAL99 Stallings, W. SNMP, SNMPo2, SNMPv3, and RMON 1 and 2. Reading,
MA:Addison-Wesley, 1999.
Рекомендуемые Web-узлы
• Рабочая группа SNMPv3 IETF. Предлагает самые последние копии
связанных с SNMPv3 документов RFC, проекты стандартов Internet,
а также графики выполненных и планируемых работ.
• Web-узел SNMPv3. Поддерживается Техническим университетом
Брауншвейга (Technical University of Braunschweig). Содержит
ссылки на документы RFC и проекты стандартов Internet, копии
разъяснений и изменений, предлагаемых этой рабочей группой, а
также ссылки на поставщиков реализаций SNMPv3.
• Узел Simple Web. Поддерживается Университетом Твенте
(University of Twente). Является хорошим источником информа-
ции о SNMP, включающим ссылки на многие общедоступные
реализации, списки книг и статей.
8.5. ЗАДАЧИ
8.1. SNMPvl определяет тип данных, называемый датчиком, и содержит следую-
щее объяснение семантики этого типа.
Этот тип представляет собой неотрицательное целое число, которое может
возрастать или убывать, но которое защелкивается (latch) при максималь-
ном значении. Данный стандарт задает максимальное значение для датчи-
ков, равное 23|-1 (или 4294967295 в десятичном представлении).
К сожалению, здесь слово latch, (запирать) не получило точного определения,
что породило две его различные интерпретации. Стандарт SNMPv2 устраняет
неоднозначность с помощью следующего определения.
Значение датчика оказывается равным максимальному значению, если модели-
руемая им информация больше или равна этому максимальному значению; ес-
ли же впоследствии моделируемая датчиком информация уменьшается ниже
максимального значения, значение датчика также уменьшается.
а. Какова альтернативная интерпретация?
б. Рассмотрите все “за” и “против” этих двух интерпретаций.
8.2. В SNMPvl любой объект MIB имеет категорию доступа MIB, которая может прини-
мать одно из следующих значений: только для чтения, чтение-запись, только запись
и недоступен. Чтение выполняется при операциях get и trap, а запись — при опе-
рациях set. Для чтения-записи объект может быть доступен при выполнении опе-
Глава 8. Защита сетевого управления
331
раций get и trap, но это зависит от реализации. Категория доступа MIB описывает
максимум возможностей доступа для объекта, но в рамках возможностей объедине-
ний SNMPvl режим доступа может дополнительно ограничивать доступ с помощью
профиля данного объединения. В следующей таблице заполните пустые ячейки,
указав соответствующий вид разрешенного доступа.
Категория доступа MIB Режим доступа SNMP
ТОЛЬКО ЧТЕНИЕ ЧТЕНИЕ-ЗАПИСЬ
только чтение
чтение-запись
только запись
недоступен
8.3. а. В документе RFC 2574 указано, что для неавторитетного процессора значения
msgAuthoritativeEngineBoots и msgAuthoritativeEngineTime в заголов-
ке исходящего сообщения устанавливаются только в случае, если сообщение
должно аутентифицироваться авторитетным получателем. Почему это огра-
ничение имеет смысл?
б. Однако для сообщения Response авторитетного процессора значения
msgAuthoritativeEngineBoots и msgAuthoritativeEngineTime в заголов-
ке исходящего сообщения устанавливаются всегда. Почему?
8.4. В документе RFC 2574 указано, что синхронизация часов (обновление показа-
ний локальных часов на основе поступающих значений) выполняется до вери-
фикации окна времени (проверки того, что поступившее сообщение своевремен-
но). Это означает, что неавторитетный процессор может обновить свое представ-
ление часов авторитетного процессора, если полученное сообщение
аутентифицировано, даже если сообщение не попадает в рамки допустимого ок-
на времени. Со времени публикации документа RFC споры по этому вопросу в
списке рассылки SNMPv3 не утихают, но на момент подготовки текста данной
книги соответствующий стандарт так и не был изменен. Полезно будет рассмот-
реть некоторые последствия этого. Определим следующие сокращения.
МАЕВ = msgAuthoritativeEngineBoots;
МАЕТ = msgAuthoritativeEngineTime;
SEB = локальное представление snmpEngineBoots для удаленного авторитет-
ного процессора;
SET = локальное представление snmpEngineTime для удаленного авторитетно-
го процессора;
LRET = latestReceivedEngineTime.
Теперь предположим, что неавторитетный процессор получает сообщение вида
(МАЕВ = SEB) AND [LRET < МАЕТ < (SET - 150)].
Тогда условия обновления часов выполняются, поэтому происходит следующее:
SET := МАЕТ; LRET := МАЕТ.
Теперь, когда необходимо проверить окно времени, мы имеем
(МАЕВ = SEB) AND (МАЕТ = SET),
332
Часть II. Приложения сетевой защиты
так что мы можем заявить, что сообщение является своевременным. Предполо-
жим, однако, что мы сначала должны выполнить проверку окна времени. Ка-
ким тогда мы должны признать сообщение — своевременным или нет?
8.5. В первоначально опубликованной версии спецификаций USM (документ RFC 2274)
при обсуждении процедуры синхронизации часов и верификации окна времени де-
лается следующее замечание. “Обратите внимание на то, что эта процедура не по-
зволяет выполнить автоматическую синхронизацию времени, если неавторитетный
процессор SNMP оказывается в ситуации, когда авторитетный процессор SNMP от-
стает от неавторитетного процессора более чем на 150 секунд.” Это утверждение не
вошло в исправленную версию (документ RFC 2574) после того, как рабочей группе
было указано, что это утверждение не всегда верно. Используя пример из задачи
8.4, докажите, что это утверждение не всегда верно.
8.6. SNMPv3 предполагает что имеются некоторые защищенные средства доставки
локализованных ключей аутентифицированным системам (агентам). Такая за-
щищенная доставка не является предметом рассмотрения протокола SNMPv3 —
это может быть доставка вручную или с помощью некоторого защищенного про-
токола, отличного от SNMPv3. После доставки агенту исходного ключа (или па-
ры ключей — аутентификации и секретности) SNMPv3 предоставляет механизм
защищенного обновления ключей. Для усиления защиты следует время от вре-
мени изменять ключи. Пользователь, со своей стороны, может инициировать
процесс изменения ключей с помощью запроса и предоставления нового пароля.
Система сетевого управления (Network Management System — NMS) может ини-
циировать этот процесс с помощью запроса нового пароля. В любом случае ключ
пользователя в NMS изменяется. После этого NMS может вычислить локализо-
ванные ключи для каждого из своих агентов. Система NMS должна затем свя-
заться защищенным образом с каждым агентом, чтобы заставить агента изме-
нить локализованный ключ. Ясно, что NMS не может просто переслать ключ в
открытом виде по сети. Очевидны следующие два варианта.
• Шифровать новый ключ, используя старый в качестве ключа шифрования.
• Использовать некоторую одностороннюю функцию, чтобы сгенерировать не-
которое значение из старого ключа. Связать с помощью операции XOR
(исключающее ИЛИ) это значение с новым ключом и послать результат аген-
ту. Агент может затем с помощью операции XOR связать поступившее значе-
ние с результатом применения той же односторонней функции к старому
ключу, чтобы получить новый ключ.
В SNMPv3 используется некоторый вариант второго метода. Каковы преимуще-
ства этого метода в сравнении с первым?
8.7. Подход SNMPv3 предполагает использование объекта Key Change (изменение
ключа) в структуре MIB системы назначения. Удаленный принципал или NMS
устанавливает этот объект, а затем он автоматически используется агентом для
обновления соответствующего ключа. Алгоритм складывается из двух частей,
одна из которых существует в запрашивающем процессоре, а другая — в уда-
ленном процессоре агента. Процесс начинается, когда запрашивающая сторона
изъявляет желание изменить существующий ключ keyOld на новое значение
keyNew. Запрашивающая сторона выполняет следующие действия.
1. Генерирует значение random с помощью генератора псевдослучайных либо
истинно случайных чисел.
2. Вычисляется
digest = Hash (keyOld || random) ,
Глава 8. Защита сетевого управления
333
где Hash обозначает либо MD5, либо SHA-1, в зависимости от того, какой требу-
ется ключ (16- или 20-байтовый), а символ || представляет конкатенацию.
3. Вычисляются
delta = digestФkeyNew,
protocolKeyChange = (random[| delta),
где Ф представляет операцию исключающего ИЛИ.
4. Значение protocolKeyChange затем посылается агенту в команде Set для
обновления экземпляра объекта KeyChange в структуре MIB агента.
Что должен сделать агент с поступившим значением, чтобы изменить ключ?
8.8. Более простая процедура (в сравнении с только что описанной) могла бы пред-
полагать связывание keyOld и keyNew с помощью операции XOR и последую-
щую передачу полученного в результате значения. Получатель затем может свя-
зать операцией XOR прибывшее значение и keyOld, чтобы получить keyNew.
Поскольку противник не знает значения keyOld, он не сможет вычислить зна-
чение keyNew. В чем заключаются преимущества использования случайных чи-
сел и защищенной односторонней функции хэширования по схеме из задачи 8.7
в сравнении с подходом, предлагаемым здесь?
334
Часть II. Приложения сетевой защиты
Защита систем
В третьей части книги рассматриваются вопросы
защиты системного уровня (включая защиту от угроз,
создаваемых нарушителями и вирусами), а также ис-
пользование брандмауэров и высоконадежных систем.
Глава 9. Нарушители и вирусы
Ж
В главе 9 описаны угрозы несанкционированного
доступа к информации и сервисам, создаваемые хакера-
ми и программами, использующими слабости защиты
сетевых компьютерных систем. Глава начинается с об-
суждения типов атак, предпринимаемых несанкциони-
рованными пользователями, называемыми нарушителя-
ми, и анализа различных подходов к решению проблемы
выявления и предотвращения нарушений. Рассматрива-
ются также программные угрозы, вызванные вирусами и
другими программами подобного вида.
Глава 10. Брандмауэры
Стандартным подходом в области защиты ресурсов
локальной компьютерной сети является использование
брандмауэра. В главе 10 обсуждаются принципы по-
строения брандмауэров и даются некоторые советы по их
использованию.
This page intentionally left blank
ГЛАВА
9
Нарушители
и вирусы
9.1. Нарушители
9.2. Вирусы и угрозы, связанные с вирусами
9.3. Рекомендуемые источники дополнительной
информации
9.4. Задачи
Одной из серьезнейших проблем безопасности сетевой среды являются зло-
намеренные или, по крайней мере, нежелательные попытки вторжения в
сеть, предпринимаемые некоторыми пользователями или программным
обеспечением. Такого рода нарушения со стороны пользователей могут иметь
форму попыток несанкционированного доступа к компьютеру или попыток ле-
гального пользователя получить привилегии либо выполнить операции, выхо-
дящие за рамки предоставленных ему полномочий. Под нарушениями со сторо-
ны программного обеспечения понимается работа вируса, “червя” или
“троянского коня”.
Все такие нарушения относятся к вопросам защиты сетей, поскольку вход в
систему может осуществляться через сеть. Однако эти нарушения нельзя отнести
к чисто сетевым — пользователь, имеющий доступ к локальному терминалу,
может попытаться проникнуть в систему, не используя сетевые средства. Вирус
или “троянский конь” могут попасть в систему с дискеты. В этом смысле только
“червь” может считаться чисто сетевым средством вторжения. Таким образом,
вопросы вторжения в компьютерные системы находятся на стыке областей, от-
носящихся к защите сетей и защите компьютерных систем.
Данная книга в основном посвящена вопросам защиты сетей, поэтому мы
не будем пытаться провести здесь исчерпывающий анализ возможностей втор-
жения в компьютерную систему и соответствующих контрмер. Вместо этого мы
рассмотрим вопрос в более широкой постановке и обсудим проблему на концеп-
туальном уровне.
Эта глава начинается с классификации нарушителей. Сначала исследуется
природа нарушений защиты соответствующего типа, а затем рассматриваются
стратегии обнаружения или предупреждения таких нарушений.
9.1. НАРУШИТЕЛИ
Одной из двух самых распространенных угроз безопасности являются наруши-
тели, обычно называемые хакерами (hacker) или взломщиками (cracker). (Вторая уг-
роза — вирусы.) В одной из основополагающих работ, посвященных анализу втор-
жений в системы [ANDE80], предлагается следующая классификация нарушителей.
• Имитатор. Лицо, не имеющее права пользования компьютером, но преодо-
левшее механизм управления доступом и использующее права доступа не-
которого легального пользователя.
• Правонарушитель. Легальный пользователь, пытающийся получить доступ
к данным, программам или ресурсам, соответствующих прав доступа к ко-
торым он не имеет, или пользователь, который располагает соответствую-
щими правами доступа, но использует их в злонамеренных целях.
• Тайный пользователь. Лицо, завладевшее правами управления системой и
использующее их с целью обхода средств аудита и управления доступом
или для создания препятствий в регистрации системных событий.
Имитаторами чаще всего бывают внешние пользователи, правонарушителя-
ми — внутренние, а тайными пользователями могут оказаться как те, так и другие.
По уровню опасности атаки нарушителей могут быть как незначительными,
так и вполне серьезными. К незначительным по опасности нарушениям можно
338
Часть III. Защита систем
отнести попытки получить доступ к сетевой среде просто из личного любопытст-
ва. К серьезным нарушениям можно отнести действия лиц, пытающихся читать
секретные данные, выполнять несанкционированные изменения данных или
осуществлять действия, приводящие к повреждению системы.
Угроза, связанная с действиями нарушителей, хорошо известна отчасти благо-
даря нашумевшему инциденту с “коварным хакером’’ (Wily Hacker) в 1986-1987 гг.,
описанному Клиффом Столлом (Cliff Stoll) [STOL88, STOL89]. В 1990 году было раз-
вернуто настоящее преследование компьютерных хакеров, сопровождавшееся аре-
стами, открытием уголовных дел, одним драматическим показательным процессом,
несколькими обвинительными приговорами, а также конфискациями немалого объ-
ема данных и компьютерного оборудования [STER92J. Многие люди поверили, что в
результате этих мер проблема была взята под контроль.
На самом деле проблема так и не была решена. Приведем лишь один при-
мер — специальная группа Bell Labs [BELL92, BELL93] опубликовала данные о
постоянных и довольно частых атаках, которым подвергался их компьютерный
комплекс через Internet в течение достаточно долгого периода времени со сторо-
ны совершенно разных источников. Были выявлены атаки следующих видов.
• Попытки копировать файл паролей (о чем мы подробнее поговорим поз-
же) — чаще одного раза в два дня.
• Подозрительные запросы на удаленный вызов процедур — чаще одного раза
в неделю.
• Попытки подключиться к несуществующим “машинам-ловушкам” — чаще
двух раз в месяц.
С действиями нарушителей, не имеющими злого умысла, можно было бы
мириться, хотя и такие действия ведут к напрасному потреблению ресурсов и,
следовательно, снижают производительность системы для легальных пользова-
телей. Проблема в том, что не существует методов, позволяющих однозначно
выяснить, является нарушитель злоумышленником или нет. Поэтому даже для
систем, не предназначенных для хранения особо важных данных, имеет смысл
держать подобную проблему под контролем.
Данное утверждение можно проиллюстрировать на примере события, про-
изошедшего в Техасском сельскохозяйственном университете (Texas А&М Uni-
versity) [SAFF93]. В августе 1992 г. в компьютерный центр университета посту-
пило сообщение о том, что один из их компьютеров использовался для атаки в
Internet на компьютеры, принадлежащие другой организации. Установив посто-
янное наблюдение, персонал компьютерного центра обнаружил, что существует
несколько внешних нарушителей, постоянно запускающих процедуры подбора
паролей на разных машинах (всего в объединенной сети центра было около
12000 компьютеров). Центр отключил машины со взломанной защитой, устра-
нил все обнаруженные в системе защиты изъяны и только после этого продол-
жил работу в нормальном режиме. Но спустя несколько дней один из локальных
системных администраторов зарегистрировал новую попытку взлома. Выясни-
лось, что методика, применяемая нарушителем, была гораздо сложнее, чем по-
казалось на первый взгляд. Были обнаружены файлы, содержащие сотни пере-
хваченных паролей, среди которых были и пароли, с помощью которых можно
было получить доступ к главным, до сих пор считавшимся надежно защищен-
ными серверам. Ко всему прочему один из локальных компьютеров был сконфи-
Глава 9. Нарушители и вирусы
339
гурирован как электронная доска объявлений, с помощью которой хакеры свя-
зывались друг с другом и делились успехами и опытом.
। Анализ этого случая выявил, что в действительности существует два типа
хакеров. На высшем уровне находятся хорошо подготовленные специалисты,
прекрасно разбирающиеся в технологии, а на низшем — “рядовые солдаты”,
просто использующие существующие программы взлома и имеющие весьма ту-
манное представление о том, как эти программы работают. Эта рабочая команда
объединяет два весьма грозных фактора: глубокое знание методов взлома систем
защиты и тупое желание бесконечно долго “стучаться в закрытые двери”, прове-
ряя все уязвимые места системы.
В результате возросшего внимания к проблеме нарушителей были сформи-
рованы многочисленные группы быстрого реагирования на компьютерные про-
исшествия — группы CERT (Computer Emergency Response Team). Эти группы,
объединяющие специалистов в области защиты информации, собирают и обоб-
щают данные об уязвимых местах используемых систем, делая эту информацию
доступной системным администраторам. К сожалению, к отчетам CERT могут
иметь доступ и хакеры. При анализе инцидента, произошедшего в Техасском
сельскохозяйственном университете, выяснилось, что хакеры разработали про-
граммы, проверяющие компьютеры на предмет выявления всех возможных не-
достатков защиты, на которые указывалось в отчетах CERT. В результате, если
система защиты какой-то машины не вполне отвечала рекомендациям CERT, она
становилась широко открытой для такого рода атак.
Помимо запуска программ подбора паролей, нарушители модифицировали
программу регистрации входа в сеть, что позволило им перехватывать пароли,
вводимые пользователями во время регистрации в системе. Это дало нарушите-
лям возможность создать впечатляющий список скомпрометированных паролей,
который был выставлен на электронной доске объявлений, созданной на одной
из машин жертвы.
Мы начнем следующий раздел с описания методов, используемых для
вторжения, а затем перейдем к обсуждению контрмер, позволяющих предотвра-
тить попытки вторжения. Если же предотвратить вторжение невозможно, то
второй линией защиты должна стать система выявления нарушений, о которой
мы поговорим в конце раздела.
Методика вторжения
Цель нарушителя — получить доступ к системе или расширить права, пре-
доставленные ему системой на законном основании. Для этого нарушителю, как
правило, требуется раздобыть информацию, которая должна быть защищенной.
В большинстве случаев эта информация представлена в форме пароля пользова-
теля. Зная пароль некоторого другого пользователя, нарушитель может войти в
систему под его именем и получить все привилегии, которыми тот обладает.
Обычно в системе имеется файл, связывающий пароли с именами легаль-
ных пользователей. Если этот файл не защищен, не составляет никакого труда
получить к нему доступ и узнать хранящиеся в нем пароли. Файл паролей мо-
жет защищаться одним из следующих способов.
• Одностороннее шифрование. Система хранит пароль пользователя только в
зашифрованном виде. Когда пользователь вводит свой пароль, система
340
Часть III. Защита систем
шифрует введенный пароль и сравнивает результат с тем значением, кото-
рое хранится в файле паролей. На практике система обычно выполняет од-
ностороннее (необратимое) преобразование, в котором пароль используется
для генерирования ключа функции шифрования, в результате чего получа-
ется вывод фиксированной длины.
• Управление доступом. Доступ к файлу паролей разрешается лишь одному
или очень небольшому числу пользователей.
Если используются обе или хотя бы одна из этих контрмер, потенциальному
нарушителю придется приложить определенные усилия, чтобы узнать пароли. На
основе анализа специальной литературы и интервью со многими взломщиками па-
ролей в [ALVA90] сообщается о следующих методах получения паролей.
1. Проверка паролей по умолчанию для стандартных учетных записей, по-
ставляемых с системой. Многие администраторы не утруждают себя работой
по смене установленных по умолчанию значений.
2. Перебор всех коротких паролей (от одного до трех символов).
3. Проверка слов из системного словаря или списка наиболее вероятных паро-
лей. Список последних всегда можно найти на электронных досках объяв-
лений хакеров.
4. Сбор информации о пользователях, включая их полные имена, имена их
супругов и детей, названия картин и любимых книг, по которым можно су-
дить об их увлечениях.
5. Проверка в качестве пароля телефонных номеров, номеров социальной
страховки и номеров комнат пользователей.
6. Проверка в качестве пароля всех возможных для данного штата номерных
знаков автомобилей.
7. Использование “троянского коня” (см. раздел 9.2) для обхода ограничений
доступа.
8. Подключение к линии связи между пользователем и хостом.
Первые шесть методов являются вариациями на тему подбора паролей. Если
нарушителю приходится угадывать варианты пароля в процессе регистрации в сис-
теме, то, с одной стороны, это весьма утомительно, а с другой — легко обнаружива-
ется системой. Например, система может просто отвергать любые попытки зарегист-
рироваться под соответствующим именем после трех неудачных попыток ввода па-
роля, что заставит нарушителя разорвать связь с узлом и пытаться подключиться
снова. В такой ситуации нет смысла проверять большое число паролей. Однако в
действительности нарушитель вряд ли станет использовать такие примитивные ме-
тоды. Например, если нарушитель может получить доступ к зашифрованному файлу
паролей как непривилегированный пользователь, то он, скорее всего, попытается
скопировать этот файл и не спеша дешифровать его на основе известного механизма
шифрования для данной конкретной системы, чтобы в результате получить пароль,
дающий более высокий уровень привилегий.
Подбор паролей оказывается эффективным методом и, таким образом,
представляет собой опасность только в тех случаях, когда он может выполняться
в автоматическом режиме и без угрозы обнаружения. Ниже в этом разделе опи-
саны методы выявления попыток автоматического подбора пароля.
Глава 9. Нарушители и вирусы
341
Под седьмым номером в приведенном выше списке указана атака, предпола-
гающая использование “троянских коней”, обнаружение которой представляет собой
достаточно нетривиальную задачу. Пример программы, которая предназначена для
обхода механизма управления доступом, приведен в [ALVA90]. Непривилегирован-
ный пользователь создал игровую программу, предложенную системному оператору
для развлечения в свободное время. Программа действительно представляла собой
игру, но во время работы она также копировала файл паролей, хранившийся в не-
зашифрованном виде и защищенный лишь с помощью системы разграничения дос-
тупа, в файл пользователя, являющегося автором программы. Поскольку игра рабо-
тала в режиме доступа привилегированного пользователя, соответствующая про-
грамма могла получить к файлу паролей неограниченный доступ.
Восьмой тип атаки, заключающийся в подключении к линии связи, отно-
сится к области вопросов обеспечения физической защиты системы. В случае та-
ких атак возможным методом противодействия является шифрование в канале
связи, которое обсуждалось в главе 2.
Перейдем к описанию двух основных методов противодействия: предупреж-
дения и выявления нарушений. Предупреждение нарушений является неизмен-
ной целью системы защиты и, в каком-то смысле, бесконечной битвой с невиди-
мым противником. Трудность этой задачи объясняется тем, что защищающаяся
сторона должна пытаться предотвратить все возможные типы атак, тогда как
атакующая сторона имеет возможность выбрать самое слабое звено в общей цепи
защиты и сосредоточить все свои усилия именно в этом месте. Целью выявления
нарушений является изучение типа проводимой атаки либо до ее успешного за-
вершения, либо уже после.
Защита паролей
Первой линией защиты от нарушителей является система паролей. Практи-
чески все многопользовательские системы требуют, чтобы пользователь при вхо-
де в систему указывал не только свой идентификатор (имя пользователя), но и
пароль. Пароль выполняет функции аутентификации пользователя, входящего в
систему. В свою очередь, идентификатор пользователя обеспечивает защиту по
следующим направлениям.
• По идентификатору пользователя определяется, получит ли пользователь
доступ к системе вообще. Во многих системах доступ разрешается только
тем, кто уже имеет соответствующую идентификатору запись в системе.
• По идентификатору пользователя определяется набор привилегий данного
пользователя. Некоторые пользователи могут иметь статус суперпользова-
теля, позволяющий читать файлы и выполнять действия, для которых в
операционной системе предусмотрена особая защита. В некоторых системах
предусмотрены специальные идентификаторы для входа в систему гостей
(guest) или анонимных пользователей (anonymous), и пользователи, регист-
рирующиеся с такими идентификаторами, оказываются более ограничен-
ными в правах доступа, чем обычные пользователи.
• Идентификаторы пользователей играют важную роль при использовании
так называемого разграничительного контроля доступа (discretionary access
control). Например, предоставляя список идентификаторов других пользо-
вателей, данный пользователь может разрешить им читать файлы, владель-
цем которых он является.
342
Часть III. Защита систем
Уязвимость паролей
Чтобы лучше понять природу соответствующих атак, рассмотрим широко
применяемую в системах UNIX схему, в которой пароли никогда не хранятся в
открытом виде (рис. 9.1, а). Каждый пользователь сам выбирает пароль длиной
до восьми алфавитно-цифровых символов. Этот пароль преобразуется в 56-
битовое значение (на основе 7-битовых кодов ASCII), которое используется в ка-
честве ключа процедуры шифрования. Процедура шифрования, имеющая назва-
ние crypt(3), базируется на использовании алгоритма DES. Алгоритм DES моди-
фицируется с помощью специального 12-битового модификатора (“salt” value).
Как правило, значение модификатора связано со временем назначения пароля
пользователю. На вход модифицированного алгоритма DES сначала подается 64-
битовый блок данных, состоящий из одних нулей. Выходное значение подается
на вход следующего шага шифрования. Процесс повторяется до тех пор, пока
общее число шагов не достигнет 25. Полученное в результате 64-битовое выход-
ное значение преобразуется в 11-символьную последовательность. Шифрованный
таким образом пароль сохраняется вместе с открытым значением модификатора
в файле паролей в соответствующей данному идентификатору записи.
Использование модификатора решает следующие задачи.
• Предотвращает дублирование паролей в файле паролей. Даже если два
пользователя выберут одинаковые пароли, они будут зарегистрированы в
разное время, поэтому “расширенные” представления паролей этих пользо-
вателей будут разными.
• Увеличивает эффективную длину пароля на два символа, не заставляя
пользователя их запоминать. Следовательно, число возможных паролей
возрастает в 4096 раз, что затрудняет задачу подбора паролей.
• Исключает возможность применения аппаратной реализации DES, упрощаю-
щую проведение атак с использованием простого перебора всех паролей.
При попытке войти в систему UNIX пользователь должен ввести идентифи-
катор и пароль. Операционная система использует идентификатор для нахожде-
ния в файле паролей открытого значения модификатора и шифрованного значе-
ния пароля. Модификатор и введенный пользователем пароль подаются на вход
процедуры шифрования. Если в результате получается значение, идентичное со-
храненному шифрованному значению пароля, введенный пароль принимается
системой как правильный.
Задача процедуры шифрования — исключить возможность угадывания па-
роля. Программные реализации DES медленнее аппаратных, а необходимость
выполнения 25 итераций еще в 25 раз увеличивает время, требуемое для перебо-
ра. Однако со времени создания алгоритма ситуация изменилась. Во-первых,
были разработаны более новые скоростные реализации алгоритма. Например, в
Internet уже существует программа-“червь”, которая за вполне приемлемое вре-
мя способна проверить несколько сотен вариантов пароля, используя для этого
существенно более эффективный алгоритм шифрования, чем тот, который ис-
пользуется в атакуемых системах UNIX. Во-вторых, производительность вычис-
лительных систем тоже постоянно растет, что означает более быстрое выполне-
ние любых алгоритмов.
Глава 9. Нарушители и вирусы
343
Salt
(модификатор) Пароль
а) загрузка нового пароля
б)проверка пароля
Рис. 9.1. Схема использования паролей в UNIX
Таким образом, можно обозначить две угрозы системе паролей, реализован-
ной в UNIX. Во-первых, пользователь может получить доступ к машине, исполь-
зуя гостевой идентификатор или какой-то другой способ, а затем запустить на
этой машине программу подбора паролей, обычно называемую “password
cracker” (взломщик паролей). В результате нарушитель может проверить сотни и
даже тысячи значений пароля, не вызывая заметного расходования системных
ресурсов. А если противнику удастся получить копию файла паролей, то про-
грамму подбора паролей можно будет запустить на другом компьютере в режиме
344
Часть III. Защита систем
отсутствия цейтнота. Это дает нарушителю возможность проверить многие тыся-
/
чи вариантов паролей за вполне приемлемое время.
Пример программы подбора паролей был опубликован в Internet в августе
1993 г. [MADS93]. На компьютере Thinking Machines Corporation была достиг-
нута производительность в 1560 вызовов процедуры шифрования в секунду на
векторную единицу. При четырех векторных единицах на процессорный узел
(что является стандартной конфигурацией) общая производительность машины,
состоящей из 128 узлов (что является весьма скромным показателем), достигает
800000 вызовов процедуры шифрования в секунду, а для машины, состоящей из
1024 узлов, — 6,4 млн вызовов в секунду.
Но даже этих огромных значений для нарушителя оказывается недостаточ-
но, чтобы успешно использовать простой перебор всех возможных вариантов па-
роля. Вместо этого взломщики паролей исходят из предположения, что многие
пользователи имеют легко угадываемые пароли.
Нередко пользователи, если им разрешается выбрать пароль по своему ус-
мотрению, выбирают очень короткие пароли. В табл. 9.1 показаны результаты
исследований, проведенных в Университете Пэдью (Purdue University). В ходе
исследования выяснялась длина паролей, выбираемых пользователями на 54
машинах с общим числом пользователей около 7000. Оказалось, что 3% всех
паролей имели длину в три символа или менее того. Таким образом, атакующий
может начать с проверки всех возможных комбинаций длиной до трех символов.
Простейшим средством противодействия этому является такая настройка систе-
мы, при которой пользователь не сможет выбрать пароль длиной меньше, ска-
жем, шести символов или даже потребовать, чтобы все пароли состояли в точно-
сти из восьми символов. Большинство пользователей вряд ли станут выражать
недовольство по поводу таких ограничений.
Таблица 9.1. Распределение длин паролей, выбираемых пользователями
[SPAF92a]
Длина пароля Число паролей указанной длины Доля от общего числа паролей
1 55 0,004
2 87 0,006
3 212 0,02
4 449 0,03
5 1260 0,09
6 3035 0,22
7 2917 0,21
8 5772 0,42
Всего: 13787 1,0
Длина пароля — это только один источник возможных проблем. Многие
пользователи, если им разрешается выбрать пароль по своему усмотрению, оста-
навливают выбор на легко угадываемых словах, например, на своем имени, на-
звании улицы, на которой они живут, на словах из повседневной лексики и т.п.
Это существенно упрощает задачу подбора пароля. Взломщику достаточно про-
Глава 9. Нарушители и вирусы
345
верить файл паролей на наличие в нем наиболее вероятных значений. Поскольку
легко угадываемые пароли используют многие люди, такая стратегия оказывает-
ся эффективной практически в любой системе.
Демонстрация эффективности подбора пароля имеется в [KLEI90]. Автор собрал
файлы паролей UNIX из самых разных источников — в общей сложности им было
получено около 14000 зашифрованных паролей. Результат, который автор справед-
ливо называет ошеломляющим, представлен в табл. 9.2. Из всех паролей примерно
четверть была им угадана. При этом использовалась следующая стратегия.
1. Проверяются имена пользователя, инициалы, идентификатор учетной запи-
си и другая персональная информация. В общем для каждого пользователя
проверялось 130 возможных вариантов пароля.
2. Проверяются слова из различных словарей. Автор собрал словарь, содер-
жащий более 60000 слов, включая словарь справки самой системы, а также
другие словари, как видно из таблицы.
3. Проверяются различные модификации слов из п. 2. Варианты создавались
путем изменения первой буквы со строчной на прописную, добавления в
начало слова символа “Л”, перевода символов слова в верхний регистр, за-
писи слова в обратном порядке, замены буквы “о” цифрой “0” и т.п. В ре-
зультате таких преобразований список проверяемых вариантов увеличива-
ется на 1 млн значений.
4. Проверяются варианты замены регистра символов в словах из п. 2, не уч-
тенные на этапе, представленном п. 3. В результате этого к списку прове-
ряемых вариантов добавляется еще 2 млн значений.
Таблица 9.2. Пароли, угаданные из выборки 13797 учетных записей [KLEI90]
Тип пароля Число вариантов Число сов- падений Доля от общего числа паролей Соотиошенне “стоимость- результат”1
Имя пользователя 130 368 2,7 % 2,830
Последовательность символов 866 22 0,2 % 0,025
Числа 427 9 0,1 % 0,021
Китайские слова 392 56 0,4 % 0,143
Географические назва- ния 628 82 0,6 % 0,131
Общеизвестные назва- ния 2239 548 4,0 % 0,245
Женские имена 4280 161 1,2 % 0,038
Мужские имена 2866 140 1,0 % 0,049
Редкие имена 4955 130 0,9 % 0,026
Мифы и легенды 1246 66 0,5 % 0,053
Персонажи Шекспира 473 11 0,1 % 0,023
Спортивные термины 238 32 0,2 % 0,134
346
Часть III. Защита систем
Окончание табл. 9.2
Тип пароля Число вариантов Число сов- падений Доля от общего числа паролей Соотношение “стоимость- результат”1
Научная фантастика 691 59 0,4 % 0,085
Кинофильмы и актеры 99 12 0,1 % 0,121
Мультфильмы 92 9 0,1 % 0,098
Известные люди 290 55 0,4 % 0,190
Крылатые фразы и вы- ражения 933 253 1,8 % 0,271
Фамилии 33 9 0,1 % 0,273
Биологические терми- ны 58 1 0,0 % 0,017
Слова из системного словаря 19683 1027 7,4 % 0,052
Названия машин 9018 132 1,0 % 0,015
Мнемоника 14 2 0,0 % 0,143
Библейские названия 7525 83 0,6 % 0,011
Повседневная лексика 3212 54 0,4 % 0,017
Слова из языка идиш 56 0 0,0 % 0,000
Названия астероидов 2407 19 0,1 % 0,007
Всего: 62727 3340 24,2 % 0,053
1 Вычисляется путем деления числа совпадений на число вариантов. Чем больше вариан-
тов необходимо проверить, тем меньше значение этого показателя.
Таким образом, данный тест предполагает проверку примерно 3 млн слов. Если
использовать упоминавшийся выше компьютер Thinking Machines, то для шифрова-
ния всех этих слов потребуется около часа. При этом необходимо понимать, что
здесь показатель успеха 25% получен в результате довольно тщательного анализа,
но в некоторых случаях одного угаданного пароля может оказаться вполне достаточ-
но для того, чтобы получить привилегированный доступ к системе.
Управление доступом
Одним из методов предотвращения атак с подбором паролей является за-
прет доступа к файлу паролей. Если часть файла, содержащая шифрованные
представления паролей, доступна только привилегированным пользователям,
нарушитель не сможет прочесть их без пароля привилегированного пользовате-
ля. В [SPAF92] отмечаются некоторые недостатки этой стратегии.
• Многие системы, включая большинство систем UNIX, оказываются чув-
ствительными к непредвиденным вторжениям. Получив каким-либо об-
разом доступ к системе, нарушитель может пытаться получить некото-
рый список паролей, чтобы каждый раз входить в систему под разными
именами, тем самым уменьшая риск своего обнаружения. Легальный
пользователь системы тоже может использовать идентификатор и пароль
Глава 9. Нарушители и вирусы 347
другого пользователя, чтобы получить доступ к закрытым данным или
нарушить работу системы.
• Один сбой системы защиты может открыть файл паролей для чтения, в ре-
зультате чего все учетные записи могут оказаться скомпрометированными.
• Некоторые пользователи, имеющие доступ к разным машинам, вводят для
разных учетных записей одни и те же пароли. Если при этом кто-то сможет
узнать пароль данного пользователя на одной машине, может быть ском-
прометирована и другая машина.
Таким образом, эффективность стратегии защиты доступа к системе нераз-
рывно связана с необходимостью выбора пароля, который нелегко разгадать.
Стратегии выбора пароля
Урок, который можно извлечь из результатов двух описанных выше иссле-
дований (табл. 9.1 и 9.2), заключается в том, что по собственному выбору мно-
гие пользователи создают либо слишком короткие, либо легко угадываемые па-
роли. В то же время, предоставленный пользователю пароль, состоящий из
восьми случайно выбранных алфавитно-цифровых символов, взломать оказыва-
ется практически невозможным. Однако большинство пользователей не смогут
запомнить такой пароль. К счастью, если даже ограничить пространство таких
паролей просто запоминающимися символьными строками, то размер этого про-
странства все равно оказывается достаточно большим для того, чтобы предотвра-
тить возможность взлома. Таким образом, цель заключается в том, чтобы ис-
ключить выбор пользователем легко угадываемого пароля и в то же время со-
хранить возможность выбора легко запоминающегося пароля. Решение этой
задачи достигается за счет перечисленных ниже средств.
• Обучение пользователей.
• Генерирование паролей компьютером.
• Реактивная проверка пароля.
• Упреждающая проверка пароля.
Пользователям можно разъяснить важность использования трудно угады-
ваемых паролей и выдать рекомендации по правильному выбору таких паролей.
Стратегия обучения пользователей в большинстве случаев оказывается малоэф-
фективной, особенно, если число пользователей велико или существует постоян-
ный приток и отток пользователей. Одни пользователи будут просто игнориро-
вать рекомендации, другие же не смогут оценить, насколько надежными явля-
ются выбранные ими пароли. Например, многие (ошибочно) полагают, что
запись слова в обратном порядке или изменение последней буквы со строчной на
прописную превращают расшифровку пароля в практически невозможное дело.
Генерирование паролей компьютером тоже приводит к проблемам. Если
генерировать пароли в виде случайных наборов букв и цифр, пользователи не
смогут их запомнить. Даже если пароли представляют собой более или менее
произносимые слова, пользователи все равно, испытывая трудности с запомина-
нием таких слов, будут стремиться записать их. В общем, схема генерирования
паролей с помощью компьютера имеет печальный опыт с точки зрения удобства
пользователя. Один из лучших автоматических генераторов паролей описан в
348
Часть Ш. Защита систем
документе FIPS PUB 181. Документ содержит не только описание применяемого
подхода, но и листинг исходного текста алгоритма на языке С. Алгоритм гене-
рирует вполне произносимые слова с помощью комбинации произносимых бук-
восочетаний. Поток символов, формирующих буквосочетания и слова, обеспечи-
вается генератором случайных чисел.
Стратегия реактивной проверки паролей состоит в том, что система периодиче-
ски запускает собственную программу подбора паролей, обнаруживающую легко
угадываемые пароли. Система отменяет все разгаданные пароли и извещает об этом
соответствующих пользователей. Данный подход имеет ряд недостатков. Во-первых,
выполнение такой проверки в полном объеме требует большого расхода ресурсов
системы. Потенциальный противник, получивший копию файла паролей, может по-
зволить себе бросить на решение задачи все ресурсы своего компьютера в течение
многих часов или даже дней, поэтому любая программа реактивной проверки паро-
лей находится в явно более проигрышном положении. Кроме того, все имеющиеся
пароли остаются уязвимыми до тех пор, пока программа реактивной проверки паро-
лей не закончит работу, и легко угадываемые пароли не будут выявлены.
Самым многообещающим с точки зрения усиления защиты паролей являет-
ся стратегия упреждающей проверки паролей. В этом случае пользователю раз-
решается выбрать пароль по своему усмотрению, но в процессе выбора система
проверяет пароль на соответствие установленным требованиям и при необходи-
мости отвергает его. Такой подход основан на убеждении, что под руководством
системы из достаточно широкого пространства допустимых паролей пользова-
тель выберет пароль, который он сможет легко запомнить, но который будет
практически невозможно угадать с помощью перебора значений из словаря.
Проблема упреждающей проверки паролей состоит в необходимости дости-
жения баланса между стойкостью пароля и его приемлемостью для пользовате-
ля. Если система отвергает слишком много паролей, пользователи жалуются,
что выбрать подходящий пароль слишком трудно. Если же система использует
для проверки пригодности паролей слишком простой алгоритм, то это только
дает взломщику возможность усовершенствовать свою программу подбора паро-
лей. В оставшейся части раздела мы обсудим возможности реализации упреж-
дающей проверки паролей.
Первый подход состоит в создании простой системы контроля за соблюде-
нием определенных правил. Например, можно потребовать, чтобы соблюдались
следующие правила.
• Все пароли должны содержать не менее восьми символов.
• Среди первых восьми символов должна присутствовать как минимум одна
строчная буква, одна прописная буква, одна цифра и один знак пунктуации.
Эти правила должны сопровождаться соответствующими инструкциями пользо-
вателю. Хотя данный подход лучше простого обучения пользователей, он не все-
гда может остановить взломщика паролей. Такая схема дает нарушителю ин-
формацию о том, какие пароли не следует проверять, но в конечном итоге не
исключает возможности успешного проведения соответствующей атаки.
Другой возможностью является создание большого словаря потенциально
“плохих” паролей. При выборе пользователем пароля система проверяет, не по-
падает ли выбранный пароль в “черный список”. Данный подход чреват сле-
дующими проблемами.
Глава 9. Нарушители и вирусы
349
• Проблема объема. Чтобы описанный выше подход был эффективным, сло-
варь должен быть достаточно большим. Например, файл словаря, использо-
вавшегося для исследований в Университете Пэдью [SPAF92a], имел объем
более 30 Мбайт.
• Проблема времени. Время поиска в таком словаре может оказаться слиш-
ком большим. Кроме того, для проверки возможных модификаций слов не-
обходимо либо включить эти модификации в словарь, что сделает его ог-
ромным, либо тратить дополнительное время на проверку модификаций
слов с помощью специальных алгоритмов.
На сегодняшний день перспективными представляются две методики прове-
дения эффективной и достаточно надежной упреждающей проверки паролей.
Одна из них строится на основе использования марковской модели генерирова-
ния угадываемых паролей [DAVI93J. На рис. 9.2 показана упрощенная версия
такой модели. Эта модель задает язык, алфавит которого состоит из трех симво-
лов. Состояние системы в любой момент идентифицируется последним выбран-
ным символом. Коэффициенты переходов из одного состояния в другое задаются
вероятностями следования одних символов за другими. Например, вероятность
того, что следующей буквой будет b при условии, что текущей является буква а,
в данном случае равна 0,5.
М = {3, {a, b, с), Т, 1 ), где
0,0 0,5 0,5
Т= 0,2 0,4 0,4
1,0 0,0 0,0
пример строки, вероятной для этого языка: аЬЬсасаЬа
пример строки, ие являющейся вероятной для этого языка: aacccbaaa
Рис. 9.2. Пример марковской модели
!5()
Часть Ш. Защита систем
В общем случае марковская модель задается четырьмя значениями
[т, А, Т, к], где т обозначает число состояний модели, А — пространство состоя-
ний, Т — матрицу вероятностей переходов, а к — порядок модели. Для модели
порядка к вероятность перехода к тому или иному символу алфавита зависит от
значений к предыдущих символов. На рис. 9.2 показана схема простой модели
первого порядка.
В упомянутой выше работе строится и используется модель второго поряд-
ка. Сначала создается словарь легко угадываемых паролей. После этого по сле-
дующим правилам вычисляется матрица переходов.
1. Определяется матрица частот f, где f(i, j,k) соответствует числу появлений
триграмм, состоящих из г-, j- и к-го символов. Например, пароль parsnips
содержит триграммы par, ars, rsn, sni, nip и ips.
2. Для каждой биграммы ij вычисляется f(i, j, <*>) как общее число триграмм,
начинающееся с ij. Например, f(a, b, <*>) представляет собой общее число
триграмм вида aba, abb, abc и т.д.
3. Элементы матрицы Т вычисляются по формуле
ТО, j, к) =
f(i,j,k)
f(i, Л°°)
В результате получается модель, отражающая структуру слов в словаре. С
помощью этой модели вопрос “Является ли данный пароль плохим?” трансфор-
мируется в вопрос “Порождается ли данная строка (т.е. пароль) с помощью дан-
ной модели Маркова?”. Для введенного пароля можно найти вероятности пере-
ходов для всех триграмм. Затем с помощью стандартных статистических тестов
можно выяснить, оказывается ли данный пароль строкой, вероятной (или неве-
роятной) для данной модели. Пароли, которые с определенной долей вероятно-
сти порождаются данной моделью, отвергаются. Авторы утверждают, что для
модели второго порядка получаются хорошие результаты. Предложенная ими
система находит практически все пароли из словаря и, вместе с тем, не отбрасы-
вает слишком много потенциально хороших паролей, оставаясь достаточно дру-
жественной по отношению к пользователю.
Совершенно другой подход предложил Спаффорд (Spafford) [SPAF92a,
SPAF92b]. Этот подход основан на использовании фильтра Блума (Bloom) [BLOO70],
Рассмотрим принцип работы этого фильтра. Фильтр Блума порядка к состоит из к
независимых функций хэширования Н^х), Н2(х), ..., НА. (х), где каждая функция
отображает пароль в хэш-код из диапазона от 0 до N -1. Таким образом,
Н;(Х7) = у, l<i<k, l<j<D, 0<у<А-1,
где
Xj — j-e слово в словаре паролей,
D — число слов в словаре паролей.
Далее к словарю применяется следующая процедура.
1. Определяется таблица хэширования из N битов, все биты в которой уста-
навливаются равными 0.
Глава 9. Нарушители и вирусы
351
2. Для каждого пароля вычисляется к соответствующих значений хэширова-
ния, и соответствующие биты в таблице хэширования устанавливаются
равными 1. Так, если для некоторых i и j получается Н;(Х ) = 67 , то шесть-
десят седьмой бит таблицы хэширования устанавливается равным 1. (Если
значение этого бита уже было равно 1, то оно не меняется.)
Когда программе проверки предъявляется новый пароль, она вычисляет к
значений хэширования для этого пароля. Если все соответствующие биты табли-
цы хэширования оказываются равными 1, пароль отвергается. Все пароли из
словаря будут отвергнуты. Однако будут наблюдаться и некоторые “ошибочные
срабатывания” (т.е. будут отвергнуты и некоторые пароли, не включенные в
словарь, но порождающие отвергающую таблицу хэширования). Чтобы убедить-
ся в этом, рассмотрим схему с двумя функциями хэширования. Предположим,
что в словаре имеются пароли undertaker и hulkhogan, но нет пароля xG%#jj98.
Допустим также, что
Hj (undertaker) = 25 , Щ (hulkhogan) = 83 , H!(xG%#jj98) = 665 ,
H2(undertaker) = 998 , H2(hulkhogan) = 665 , Hj(xG%#jj98) = 998.
Пароль xG%#jj98, предложенный системе, будет отвергнут, несмотря на то,
что его нет в словаре. Если такие ошибочные срабатывания будут наблюдаться
слишком часто, пользователям будет трудно выбирать пароли. Следовательно,
необходимо предложить такую схему хэширования, при которой ошибочные
срабатывания были бы сведены к минимуму. Можно доказать, что вероятность
ошибочного срабатывания приблизительно равна
Р = (1-с-^/Л,/=(1-^/й/
или, что то же самое,
1п(1- Р11к) '
где
к — число функций хэширования,
N — число битов в таблице хэширования,
D — число слов в словаре,
R = N/D — отношение размера таблицы хэширования (в битах) к размеру
словаря (в словах).
На рис. 9.3 изображен график Р как функция от R для различных значений
к. Предположим, что у нас есть словарь, состоящий из 1 млн слов. Необходимо,
чтобы не указанные в словаре слова отбрасывались с вероятностью 0,01. Если
выбрать шесть функций хэширования, требуемым отношением будет Л =9,15.
Соответствующая таблица хэширования должна содержать 9,бх106 битов, что
означает необходимость выделить примерно 1,2 Мбайт для ее хранения. Хране-
ние всего словаря потребовало бы около 8 Мбайт. Таким образом будет достиг-
нут коэффициент сжатия порядка 7. Более того, проверка пароля предполагает
прямое вычисление всего шести функций хеширования, которые не зависят от
352
Часть III. Защита систем
размеров словаря, тогда как использование для проверки полного словаря пред-
полагает долгие операции постоянного поиска.1
Рис. 9.3. Графики характеристик фильтра Блума
Обнаружение нарушений
Даже самая хорошая система предотвращения вторжений иногда не срабатыва-
ет. Поэтому второй линией защиты должна стать система выявления нарушений,
что в последнее время привлекает внимание все большего числа исследователей. Ин-
терес к этим вопросам обусловлен целым рядом причин, включая следующие.
1. Если нарушение будет обнаружено достаточно быстро, нарушителя можно
будет идентифицировать и лишить доступа к системе прежде, чем он успеет
повредить или скомпрометировать данные. Даже если нарушение будет за-
фиксировано слишком поздно для того, чтобы успеть воспрепятствовать
действиям нарушителя, чем раньше нарушение будет обнаружено, тем
меньше будет ущерб и тем быстрее будет восстановлена система.
1 И модель Маркова, и фильтр Блума опираются на методы теории вероятностей.
В модели Маркова допускается небольшая вероятность того, что некоторые пароли из
словаря не будут отвергнуты, и небольшая вероятность того, что будут отвергнуты
пароли, которых в словаре нет. При использовании фильтра Блума имеется только не-
большая вероятность того, что будут отвергнуты пароли, которых нет в словаре.
Глава 9. Нарушители и вирусы
353
2. Эффективная система обнаружения нарушений сама по себе может служить
в качестве отпугивающего средства, отчасти выполняя функции системы
предотвращения вторжений.
3. Обнаружение нарушений позволяет собирать информацию о методах втор-
жения, которую впоследствии можно использовать для усиления системы
предотвращения вторжений.
Обнаружение нарушений основывается на предположении, что поведе-
ние нарушителя отличается от поведения легального пользователя и соответ-
ствующие различия можно представить в количественном выражении. Ко-
нечно же, нельзя ожидать, что мы сможем наблюдать совершенно разное ис-
пользование ресурсов нарушителем в сравнении с легальным пользователем.
Правильнее предположить, что в поведении и того, и другого все же будут
иметься общие черты.
На рис. 9.4 в очень абстрактном виде иллюстрируется природа задачи,
стоящей перед разработчиком системы выявления нарушений. Хотя типич-
ное поведение нарушителя и отличается от типичного поведения легального
пользователя, характеризующие их поведение области пересекаются. Таким
образом, чем более грубо будет интерпретироваться поведение нарушителя,
тем выше будет вероятность “ошибочных срабатываний”, т.е. признания ле-
гальных пользователей нарушителями. В то же время стремление избавиться
от ошибочных срабатываний путем более строгой интерпретации поведения
нарушителя ведет к “ошибочным несрабатываниям”, т.е. ситуациям, когда
нарушители остаются невыявленными. Таким образом, в практике обнару-
жения нарушителей присутствует элемент искусства компромисса.
В работе Андерсона (Anderson) [ANDE80] в качестве постулата принято
предположение о том, что отличить имитатора от легального пользователя
можно с достаточной степенью точности. Характеристика поведения может
быть установлена на основе наблюдения за действиями пользователя в про-
шлом, и в результате значительные отклонения в поведении могут быть за-
мечены. Андерсон полагает, что обнаружение правонарушителя (легального
пользователя, выполняющего несанкционированные операции) является бо-
лее сложной задачей, поскольку в данном случае ненормальное поведение
может почти не отличаться от нормального. В результате Андерсон заключа-
ет, что выявить такие нарушения с помощью одного лишь поиска аномалий
поведения невозможно. Тем не менее, правонарушителя тоже можно обна-
ружить, если правильно определить класс условий, при которых происходит
несанкционированное использование ресурсов. Наконец, выявление тайных
пользователей, кажется, вообще выходит за рамки одних лишь методов ав-
томатического обнаружения. Эти выводы, сделанные еще в 1980 году, не по-
теряли своего значения и сегодня.
В [PORR92] указываются следующие подходы к решению проблемы обна-
ружения нарушений.
1. Обнаружение по статистическим отклонениям. Предусматривает сбор дан-
ных, характеризующих поведение легальных пользователей, в течение оп-
ределенного времени. Затем эти данные анализируются с применением ста-
тистических методов, чтобы с высокой степенью точности определить, соот-
354
Часть III. Защита систем
ветствует поведение определенного пользователя поведению легального
пользователя или нет.
• Использование пороговых значений. Данный подход предполагает опре-
деление не зависящих от конкретного пользователя пороговых значений,
характеризующих частоту возникновения различных событий.
• Использование профиля поведения. Создается профиль активности поль-
зователя и с его помощью выявляются отклонения в поведении пользова-
теля, регистрирующегося в системе под данным именем.
Плотность
распределения
вероятности
пользователя
Рис. 9.4. Профили характеристик поведения нарушителей и легальных
пользователей
2. Обнаружение по набору правил. Предполагает разработку набора правил,
на основе которых принимается решение о том, что данный тип поведения
является поведением нарушителя.
• Выявление аномалий. Разрабатываются правила, позволяющие обнару-
жить отклонения от наблюдавшегося ранее поведения.
• Идентификация вторжения. Подход на основе использования экспертной
системы, выявляющей подозрительное поведение.
По сути, в подходе, основанном на статистических методах, делается попытка
определить нормальное или ожидаемое поведение, тогда как в подходе, основан-
ном на правилах, делается попытка выявить правильное поведение.
Глава 9. Нарушители и вирусы
355
Относительно типов нарушителей, определенных в начале главы, выявление
статистических аномалий эффективно против имитаторов, которые вряд ли ста-
нут подражать поведению легального пользователя, под именем которого они
входят в систему. В то же время эта методика практически неприменима к пра-
вонарушителям. Против атак правонарушителей более эффективен подход, осно-
ванный на использовании правил, позволяющих распознать отдельные события
и их последовательности, которые в определенном контексте означают вторже-
ние. На практике в системе реализуется некоторая комбинация обоих подходов,
что обеспечивает эффективное противостояние широкому спектру нарушений.
Контрольные записи
Основным средством обнаружения нарушений является контрольная запись
(audit record), когда предполагается запись информации о некоторых выполняе-
мых пользователями операциях для последующего применения таких записей в
качестве исходных данных системы обнаружения нарушений. Чаще всего при-
меняют следующие две стратегии.
• Системные контрольные записи (native audit records). Практически все
многопользовательские операционные системы содержат программы для
сбора информации о действиях, выполняемых пользователями. Преимуще-
ство использования этой информации заключается в том, что для этого не
требуется никакого дополнительного программного обеспечения. Недостаток
связан с тем, что системные контрольные записи могут не содержать необ-
ходимой информации или содержать ее в неподходящей форме.
• Специальные контрольные записи (detection-specific audit records). Могут быть
разработаны и применяться специальные средства сбора информации, генери-
рующие записи, содержащие только данные, необходимые для работы системы
обнаружения нарушений. Преимуществом такого подхода является независи-
мость от поставщика системы и переносимость на разные платформы. В качест-
ве недостатка следует отметить дополнительную нагрузку на систему из-за не-
обходимости выполнения двух программ ведения контрольных записей.
Хорошим примером специальных средств создания контрольных записей
является система, разработанная Дороти Деннинг (Dorothy Denning) [DENN87],
Каждая контрольная запись содержит следующие поля.
• Subject (субъект). Инициатор действия. Субъектом обычно является пользо-
ватель терминала, но это может быть и процесс, выполняемый для пользо-
вателя или группы пользователей. Все действия совершаются по командам,
исходящим от субъекта. Субъекты могут быть сгруппированы в классы по
уровням доступа, и эти классы могут пересекаться.
• Action (действие). Операция, выполняемая субъектом по отношению к объ-
екту, например, регистрация входа в систему, чтение, ввод-вывод данных,
выполнение программ.
• Object (объект). Акцептор действия. Примерами объектов являются файлы,
программы, сообщения, записи, терминалы, принтеры, а также структуры, соз-
данные пользователями или программами. Когда акцептором действия являет-
ся субъект (например, при получении электронной почты), этот субъект тоже
рассматривается в качестве объекта. Объекты могут быть сгруппированы по ти-
356
Часть III. Защита систем
паи. При этом дискретизация объектов по типам и окружению может быть
разной. Например, действия в базе данных могут регистрироваться как на
уровне базы данных в целом, так и на уровне отдельных записей.
• Exception-Condition (исключительная ситуация). Указывает тип исключи-
тельной ситуации, возникающей при возвращении вызова.
• Resource-Usage (использование ресурса). Список количественных показателей,
в котором каждый элемент указывает объем использования того или иного ре-
сурса (например, число напечатанных или отображенных на экране строк, чис-
ло прочитанных или созданных записей, время использования процессора, чис-
ло задействованных каналов ввода-вывода, длительность сеанса связи).
• Time-stamp (штамп даты-времени). Уникальная метка даты и времени,
указывающая момент выполнения действия.
Большинство действий, выполняемых пользователем, складываются из на-
бора элементарных операций. Например, копирование файла означает выполне-
ние команды пользователя, предполагающей получение права доступа и созда-
ния копии, чтение из одного файла и запись в другой файл. Рассмотрим команду
COPY GAME.EXE ТО <Library>GAME.EXE,
инициированную пользователем Smith с целью копирования исполняемого фай-
ла GAME из текущего каталога в каталог <Library>. В этой ситуации могут ге-
нерироваться следующие контрольные записи.
Smith execute <Library>COPY.EXE 0 C₽U=00002 11058721678
Smith read <Smith>GAME.EXE 0 RECORDS=0 11058721679
Smith execute <Library>COPY.EXE write-viol RECORDS=0 11058721680
В нашем примере процесс копирования завершается аварийно, поскольку поль-
зователь Smith не имеет права записи в каталог <Library>.
Разложение действий пользователя на элементарные операции имеет сле-
дующие преимущества.
1. Поскольку объекты в системе являются защищаемыми сущностями, ис-
пользование элементарных операций позволяет проследить за всеми дейст-
виями, выполняемыми с данным объектом. Система может обнаруживать
попытки нарушения контроля доступа (при отсутствии отклонений от нор-
мы возвращаемых исключительных ситуаций) и выявлять успешные случаи
таких нарушений (при отсутствии отклонений от нормы в наборе объектов,
доступных данному субъекту).
2. Принцип создания контрольных записей для каждого объекта и каждого
действия упрощает модель и ее реализацию.
3. Простая и единообразная структура специальных контрольных записей по-
зволяет относительно просто получить соответствующую информацию или
хотя бы ее часть путем копирования из имеющихся системных контроль-
ных записей в специальные контрольные записи.
Глава 9. Нарушители и вирусы 357
Обнаружение по статистическим отклонениям
Как уже упоминалось, методы обнаружения статистических аномалий мож-
но разделить на две категории: обнаружение по пороговым значениям (threshold
detection) и обнаружение по профилю поведения (profile-based detection). Обна-
ружение по пороговым значениям предполагает ведение учета частоты возник-
новения событий определенного типа за определенный интервал времени. Если
частота превышает значение, которое считается разумным, система рассматрива-
ет этот инцидент как вторжение нарушителя.
Анализ пороговых значений в чистом виде оказывается слишком грубым и
не очень эффективным методом выявления нарушений даже при атаках средней
сложности. Необходимо правильно определить и пороговые значения, и времен-
ные интервалы. Поскольку разные пользователи работают по-разному, простое
использование пороговых значений будет приводить к многочисленным ошибоч-
ным срабатываниям (false positive) и несрабатываниям (false negative). Тем не
менее, простой детектор превышения пороговых значений может быть полезным
в совокупности с другими, более сложными методами.
Обнаружение по профилю поведения строится на изучении поведения поль-
зователя или группы пользователей, наблюдавшегося в прошлом, и сравнении
этого поведения с текущим поведением на предмет выявления значительных от-
клонений. Профиль может состоять из набора параметров, так что отклонения
по одному из параметров может быть недостаточно для того, чтобы генерировать
системную тревогу.
Данный подход опирается на анализ содержимого контрольных записей.
Контрольные записи обеспечивают ввод для функции выявления нарушений
следующим образом. Сначала разработчик должен решить, какое число па-
раметров необходимо отслеживать в поведении пользователя. Чтобы постро-
ить профиль активности типичного пользователя, можно провести анализ
контрольных записей на протяжении некоторого промежутка времени. Затем
содержимое текущих записей может использоваться в качестве исходных
данных, по которым выявляются нарушения. Таким образом, предлагаемая
модель выявления нарушений предполагает анализ поступающих контроль-
ных записей поведения на предмет отклонения этого поведения от обычного.
Примерами параметров, которые оказываются полезными при выявлении
нарушений по профилю поведения, являются следующие.
• Счетчик. Неотрицательное целое число, значение которого можно увеличи-
вать, но не уменьшать, до тех пор, пока это значение не будет переустанов-
лено в результате действия программы управления. Обычно подсчет наблю-
давшегося числа определенных событий ведется в течение некоторого про-
межутка времени. Примерами могут быть число попыток входа в систему,
предпринятых пользователем в течение одного часа, число вызовов опреде-
ленной команды в течение сеанса работы пользователя или число непра-
вильно введенных паролей в течение одной минуты.
• Датчик. Неотрицательное целое число, значение которого может как увели-
чиваться, так и уменьшаться. Обычно датчик предназначен для регистра-
ции текущего значения некоторой характеристики объекта. Примерами яв-
ляются число логических соединений, установленных приложением пользо-
358
Часть III. Защита систем
вателя, или число исходящих сообщений, поставленных в очередь пользо-
вательским процессом.
• Интервальный таймер. Длина периода времени между двумя последователь-
ными событиями. Например, длина периода времени между двумя последова-
тельными попытками регистрации по одной и той же учетной записи.
• Показатель использования ресурса. Объем потребления ресурса за опреде-
ленный промежуток времени. Примерами являются число страниц, отпеча-
танных за время сеанса работы, или общее время выполнения некоторой
программы.
Эти количественные показатели можно использовать в самых разных тес-
тах, чтобы выяснить, не выходит ли текущая деятельность пользователя за рам-
ки установленных границ. В [DENN87] приводится следующий список методов,
которые можно применять с указанной целью.
• Метод средних значений и среднеквадратических отклонений.
• Метод многомерной модели.
• Метод марковских процессов.
• Метод временных рядов.
• Операторный метод.
Самый простой статистический тест заключается в рассмотрении сред-
них значений и среднеквадратических отклонений параметров за определен-
ный период времени. Результаты характеризуют среднее поведение и его от-
клонение от среднего. Использовать средние значения и среднеквадратиче-
ские отклонения можно для широкого спектра счетчиков, таймеров и
показателей использования ресурсов. Значения этих параметров сами по себе
обычно дают слишком грубую оценку, чтобы использовать их непосредствен-
но для обнаружения вторжения.
Метод многомерной модели основывается на использовании корреляции
между двумя или несколькими переменными. Рассматривая такие корреляции
(например, для времени использования процессора и ресурсов или для частоты
входа в систему и длительности сеанса работы), поведение нарушителя можно
характеризовать с большей надежностью.
Метод марковских процессов служит для определения вероятностей перехо-
дов между различными состояниями. Эта модель позволяет выяснить, например,
характер связи между определенными командами.
Метод временных рядов основан на анализе интервалов времени с целью
обнаружения событий, которые проходят либо слишком быстро, либо слишком
медленно. При этом для выявления временных аномалий тоже можно приме-
нять различные статистические преобразования.
Наконец, операторная модель базируется на определении того, что счи-
тается выходящим за рамки обычного, а не на автоматическом анализе со-
держимого сохраненных контрольных записей. Обычно устанавливаются
четко определенные границы, выход за пределы которых считается призна-
ком вторжения в систему. Этот подход лучше всего работает тогда, когда по-
ведение нарушителя характеризуется действиями определенного типа. На-
Глава 9. Нарушители и вирусы
359
пример, большое число попыток входа в систему и регистрации за короткий
период времени позволяет сделать вывод о попытке вторжения.
В качестве примера использования рассмотренных выше параметров и мо-
делей рассмотрим табл. 9.3, в которой собраны сведения о различных критери-
ях, учитываемых в системе обнаружения нарушений IDES, используемой в
Стэнфордском исследовательском институте (Stanford Research Institute — SRI)
[DENN87, JAVI91, LUNT88].
Таблица 9.3. Критерии, используемые для обнаружения нарушений
Критерий Модель Тип выявляемых нарушений
Вход в систему и сеанс работы пользователя
Частота входов в систему по дням и часам Средние значения и средне- Нарушители чаще всего пы- квадратические отклонения таются войти в систему в не- рабочее время
Частота входов в систему из разных мест Средние значения и средне- Нарушители могут входить в квадратические отклонения систему из таких мест, где соответствующий легальный пользователь бывает очень редко или не бывает никогда
Время, прошедшее с момента последнего входа в систему Операторная модель Попытка вторжения в систему по “ничейной” учетной записи
Длительность сеансов работы Средние значения и средне- Значительные отклонения мо- квадратические отклонения гут означать работу имитатора
Объем данных, пересылае- мых в определенное место Средние значения и средне- Слишком большие объемы квадратические отклонения данных, передаваемые на уда- ленные узлы, могут означать утечку важной информации
Показатель использования ресурсов во время сеанса Средние значения и средне- Выходящие за рамки обыч- квадратические отклонения ных показатели загрузки процессора или устройств ввода-вывода могут означать работу нарушителя
Число вводов неправильных значений пароля при реги- страции Операторная модель Попытки проникновения в систему с помощью угадыва- ния пароля
Неудачные попытки входа в систему с определенных терминалов Операторная модель Попытки вторжения в систему
Выполнение команд или программ
Частота запуска программ Средние значения и средне- Может указывать на присутст- квадратические отклонения вие нарушителя, который про- бует доступные ему команды, или же на легального пользова- теля, получившего доступ к привилегированным командам
360
Часть III. Защита систем
Окончание табл. 9.3
Критерий Модель Тип выявляемых нарушений
Использование ресурсов программами Средние значения и средне- квадратические отклонения Выходящее за рамки обычно- го значение может означать внедрение вируса или троян- ского коня, которые в фоно- вом режиме выполняют опе- рации, увеличивающие за- грузку системы ввода-вывода или процессора
Число отказов выполнения Операторная модель Может означать попытки ле- гального пользователя полу- чить привилегии более высо- кого уровня
Доступ к файлам
Частота выполнения опера- ций чтения, записи, созда- ния, удаления Средние значения и средне- квадратические отклонения Выходящая за рамки обыч- ной частота операций доступа к файлам для чтения и запи- си может означать присутст- вие имитатора или просмотр ресурсов
Чтение имеющихся записей и сохранение информации Средние значения и средне- квадратические отклонения Выходящие за рамки обычных показатели могут означать по- пытки получить важные дан- ные путем сбора информации и логических заключений
Подсчет неудачных попыток чтения, записи, создания, удаления Операторная модель Могут обнаруживать пользова- телей, которые постоянно пы- таются получить несанкциони- рованный доступ к файлам
Главное преимущество использования статистических профилей состоит в том,
что для их применения не нужно заранее знать обо всех изъянах в системе защиты.
Программа-детектор выясняет, какое поведение является “нормальным”, а затем
выявляет отклонения. Данный подход не основан на характеристиках системы и
сведениях о ее уязвимости, поэтому соответствующая реализация легко переносится
с одной системы на другую.
Обнаружение по набору правил
Методы обнаружения нарушений, основанные на использовании правил,
предполагают отслеживание происходящих в системе событий и применение на-
бора правил, по которым можно вынести заключение, является данное поведе-
ние подозрительным или нет. Подобные методы можно разделить на два класса:
методы, основанные на выявлении аномалий, и методы, идентифицирующие
преодоление защиты.
Выявление аномалий в данном случае похоже по подходам и возможностям на
методы выявления статистических отклонений. При использовании базы правил
Глава 9. Нарушители и вирусы
361
анализ сохраненных контрольных записей проводится с целью выявления характе-
ристик типичного поведения и автоматического генерирования правил, описываю-
щих такое поведение. Правила могут представлять поведенческие шаблоны пользо-
вателей, программ, привилегий, временных интервалов, терминалов и т.п. Затем на-
блюдается текущее поведение и каждая транзакция проверяется по набору правил
на предмет ее соответствия полученным ранее поведенческим шаблонам.
Как и при анализе статистических отклонений, выявление аномалий, основан-
ное на правилах, не требует знания уязвимых мест защиты системы. Схема опирает-
ся на наблюдение за поведением пользователей и на предположение о том, что в бу-
дущем это поведение не должно существенно измениться. Чтобы этот подход оказал-
ся эффективным, потребуется достаточно большая база правил. Например, схема,
описанная в [VACC89], требует использования от 104 до 10б правил.
Идентификация преодоления защиты основана совершенно на другом под-
ходе, связанном с технологией экспертных систем. Основной чертой таких сис-
тем является использование правил для идентификации известных видов втор-
жений или вторжений, построенных на известных недостатках систем защиты.
Можно определить и правила для идентификации подозрительного поведения,
даже если поведение не выходит за рамки типичного. Обычно правила, приме-
няемые в таких системах, зависят от конкретного типа машины и операционной
системы. Кроме того, такие правила генерируются, скорее, экспертами, а не в
результате автоматического анализа контрольных записей. Чаще всего выполня-
ется опрос системных администраторов и аналитиков системы защиты, чтобы в
результате получить пакет известных сценариев и событий, несущих угрозу
безопасности защищаемой системы.2 Таким образом, успех данного подхода за-
висит от профессионализма тех, кто участвует в выработке системы правил.
Простой пример типов правил, которые могут при этом использоваться,
можно найти в системе NDIX — одной из первых систем эвристических правил,
с помощью которых можно определить степень подозрительности той или иной
деятельности [BAUE88J. Вот примеры таких эвристических правил.
1. Пользователи не должны читать файлы, находящиеся в личных каталогах
других пользователей.
2. Пользователи не имеют права записывать информацию в файлы, принадле-
жащие другим пользователям.
3. Пользователи, постоянно работающие с системой, часто при новом входе в
систему открывают те же файлы, которые использовались ими раньше.
4. Пользователи редко открывают дисковые устройства напрямую, а используют
для этого утилиты высшего уровня, предлагаемые операционной системой.
5. Пользователи не должны открывать несколько сеансов работы с одной и той
же системой одновременно.
6. Пользователи не копируют системные программы.
Схема идентификации вторжений, реализованная в упоминавшейся выше сис-
теме IDES, основана на использовании следующей стратегии. Контрольные записи по
мере их появления проверяются по базе правил. Если обнаруживается совпадение,
2 В таких опросах могут участвовать даже бывшие и настоящие взломщики сис-
тем, которые согласны поделиться своим опытом за определенную плату [FREE93].
362
ЧаСТЬ ТУТ. Яят татя тхг-ггатчг
происходит увеличение рейтинга подозрения (suspicion rating) пользователя. Если
совпадения наблюдаются для достаточно большого числа правил, рейтинг превысит
заданный порог и система генерирует отчет об обнаруженной аномалии.
Подход IDES основан на проверке контрольных записей. Слабой стороной
этого подхода является недостаточная гибкость. Например, можно реализовать
такой сценарий вторжения, когда система генерирует ряд последовательностей
контрольных записей, слабо отличающихся от других. Учесть такие отклонения
с помощью правил совсем непросто. Другой метод заключается в разработке мо-
дели более высокого уровня, не зависящей от данных контрольных записей.
Примером такой модели является модель переходов состояний, известная под
названием USTAT [ILGU93]. Модель USTAT имеет дело с действиями в целом, а
не специальными действиями, регистрируемыми с помощью системы контроля
UNIX. Модель USTAT реализована в системе SunOS, где она обеспечивает созда-
ние контрольных записей для 239 типов событий. Из них только 28 используют-
ся препроцессором, отображающим их в 10 действиях общего характера
(табл. 9.4). На основе только этих действий, а также параметров, необходимых
для каждого из них, строится диаграмма переходов, характеризующая подозри-
тельное поведение. Поскольку целый ряд контролируемых событий отображает-
ся в небольшой набор действий, процесс выработки правил значительно упроща-
ется. Кроме того, диаграмма переходов состояний модели легко модифицируется
с получением новых сведений о поведении нарушителей.
Таблица 9.4. Действия USTAT и типы событий SunOS
Действие USTAT Тип события SunOS
Read open_r, openrc, openrtc, openrwc, openrwtc, open_rt, open_rw, open_rwt
Write truncate, ftruncate, creat, open rtc, openrwc, open rwtc, open_rt, open_rw, openrwt, openw, openwt, openwc, open wet
Create mkdir, creat, open rc, open rtc, open rwc, open rwtc, open_wc, open_wtc, mknod
Delete rmdir, unlink
Execute exec, exeeve
Exit exit
Modify_Owner Modify_Perm Rename chown, fchown chmod, fchmod rename
Hardlink link
Распределенные системы выявления нарушений
До недавнего времени все работы по созданию системы обнаружения нару-
шений ограничивались рамками отдельно взятой вычислительной системы. Од-
нако типичной организации требуется обеспечить защиту распределенного ком-
плекса вычислительных узлов, объединенных локальной сетью или средствами
межсетевого взаимодействия. Конечно, можно защитить каждый узел в отдель-
ности, используя в каждом из них свою систему обнаружения нарушений, но
Глава 9. Нарушители и вирусы
363
более эффективная защита достигается путем координации и взаимодействия
систем обнаружения нарушений в сети.
В работе [PORR92] Поррас (Porras) формулирует следующие вопросы, возни-
кающие при проектировании распределенной системы обнаружения нарушений.
• Распределенной системе обнаружения нарушений, возможно, придется
иметь дело с разными форматами контрольных записей. В разнородной сре-
де разные системы могут иметь разные средства создания контрольных за-
писей, поэтому для обнаружения нарушений эти системы могут использо-
вать контрольные записи разных форматов.
• Некоторые узлы сети должны быть местом накопления и анализа данных,
поступающих к ним от других систем в сети. Поэтому либо “сырые”, либо
уже обработанные данные должны будут передаваться по сети. Значит, не-
обходимо обеспечить целостность и конфиденциальность этих данных. Це-
лостность не позволит нарушителю маскировать свою деятельность путем
изменения передаваемой контрольной информации. Конфиденциальность
требуется потому, что контрольная информация может оказаться очень
важной для поддержания работоспособности системы.
• Система может иметь как централизованную, так и децентрализованную
архитектуру. В первом случае предполагается наличие единого центра, в
котором накапливаются и анализируются все контрольные данные. Это
упрощает задачу согласования поступающих отчетов, но создает потен-
циально “узкое место”, отказ в котором может привести к выходу из
строя всей системы. При использовании децентрализованной архитекту-
ры имеется несколько аналитических центров, однако при этом требует-
ся координировать их деятельность и организовать обмен информацией
между ними.
Хорошим примером распределенной системы обнаружения нарушений
является система, разработанная в отделении Калифорнийского университета
в Дэвисе (University of California at Davis) [HEBE92, SNAP91]. На рис. 9.5
показана общая архитектура этой системы, состоящей из следующих трех
основных компонентов.
• Модуль агента узла. Модуль сбора контрольной информации, выполняемый
в фоновом режиме в системе, за которой ведется наблюдение. Целью моду-
ля является сбор данных об имеющих отношение к защите узла событиях и
передача этих данных модулю центрального администратора.
• Модуль агента монитора локальной сети. Работа этого модуля аналогична
работе модуля агента узла, но данный модуль анализирует поток данных
локальной сети, тоже передавая полученные данные модулю центрального
администратора.
• Модуль центрального администратора. Принимает сведения, поступающие
от агентов узлов и монитора локальной сети, и обрабатывает их, выясняя
корреляцию и пытаясь обнаружить нарушение.
364
Часть III. Защита систем
Монитор
локальной
Рис. 9.5. Архитектура распределенной системы выявления нарушений
При разработке схемы ставилась задача ее независимости от операцион-
ной системы и конкретных реализаций системы контроля. На рис. 9.6
[SNAP91] показана общая структура подхода, применявшегося в этом слу-
чае. Агент просматривает каждую контрольную запись, порожденную систе-
мой регистрации контрольных параметров соответствующей системы. Запи-
си, не представляющие интереса с точки зрения защиты, отфильтровывают-
ся. Остальные записи преобразуются в стандартный формат контрольной
записи хоста (Host Audit Record — HAR). Затем использующий набор шаб-
лонов логический модуль анализирует полученные записи на предмет выяв-
ления подозрительных действий. Прежде всего агент проводит поиск в запи-
сях событий, представляющих интерес с точки зрения защиты независимо от
их связи с прошлыми событиями. Примерами таких событий являются отка-
зы в доступе к файлам, доступ к системным файлам и изменение параметров
контроля доступа к файлам. На следующем уровне поиска агент ищет после-
довательности событий, соответствующих уже известным попыткам взлома
(так называемые сигнатуры). Наконец, агент пытается найти аномалии по-
ведения отдельных пользователей, основываясь на имеющемся для каждого
пользователя профиле, содержащем сведения о числе выполняемых про-
грамм, числе файлов, к которым был получен доступ, и т.п.
Если обнаруживается подозрительная активность, центральному адми-
нистратору направляется извещение. Модуль центрального администратора
включает экспертную систему, способную выявлять взаимозависимость полу-
чаемых данных. Модуль центрального администратора может запросить у
отдельных узлов копии их записей HAR, чтобы сравнить их с записями дру-
гих агентов.
Глава 9. Нарушители и вирусы
365
Контрольная
информация ОС
Рис. 9.6. Архитектура агента
Модуль монитора локальной сети тоже предоставляет собранные им данные
модулю центрального администратора. Агент монитора локальной сети контро-
лирует соединения между узлами, используемые службы и уровень трафика.
Этот агент регистрирует все заметные события, например резкое изменение за-
грузки сети, использование служб защиты и сетевые операции типа rlogin.
Архитектурные решения, показанные на рис. 9.5 и 9.6, оказываются доста-
точно общими и гибкими. Они позволяют использовать машинно-независимый
подход при построении систем выявления нарушений в масштабе от уровня от-
дельного узла до уровня достаточно большой сети, когда на основе сравнения
активности отдельных узлов сети обнаруживаются подозрительные действия,
которые иначе остались бы незамеченными.
9.2. ВИРУСЫ И УГРОЗЫ, СВЯЗАННЫЕ
С ВИРУСАМИ
По-видимому, наиболее изощренную угрозу для компьютерных систем
представляют собой программы, использующие уязвимые места защиты систем.
В данном контексте могут рассматриваться не только прикладные программы,
но и служебные, такие как редакторы и компиляторы.
Мы начнем следующий раздел с обзора всего спектра программных угроз.
Остальная часть раздела будет посвящена вирусам. Сначала будет рассмотрена
их природа, а затем — соответствующие контрмеры.
366
Часть III. Защита систем
Вредоносные программы
На рис. 9.7 (см. [BOWL92]) показана общая схема классификации про-
граммных угроз, или вредоносных программ. Такие программы можно разде-
лить на две категории: программы, нуждающиеся в программе-носителе, и неза-
висимые программы. К первой категории относится программный код, который
не может работать независимо от некоторой реальной прикладной программы
или утилиты. Ко второй категории относятся самостоятельные программы, ко-
торые могут быть запущены стандартными средствами операционной системы,
как любая другая программа.
Рис. 9.7. Классификация вредоносных программ
Способны размножаться
Кроме того, мы разделим вредоносные программы на обычные и размно-
жающиеся. К первым относятся фрагменты программ, которые активизируются,
когда программа-носитель выполняет вполне конкретные действия. Ко второй
группе могут относиться как программные фрагменты (вирусы), так и независи-
мые программы (“черви”, “бактерии”), во время работы создающие свои копии,
которые могут выполняться впоследствии в той же или другой системе.
Классификация, приведенная на рис. 9.7, позволяет систематизировать ин-
формацию по этому вопросу, но она не дает полного описания реальной карти-
ны. В частности, логические бомбы и “троянские кони” могут быть частями ви-
руса или “червя”.
Люки
Люк, или лазейка, — это секретная точка входа в программу, позволяющая
тому, кто знает о существовании люка, получить доступ в обход стандартных
процедур защиты. Люки уже много лет совершенно законно используются в
программистской практике для ускорения отладки и тестирования программ.
Эта возможность обычно применяется программистом при создании приложе-
ния, в состав которого входит процедура аутентификации или слишком долгая
Глава 9. Нарушители и вирусы
367
программа установки, требующая от пользователя ввода множества различных
параметров для запуска программы. Чтобы ускорить процесс отладки, разработ-
чик может воспользоваться специальным уровнем привилегий или обойти про-
цедуру установки или аутентификации. Для программиста удобно иметь воз-
можность запустить программу тогда, когда по причине каких-то неполадок
встроенная процедура аутентификации не позволяет этого сделать. Люк пред-
ставляет собой программный код, реагирующий на специальную последователь-
ность введенных с клавиатуры символов, либо активизирующийся в ответ на
ввод определенного идентификатора пользователя или последовательность ка-
ких-то маловероятных событий.
Люки представляют собой угрозу, когда они позволяют недобросовестным
программистам получить несанкционированный доступ. Именно люк был основ-
ной причиной угрозы, на которой построен сюжет фильма “Военные игры” (War
Games) [СООР89]. Еще одним примером является люк, использованный в рамках
тестирования системы Multics, проводимого “командой тигров” (командой моде-
лирования действий противника) ВВС США. Одним из решений была отправка
на узел, на котором выполнялась Multics, ложного пакета с обновлениями сис-
темы. В этом пакете содержался “троянский конь”, который активизировался
через люк и позволял “тиграм” получить доступ к системе. Угроза была реали-
зована настолько удачно, что разработчики Multics не смогли найти ее даже по-
сле того, как были информированы о ее существовании [ENGE80].
Реализовать выявление возможных лазеек стандартными средствами опера-
ционной системы очень трудно. Меры защиты в данном случае должны быть
сфокусированы на осуществлении контроля процесса разработки программного
обеспечения и его обновления.
Логические бомбы
Одним из самых старых типов вредоносных программ, возникших еще до по-
явления вирусов и “червей”, является логическая бомба. Логическая бомба пред-
ставляет собой программный код, внедренный в какую-то полезную программу,
который должен “взорваться” при выполнении определенных условий. Примерами
условий, которые запускают логическую бомбу, могут быть присутствие или от-
сутствие каких-то файлов, наступление определенного дня недели или определен-
ной даты, имя конкретного пользователя, инициировавшего запуск приложения. В
одном ставшем широко известным случае [SPAF89] логическая бомба проверяла
наличие определенного табельного номера сотрудника (автора бомбы) и срабатыва-
ла тогда, когда этот табельный номер отсутствовал в двух идущих подряд ведомо-
стях по начислению зарплаты.' После запуска бомба может изменять или удалять
данные файлов, вызывать зависание машины или выполнять какие-то другие раз-
рушительные действия. Впечатляющий пример того, как можно использовать ло-
гическую бомбу, дает дело о библиотечной системе, рассматривавшееся в суде ок-
руга Монтгомери, шт. Мэриленд [TIME90J. Подрядчик, разработавший библиотеч-
ную систему компьютеризованного учета, заложил в ее код логическую бомбу,
которая через некоторое время должна была сделать систему недоступной, если
подрядчику не заплатят за выполненную работу. Когда библиотека, основываясь
на том, что система слишком медленно реагирует на запросы, решила не оплачи-
вать финальную стадию работ, подрядчик сообщил о существовании бомбы и зая-
вил, что не уберет ее до тех пор, пока не получит своих денег.
368
Часть III. Защита систем
“Троянские кони”
“Троянский конь” представляет собой полезную или кажущуюся полезной
программу, содержащую скрытый код, который после запуска программы-
носителя выполняет нежелательные или разрушительные функции.
Программа этого типа может использоваться для опосредованного выполне-
ния операций, которые несанкционированный пользователь не может выполнить
непосредственно. Например, для получения доступа к файлам другого пользова-
теля на компьютере, находящемся в совместном пользовании нескольких чело-
век, злоумышленник может создать программу “троянского коня”, которая при
выполнении изменит параметры доступа к файлам этого пользователя, сделав их
открытыми для всех. Создав такую программу, автор может спровоцировать
других пользователей запустить ее, поместив программу в общедоступный ката-
лог и присвоив ей имя, которое большинству пользователей покажется именем
полезной программы или утилиты. Примером может служить программа, якобы
создающая только список файлов пользователя в нужном формате. После того
как другой пользователь запустит такую программу, автор программы может
получить доступ к информации, содержащейся в файлах этого пользователя.
Примером “троянского коня”, которого обнаружить очень трудно, является ком-
пилятор, модифицированный с целью внедрения дополнительного кода в про-
граммы определенного вида (например, в программы входа в систему) во время
их компиляции [ТНОМ84]. Соответствующий код создает в модуле регистрации
люк, позволяющий автору кода войти в систему с помощью специального паро-
ля. Обнаружить такого “троянского коня” по исходному коду программы входа в
систему будет просто невозможно.
Вторым побудительным мотивом создания “троянских коней” является раз-
рушение данных. В этом случае программа, выполняющая какие-то полезные
функции (например программа-калькулятор), может без каких бы то ни было
внешних проявлений удалить все файлы пользователя. Так, жертвой
“троянского коня” однажды оказался даже один из высокопоставленных чинов-
ников компании CBS, у которого эта программа уничтожила всю хранившуюся
на компьютере информацию [Т1МЕ90]. “Троянский конь” был внедрен в про-
грамму обработки графических данных, распространявшуюся через электронную
доску объявлений.
Вирусы
Вирус представляет собой программу, которая может “инфицировать” дру-
гие программы путем их модификации. В модифицированный код включается
код вируса, с помощью которого вирус может “заразить” другие программы.
Биологические вирусы являются небольшими фрагментами генетического
кода — ДНК или РНК, — использующими механизм жизнедеятельности живой
клетки для создания тысяч абсолютных копий оригинального вируса. Подобно
своему биологическому двойнику, компьютерный вирус несет в своем программ-
ном коде рецепт создания совершенных копий самого себя. Внесенный в компь-
ютерную систему, типичный вирус временно захватывает управление дисковой
операционной системой компьютера. Затем при каждом контакте зараженного
компьютера с незараженным программным обеспечением очередная копия виру-
са помещается в новую программу. Таким образом инфекция может передавать-
ся от компьютера к компьютеру ничего не подозревающими пользователями,
Глава 9. Нарушители и вирусы
369
обменивающимися содержимым магнитных дисков или пересылающими про-
граммы по сети. Сеть с ее возможностями доступа к приложениям и системным
службам других компьютеров является прекрасной “питательной средой” для
распространения вируса.
Подробнее о вирусах речь пойдет в этой главе ниже.
“Черви”
Программы-“черви” используют сетевые соединения для распространения от
одной системы к другой. Во время работы на отдельном компьютере сетевой
“червь” может вести себя как компьютерный вирус или “бактерия”, внедрять
“троянских коней”, или же выполнять какие-то другие разрушительные или
подрывные действия.
Для размножения сетевой “червь” использует сетевые средства доставки
информации. Примерами таких средств могут быть следующие службы.
• Электронная почта. “Червь” отправляет свою копию по почте в другую систему.
• Удаленный вызов программ. “Червь” запускает свою копию на выполнение
в другой системе.
• Доступ к удаленной системе. “Червь” входит в удаленную систему как
пользователь, а затем использует команду копирования себя из одной сис-
темы в другую.
Новая копия “программы-червя” в результате оказывается запущенной в уда-
ленной системе, где в дополнение ко всем другим предусмотренным операциям
“червь” продолжает размножаться указанным выше способом.
Сетевой “червь” во многом подобен компьютерному вирусу — у него тоже
есть инкубационный период, фаза распространения, фаза активизации и фаза
выполнения. В фазе распространения обычно выполняются следующие функции.
1. Поиск других подходящих для заражения систем путем проверки списков
известных данному компьютеру узлов или других подобных объектов, хра-
нящих информацию об адресах удаленных систем.
2. Установка соединения с удаленной системой.
3. Копирование своего кода в удаленную систему и инициирование ее запуска там.
Перед тем как копировать себя в другую систему, сетевой “червь” может также
пытаться проверить, не была ли система уже инфицирована ранее. В многозадачной
среде он может скрывать свое присутствие с помощью назначения себе имени, соот-
ветствующего системному процессу, или с помощью использования какого-то друго-
го имени, не вызывающего подозрения у системного оператора.
Так же как и вирусам, сетевым “червям” трудно противостоять. Однако ме-
ры сетевой защиты в совокупности с мерами по защите отдельных компьютер-
ных систем при условии их правильной разработки и применения значительно
уменьшают опасность, которую несут с собой “черви”.
“Бактерии”
“Бактерии” являются программами, не повреждающими сами по себе ника-
ких файлов. Единственной целью “бактерии” является воспроизведение себе по-
добных. Типичная “бактерия” может просто запустить две собственные копии в
370
Часть III. Защита систем
многозадачной среде или создать два новых файла, содержащих по копии ори-
гинальной программы-“бактерии”. Затем каждая из копий может создать еще
две копии и т.д. Скорость размножения “бактерий” растет экспоненциально, что
в конце концов приводит к быстрому захвату всех ресурсов процессора, памяти
или дискового пространства, а результатом является отказ пользователям в дос-
тупе к этим ресурсам.
Природа вирусов
Вирусы могут делать все, что могут делать обычные программы. Единственное
отличие состоит в том, что вирус присоединяется к другой программе и выполняется
скрытно в процессе работы программы-носителя. Во время работы вирус может вы-
полнить любую операцию, например, стереть файлы документов и программ.
Жизненный цикл типичного вируса состоит из четырех этапов.
1. Инкубационный период. Вирус никак не проявляется. В конце концов ви-
рус будет активизирован некоторым событием, например, наступлением оп-
ределенной даты, присутствием другой программы или файла, появлением
достаточного места на диске. Инкубационный период имеют не все вирусы.
2. Фаза распространения. Вирус помещает свою копию в другие программы
или в определенные системные области на диске. Все инфицированные про-
граммы будут содержать точную копию вируса, каждая их которых тоже
должна будет когда-нибудь пройти свою фазу распространения.
3. Фаза активизации. Вирус активизируется для выполнения функции, с ко-
торой он создавался. Фаза активизации может быть инициирована самыми
разными системными событиями, например, наличием определенного числа
копий данного вируса в системе.
4. Фаза выполнения. Выполняется содержащаяся в вирусе функция. Эта
функция может быть как вполне безобидной (например, вывод сообщения
на экран), так и совершенно деструктивной (например, уничтожение про-
грамм и файлов с данными).
Работа большинства вирусов построена в соответствии с особенностями ар-
хитектуры конкретной операционной системы, а в некоторых случаях даже кон-
кретных аппаратных средств. Таким образом, в основе работы вирусов лежит
использование недостатков и нюансов тех или иных систем.
Структура вируса
Вирус может помещаться в начало или конец исполняемой программы либо
встраиваться в нее каким-то иным образом. Идея действенности вируса состоит в
том, что при запуске программы-носителя сначала выполняется код вируса и
только затем — код самой программы.
В самых общих чертах структура вируса показана на рис. 9.8 (приводится
по [СОНЕ94]). В данном случае код вируса V добавляется в начало инфицируе-
мой программы в предположении, что точкой входа в программу является ее
первая строка.
Выполнение инфицированной программы начинается с выполнения кода
вируса следующим образом. В первой строке кода программы указана команда
перехода в начало основного кода вируса. Вторая строка представляет собой
Глава 9. Нарушители и вирусы
371
специальный маркер, используемый вирусом для проверки того, что програм-
ма, выбранная в качестве потенциальной жертвы, не была заражена этим ви-
русом раньше. При запуске инфицированной программы управление сразу же
передается в основное тело вируса. Программный код вируса сначала ищет не-
зараженные файлы и заражает их. После этого вирус может выполнить какие-
то другие действия, обычно враждебные по отношению к системе. Эти дейст-
вия могут иметь место при каждом запуске инфицированной программы или
же только при выполнении определенных условий. Закончив работу, вирус пе-
редает управление программе-носителю. Если инфицирование осуществляется
достаточно быстро, то пользователь вряд ли сможет заметить при запуске про-
граммы, что она заражена.
program V :=
{goto main;
1234567;
subroutine infect-executable :=
{loop:
file := get-random-executable-file;
if (first-line-of-file = 1234567)
then goto loop
else prepend V to file; }
subroutine do-damage :=
{whatever damage is to be done}
subroutine trigger-pulled :=
{return true if some condition holds}
main: main-program :=
{infect-executable;
if trigger-pulled then do-damage;
goto next;}
next:
}
Puc. 9.8. Пример простого вируса
Вирусы, построенные на основе только что описанной схемы, легко обна-
ружить, поскольку в результате инфицирования увеличивается длина файла за-
раженной программы. Чтобы обойти столь простые методы обнаружения, вирус
должен сжать исполняемый файл, чтобы инфицированная и неинфицированная
версии файла оказались одинаковой длины. На рис. 9.9 [СОНЕ94] показана об-
щая логика работы такого вируса. Наиболее важные строки вируса пронумеро-
ваны, а соответствующие операции иллюстрируются на рис. 9.10 [СОНЕ94].
Предполагается, что программа Р] инфицирована вирусом CV. Когда такая про-
грамма запускается на выполнение, управление передается вирусу, который де-
лает следующее.
372
Часть III. Защита систем
1. Обнаружив неинфицированный файл Р2, вирус сначала сжимает его, в ре-
зультате получая файл Р2, длина которого меньше исходной на длину кода
вируса.
2. Копия вируса присоединяется к началу сжатой программы.
3. Сжатая версия инфицированной оригинальной программы (к,) распако-
вывается.
4. Распакованная оригинальная программа выполняется.
program CV :=
{goto main;
01234567;
subroutine infect-executable :=
{loop;
file := get-random-exec utable-file;
if (first-line-of-file = 01234567) then goto loop;
(1) compress file;
(2) prepend CV to file;
}
main; main-program :=
{if ask-permission then infect-executable;
(3) uncompress rest-of-file;
(4) run uncompressed file;}
}
Puc. 9.9. Логика вируса, использующего сжатие
Рис. 9.10. Вирус, использующий сжатие
В рассмотренном выше примере вирус только размножается. Но он может
содержать и логическую бомбу, как описано в предыдущем примере.
Глава 9. Нарушители и вирусы
373
Начальное инфицирование
Попав в систему путем заражения некоторой программы, вирус получает
возможность при ее выполнении заразить некоторые другие или вообще все ис-
полняемые файлы данного компьютера. Таким образом, появления вирусной
инфекции можно не допустить, если не позволить вирусу попасть в систему. За-
дача предотвращения вирусного заражения относится к разряду очень сложных,
поскольку вирус может оказаться в любой программе, попадающей в систему
извне. Таким образом, в уязвимом положении оказывается любой, кто не создал
собственную операционную систему и все прикладное программное обеспечение с
помощью собственных аппаратных средств.
В большинстве случаев начальное инфицирование происходит через носите-
ли информации, с которых зараженные программы копируются в компьютер.
Многие из таких программ относятся к разряду игровых или же являются про-
стыми, но удобными утилитами, которыми служащие пользуются сначала на
своих домашних компьютерах, а затем приносят на работу. Иногда зараженные
программы содержатся даже на упакованных дистрибутивных дисках разработ-
чиков программного обеспечения. Только небольшая часть случаев инфицирова-
ния происходит через сетевые соединения, и чаще всего источником инфекции
служат электронные доски объявлений. Опять же, обычно служащий при этом
загружает из сети какую-нибудь игру или, казалось бы, полезную утилиту, ко-
торые, как выясняется впоследствии, содержат вирусы.
Типы вирусов
С тех пор как появились вирусы, началась и бесконечная борьба между авто-
рами вирусов и авторами антивирусных программ. Как только вырабатывались
эффективные методы противодействия уже известным вирусам, появлялись новые
типы вирусов. В [STEP93] предлагается следующая классификация вирусов.
• Паразитный вирус. Традиционная и до сих пор самая распространенная
форма вируса. Паразитный вирус добавляет свой код к исполняемым фай-
лам и размножается при каждом запуске инфицированной программы, на-
ходя другие файлы, которые можно было бы инфицировать.
• Резидентный вирус. Размещается в оперативной памяти как часть рези-
дентной системной программы. С момента размещения в памяти инфициру-
ет любую запускаемую программу.
• Загрузочный вирус. Инфицирует главную загрузочную запись или загрузочный
сектор и распространяется, когда система загружается с зараженного диска.
• Вирус-невидимка. Разновидность вируса, имеющего специально предусмот-
ренное свойство, защищающее вирус от обнаружения антивирусным про-
граммным обеспечением.
• Полиморфный (мимикрирующий) вирус. Вирус, код которого изменяется
при каждом новом заражении, что делает практически невозможным обна-
ружить его по “сигнатуре”.
Один из примеров вируса-невидимки (stealth virus) был рассмотрен выше:
вирус, использующий сжатие, чтобы длина инфицированного файла была в точ-
ности равна длине исходного. Существуют и другие, гораздо более хитроумные
374
Часть III. Защита систем
решения. Например, вирус может перехватывать обращения к функциям ввода-
вывода и при попытках прочитать подозрительные части диска с помощью этих
функций возвращать оригинальные неинфицированные версии программ. Таким
образом, применяемая в данном случае характеристика стеле (скрытный) отно-
сится не столько к вирусам, сколько к технологии, обеспечивающей вирусу за-
щиту от обнаружения.
Полиморфный вирус создает при размножении копии, эквивалентные по
функциям, но существенно различающиеся по двоичному представлению кода.
Как и в случае с вирусами-невидимками, это делается с целью противостоять
программам, обнаруживающим вирусы. Для изменения представления кода ви-
рус может вставлять в свой код генерируемые случайным образом избыточные
команды или же изменять порядок следования независимых команд. Более эф-
фективным подходом является шифрование. Часть вируса, называемая меха-
низмом управления мутациями, генерирует случайное значение ключа, с помо-
щью которого шифрует остальной код вируса. Ключ сохраняется вместе с виру-
сом, а механизм управления мутациями видоизменяется. Во время запуска
инфицированной программы вирус с помощью сохраненного ключа расшифро-
вывается. При новом инфицировании генерируется новый ключ.
Еще одним оружием в арсенале авторов вирусов является пакет инструмен-
тальных средств для разработки вирусов. Такой пакет позволяет даже новичку бы-
стро создать целый набор вирусов разных типов. Хотя вирусы, созданные с помощью
пакета инструментальных средств разработки, обычно оказываются менее изощрен-
ными в сравнении с вирусами, созданными “с нуля”, неограниченное число новых
вирусов, которые можно генерировать с помощью пакета, представляет собой доста-
точно серьезную проблему для схем антивирусной защиты.
Еще одним средством разработчика вирусов являются электронные доски
объявлений, посвященные вопросам создания вирусов. Целый ряд таких элек-
тронных досок объявлений существует в ОПТ A [ADAM92], немало их и в других
странах. На всех соответствующих узлах предлагаются копии вирусов, а также
рекомендации по созданию собственных вирусов.
Макровирусы
За последние годы число вирусов, регистрируемых на корпоративных узлах,
стремительно растет [BERG97]. Практически весь этот прирост связан с распростра-
нением нового типа вирусов, называемых макровирусами. Согласно информации
NCSA (National Computer Security Agency — Национальное агентство компьютерной
безопасности США), которая доступна по адресу www.nsca.com, макровирусы сегодня
составляют две трети от общего числа вирусов.
Макровирусы особенно опасны по следующим причинам.
1. Макровирусы независимы от платформы. Так, практически все макровирусы
поражают документы Microsoft Word. Поэтому любая аппаратно-программная
система, поддерживающая Word, может быть заражена таким вирусом.
2. Макровирусы инфицируют документы, а не выполняемый код. Информа-
ция, вводимая в компьютерную систему, по большей части представлена в
форме документов, а не программ.
3. Макровирусы быстро распространяются. Чаще всего распространение про-
исходит по электронной почте.
Глава 9. Нарушители и вирусы
375
Существование макровирусов построено на использовании средств поддержки
макросов, предлагаемых в Word и других офисных приложениях (например, Micro-
soft Excel). По сути, макрос представляет собой программу, встроенную в документ
текстового процессора или файл какого-то другого типа. Обычно пользователи при-
меняют макросы для того, чтобы автоматизировать выполнение часто повторяемых
действий, что позволяет экономить время. Язык макросов чаще всего является ка-
ким-нибудь вариантом языка программирования Basic. Пользователь может запи-
сать последовательность нажатий клавиш в виде макроса, а затем настроить про-
грамму так, чтобы записанный макрос вызывался нажатием функциональной кла-
виши или какой-то специальной комбинации клавиш.
Создание макровирусов оказывается возможным благодаря существованию ав-
томатических макросов. Это макросы, которые выполняются автоматически, без яв-
ной активизации их пользователем. Типичными автоматически происходящими со-
бытиями являются открытие, закрытие файла, а также запуск приложения. Во вре-
мя своего выполнения макрос может копировать себя в другой документ, удалять
файлы и выполнять любые другие действия, разрушающие систему пользователя. В
Microsoft Word существует три типа автоматических макросов.
• AutoExec. Макрос с зарезервированным именем AutoExec, размещенный в
шаблоне normal.dot или в глобальном шаблоне, хранящемся в каталоге
запуска Word, и автоматически выполняющийся при запуске Word.
• Автомакрос. Выполняется, когда происходит определенное событие, напри-
мер открытие или закрытие документа, создание нового документа или за-
вершение работы Word.
• Командный макрос. Если находящийся в глобальном файле макросов или
связанный с текущим документом макрос имеет имя, совпадающее с назва-
нием команды Word, он будет выполняться при каждом вызове этой ко-
манды (например, команды FileSave) пользователем.
Обычно распространение макровируса происходит следующим образом. Ав-
томакрос или командный макрос вставляется в документ Word, который переда-
ется в компьютерную систему по электронной почте или с внешнего носителя
информации. В какой-то момент после открытия документа макровирус начина-
ет выполняться. Он копирует свой код в глобальный файл макросов. При сле-
дующем запуске Word становится активным инфицированный глобальный файл
макросов. При выполнении макрос может размножаться и выполнять действия,
наносящие вред системе.
В современные версии Word встроена защита от макровирусов. Microsoft
предоставляет в распоряжение пользователя средство защиты от макровирусов,
выявляющее подозрительные файлы Word и предупреждающее пользователя об
опасности, связанной с открытием файлов, содержащих макросы. Ведущие раз-
работчики антивирусных программ тоже создали средства для обнаружения и
удаления опасных макровирусов. Однако, как и с любыми другими вирусами,
“гонка вооружений” в области макровирусов продолжается.
Антивирусная защита
Идеальным решением проблемы вирусов является предотвращение инфици-
рования: не следует допускать начального проникновения вируса в компьютер-
376
Часть III. Защита систем
ную систему. Этой цели в общем достичь невозможно, хотя предпринятые пре-
вентивные меры могут снизить вероятность успешного завершения вирусной
атаки. Идеальный подход должен обеспечивать решение следующих задач.
• Обнаружение. Если заражение произошло, оно должно быть немедленно
обнаружено с установлением места обитания вируса.
• Идентификация. Обнаружив заражение вирусом, необходимо идентифици-
ровать его тип.
• Удаление. Как только вирус будет идентифицирован, следует удалить все
следы вируса из инфицированных программ и восстановить программы в их
исходном виде. Важно удалить вирус из всех инфицированных систем, что-
бы болезнь не распространялась дальше.
Если вирус обнаружен, но его не удается идентифицировать или удалить из сис-
темы, альтернативой является удаление инфицированной программы с после-
дующей ее новой загрузкой с резервной копии.
Технологии разработки вирусов и антивирусов идут рука об руку. Первые
вирусы представляли собой сравнительно простые фрагменты кода и могли быть
удалены с помощью относительно простых антивирусных программ. По мере ус-
ложнения вирусов антивирусное программное обеспечение тоже становилось все
сложнее и изощреннее.
В [STEP93] антивирусные программы разделяются на четыре поколения.
• Первое поколение: обычные сканеры.
• Второе поколение: эвристические анализаторы.
• Третье поколение: мониторы.
• Четвертое поколение: полнофункциональные системы защиты.
Антивирусные программы-сканеры первого поколения для идентификации ви-
русов использовали характерные для соответствующих вирусов сигнатуры. Вирусы
могли содержать “групповые символы”, но все копии вируса имели в основном одну
и ту же структуру и неизменный код. Такие программы-сканеры, использующие
сигнатуры, могли обнаруживать только известные вирусы. Другой тип сканеров пер-
вого поколения предполагал поиск несоответствий текущих значений длин файлов в
сравнении со значениями, сохраненными в специальной базе данных.
Сканеры второго поколения уже не ориентированы на конкретные сигнату-
ры. Вместо этого в них начали применять эвристический анализ, с помощью ко-
торого можно сделать вывод о вероятном наличии вируса в программе. Одна из
разновидностей таких сканеров предполагала поиск в программе фрагментов ко-
да, характерного для вирусов. Например, сканер мог искать начало цикла шиф-
рования, используемого полиморфным вирусом, и пытаться открыть ключ шиф-
рования. Получив ключ, сканер мог расшифровать тело вируса, идентифициро-
вать вирус, удалить его из программы и вернуть программу в рабочее состояние.
Другим подходом, применявшимся в антивирусных программах второго по-
коления, была проверка целостности. С каждой программой можно связать кон-
трольную сумму. Если вирус инфицирует программу, не меняя при этом кон-
трольной суммы, то проверка целостности обязательно это обнаружит. Чтобы
противостоять вирусам, которые при заражении меняют соответствующую кон-
трольную сумму, можно использовать некоторую шифрованную функцию хэши-
Глава 9. Нарушители и вирусы
377
рования. Ключ шифра хранится отдельно от программы, чтобы вирус не мог
сгенерировать новый хэш-код и зашифровать его. Использование функции хэ-
ширования с шифрованием вместо обычной контрольной суммы не дает вирусу
возможности модифицировать программу так, чтобы результат хэширования по-
сле инфицирования не изменился.
Программы третьего поколения представляют собой резидентные программы,
выявляющие вирусы по выполняемым ими действиям, а не по их коду в инфициро-
ванной программе. Преимущество таких программ заключается в том, что для них
не требуется постоянно обновлять базу данных сигнатур и эвристик для все больше-
го числа новых вирусов. Вместо этого достаточно определить относительно неболь-
шой набор действий, характеризующих возможные проявления вируса.
Продукты четвертого поколения представляют собой пакеты, объединяющие в
единое целое все существующие антивирусные технологии. Такой подход, помимо
выполнения сканирования и наличия компонентов, позволяющих регистрировать
определенные действия вирусов, предполагает наличие средств управления доступом.
Эти средства позволяют ограничить возможности вирусов по проникновению в сис-
тему и внесению изменений в файлы под видом обновления.
Вирусная “гонка вооружений” продолжается. С появлением пакетов четвер-
того поколения появилась возможность построить всеобъемлющую стратегию
антивирусной защиты, являющейся органической частью общей безопасности
компьютерных систем.
Перспективные методы антивирусной защиты
В результате постоянной разработки все более совершенных подходов к
осуществлению антивирусной защиты появляются новые и более надежные про-
дукты. В следующем разделе мы остановимся на двух наиболее важных направ-
лениях развития данной области защиты систем.
Полное декодирование
Технология полного декодирования (General Decryption — GD) позволяет анти-
вирусной программе легко обнаруживать даже самые сложные полиморфные виру-
сы, сохраняя при этом высокую скорость сканирования [NACH97]. Напомним, что
при выполнении содержащего полиморфный вирус файла перед активизацией вирус
должен быть расшифрован. Для выявления подобных структур выполняемый файл
проходит через GD-сканер, состоящий из следующих элементов.
• Эмулятор процессора. Представляет собой программную реализацию вирту-
ального компьютера. Команды выполняемого файла интерпретируются эму-
лятором вместо того, чтобы выполняться реальным процессором. Эмулятор
содержит программные версии всех регистров и других аппаратных средств
процессора, так что сам процессор оказывается вне зоны действия про-
грамм, интерпретируемых эмулятором.
• Сканер сигнатур вирусов. Модуль, выполняющий сканирование проверяе-
мого кода на предмет выявления в нем сигнатур известных вирусов.
• Модуль управления эмуляцией. Управляет процессом выполнения прове-
ряемого кода.
378
Часть III. Защита систем
Загрузив программу, эмулятор начинает интерпретировать одну за одной
команды проверяемого кода. Если в программе содержится процедура дешифро-
вания тела вируса, ее код тоже будет интерпретирован. В результате вирус сам
откроет себя антивирусной программе. Периодически модуль управления преры-
вает ход эмуляции, чтобы выполнить сканирование полученного кода на предмет
наличия в нем сигнатур вирусов.
Во время интерпретации код вируса не может нанести реального вреда системе,
так как он выполняется в изолированной и контролируемой виртуальной среде.
Самым сложным вопросом реализации GD-сканеров является определение
того, как долго нужно выполнять интерпретацию проверяемой программы.
Обычно вирус активизируется вскоре после запуска программы, но это правило
не является догмой. Чем дольше эмулятор проверяет программу, тем выше ве-
роятность обнаружения скрытых вирусов. Однако неоправданно большое время
проверки и высокие требования к потребляемым ресурсам, очевидно, не очень
удовлетворяют пользователей.
Цифровая иммунная система
Цифровая иммунная система представляет собой сложную технологию ан-
тивирусной защиты, разработанную компанией IBM [КЕРН97а, КЕРН97Ь]. При-
чиной разработки послужила возрастающая угроза распространения вирусов че-
рез Internet. Сначала мы скажем несколько слов о самой угрозе, а затем перей-
дем к описанию подхода, предложенного IBM.
В настоящее время угроза вирусной инфекции характеризуется относитель-
но низкой частотой появления новых вирусов и новых мутаций старых вирусов.
Антивирусное программное обеспечение обновляется, как правило, ежемесячно,
и это оказывается достаточным для того, чтобы держать проблему под контро-
лем. Кроме того, сегодня Internet играет относительно второстепенную роль в
распространении вирусов. Однако, как отмечается в [CHES97], в ближайшие го-
ды скорость распространения вирусов может существенно возрасти под влиянием
следующих тенденций развития технологий Internet.
• Интегрированные почтовые системы. Системы типа Lotus Notes и Microsoft
Outlook допускают пересылку чего угодно и кому угодно, и при этом работа
с полученными по почте объектами оказывается очень простым делом.
• Мобильные программы. Технологии, подобные Java и ActiveX, позволяют
программам самостоятельно перемещаться из одной системы в другую.
В ответ на угрозу распространения вирусов, которую потенциально несут
эти возможности Internet, IBM разработала прототип цифровой иммунной сис-
темы. Эта система развивает технологию эмуляции, о которой говорилось в пре-
дыдущем разделе, предлагая комплекс эмулятора общего назначения и системы
обнаружения вирусов. Целью цифровой иммунной системы является создание
схемы быстрого реагирования, позволяющей регистрировать вирусы практиче-
ски в момент их появления. Когда новый вирус появляется в вычислительной
сети организации, иммунная система находит его, анализирует, добавляет необ-
ходимые средства обнаружения этого вируса и защиты от него, удаляет вирус и
передает информацию о попытке проникновения вируса системам AntiVirus
компании IBM, чтобы вирус и в других местах мог быть выявлен до того, как
начнет выполняться.
Глава 9. Нарушители и вирусы
379
Рис. 9.11. Цифровая иммунная система
На рис. 9.11 показана схема основных действий цифровой иммунной системы.
1. Специальная программа, работающая на каждом персональном компьютере,
выполняет мониторинг, используя различные методы эвристического ана-
лиза поведения системы и выявления подозрительных изменений в про-
граммах, а также информацию о сигнатурах известных вирусов. Обнаружив
подозрительные действия, программа мониторинга отправляет копию по-
дозрительной на предмет заражения программы в систему администратора
сети организации.
2. Машина-администратор шифрует полученный образец и отправляет его
центральной машине-анализатору, выполняющей анализ вирусов.
3. Машина-анализатор создает виртуальную среду, в которой можно выпол-
нить безопасный запуск инфицированной программы для анализа. Для это-
го может применяться технология программной эмуляции или создание ка-
кой-то иной защищенной среды, в которой подозреваемая программа может
быть выполнена и изучена. Обнаружив вирус, машина-анализатор генериру-
ет рекомендации, касающиеся вопросов идентификации и удаления вируса.
4. Созданные рекомендации передаются обратно машине-администратору.
5. Машина-администратор пересылает рекомендации инфицированной маши-
не-клиенту.
6. Рекомендации рассылаются также всем другим машинам-клиентам ор-
ганизации.
7. Все другие подписчики системы также получают регулярные обновления
антивирусных пакетов, что позволяет защититься от новых вирусов.
Успех цифровой иммунной системы зависит от способности машины-
анализатора выявлять новые вирусы и их модифицированные штаммы. С помощью
380
Часть III. Защита систем
постоянного анализа и мониторинга всех появляющихся вирусов можно обеспечить
постоянное обновление программного обеспечения цифровой иммунной системы с
целью организации надежной защиты от угрозы вирусной инфекции.
9.3. РЕКОМЕНДУЕМЫЕ ИСТОЧНИКИ
ДОПОЛНИТЕЛЬНОЙ ИНФОРМАЦИИ
Самым популярным источником информации о получивших широкую огла-
ску инцидентах, связанных с вторжением в компьютерные системы, является
[STOL89]. В [STER92] содержатся полезные исторические сведения о развитии
компьютерных правонарушений, а также описывается методика и цели основ-
ных действующих лиц: нарушителей, органов правопорядка и правозащитников.
В [DENN90] включены репринты многих основополагающих статей, речь в кото-
рых идет о нарушителях систем защиты.
В [HOFF90] и [DENN90] содержатся репринты многих важных статей, по-
священных вирусам и “червям”. Прекрасное техническое изложение технологий
создания вирусов и антивирусной защиты представлено в [СОНЕ94]. Интересны-
ми обзорными статьями о вирусах являются [FORR97], [КЕРН97] и [NACH97].
' СОНЕ94 Cohen, F. A Short Course on Computer Viruses. New York: Wiley, 1994.
DENN90 Denning, P., editor. Computers Under Attack: Intruders, Worms, and Vi-
ruses. Reading, MA: Addison-Wesley, 1990.
FORR97 Forrest, S.; Hofmeyr, S.; and Somayaji, A. “Computer Immunology.” Com-
munications of the ACM. October 1997.
; HOFF90 Hoffman, L., editor Rogue Programs: Viruses, Worms and Trojan Horses.
New York: Van Nostrand Reinhold, 1990.
; KEPH97 Kephart, J.; Sorkin G.; Chess, D.; and White, S. “Fighting Computer Vi-
ruses.” Scientific American. November 1997.
NACH97 Nachenberg, C., “Computer Virus-Antivirus Coevolution.” Communications
of the. ACM, May 1997.
STER92 Sterling, B. The Hacker Crackdown: Law and Disorder on the Electronic
Frontier. New York: Bantam, 1992.
STOL89 Stoll, G. The Cuckoo’s Egg. New York: Doubleday, 1989.
Jv Рекомендуемые Web-узлы
• Координационный центр CERT. Организация, которая создана на
основе группы быстрого реагирования на компьютерные угрозы
I Научно-исследовательским агентством по передовым оборонным
проектам (Defense Advanced Research Projects Agency — DARPA ).
Данный узел является хорошим источником информации об угро-
зах безопасности Internet, уязвимых местах защиты, а также о ре-
альной статистике атак нарушителей.
• AntiVirus Online. Один из лучших узлов компании IBM с ин-
формацией о вирусах.
Глава 9. Нарушители и вирусы
381
9.4. ЗАДАЧИ
9.1. Предположим, что для пароля выбирается четырехсимвольная комбинация из
26-буквенного алфавита. Допустим также, что противник имеет возможность
проверять пароли по одному за секунду.
а. Если противник не может узнать, насколько успешна его очередная попытка,
пока очередная проверка не завершится, то сколько времени понадобится на
то, чтобы найти правильный пароль?
б. Если противник имеет возможность сразу же узнать, что очередной введен-
ный символ не подходит, то сколько потребуется времени, чтобы найти пра-
вильный пароль в таком случае?
9.2. Предположим, что входные элементы длины к отображаются каким-либо рав-
номерным образом в элементы меньшей длины р. Если каждая цифра элемента
может принимать одно из г значений, то число исходных элементов равно гк , а
число получаемых элементов — меньшему числу гр. Каждый отдельный эле-
мент Xj отображается в элемент у,.
а. Какова вероятность того, что входной элемент будет угадан противником?
б. Какова вероятность того, что противником будет найден другой входной эле-
мент хк (хк * х,), соответствующий тому же выходному элементу у,- ?
в. Какова вероятность того, что правильный выходной элемент будет угадан
противником?
9.3. Генератор удобных для произношения паролей создает шестисимвольные пароли,
складывая вместе два генерируемых случайным образом сегмента. Каждый сегмент
имеет вид CVC (согласная, гласная, согласная), где V = < а, е, i, о, и > и С = V .
а. Сколько всего паролей может быть сгенерировано?
б. Какова вероятность случайного угадывания пароля противником?
9.4. Допустим, что в пароле можно использовать только 95 алфавитно-цифровых
символов ASCII и что все пароли имеют длину 10 символов. Предположим так-
же, что программа подбора паролей может выполнять 6,4 млн операций шифро-
вания в секунду. Сколько времени потребуется для перебора всех возможных
паролей в системе UNIX?
9.5. Основываясь на знании слабых мест системы паролей UNIX, в документации
SunOS-4.0 рекомендуется удалить файл паролей и заменить его общедоступным
файлом /etc/publickey. Каждая запись в этом файле для пользователя А
должна содержать идентификатор пользователя П)А , открытый ключ этого
пользователя KUa и соответствующий личный ключ KRa . Личный ключ шиф-
руется с помощью алгоритма DES и ключа, получаемого из пароля Ра, вводимо-
го пользователем при входе в систему. Когда пользователь А регистрируется в
системе, система дешифрует Epa[KRa], чтобы получить KRa .
а. Затем система проверяет, что введен правильный пароль Ра. Как это делается?
б. Каким образом можно атаковать такую систему?
9.6. В UNIX применяется однонаправленная схема шифрования паролей — по зашифро-
ванному паролю исходный пароль восстановить нельзя. Однако будет ли строгим
утверждение, что на самом деле выполняется хэширование, а не шифрование?
382
Часть III. Защита систем
9.7. Как упоминалось выше в тексте этой главы, использование модификатора в
схеме парольной защиты UNIX повышает сложность задачи отгадывания паро-
ля в 4096 раз. Но значение самого модификатора при этом хранится в открытом
виде в той же записи, которая включает шифрованный пароль. Поэтому авто-
матически добавляемые к паролю два символа оказываются известными про-
тивнику, и их не нужно угадывать. Чем же тогда объяснить утверждение, что
использование модификатора усиливает защиту?
9.8. Если вы смогли решить предыдущую задачу и разобраться с назначением мо-
дификатора, попробуйте ответить на следующий вопрос. Почему бы не сделать
бессмысленными любые попытки взлома пароля вообще, увеличив длину моди-
фикатора до значения, скажем, 24 или 48 бит?
9.9. Рассмотрим фильтр Блума, речь о котором шла в разделе 9.1. Пусть к обознача-
ет число используемых функций хэширования, N — число битов в таблице хэ-
ширования, a D — число слов в словаре.
а. Докажите, что ожидаемое число нулевых битов в таблице хэширования опре-
деляется выражением
б. Докажите, что вероятность того, что отсутствующее в словаре слово будет
воспринято как слово из словаря, равна
Р = (1-0)*.
в. Докажите, что значение Р, вычисляемое с помощью предыдущего выраже-
ния, можно аппроксимировать с помощью формулы
Р = (l-e-kDIN)k.
9.10. В алгоритме вируса, приведенном на рис. 9.8, имеется дефект. В чем он заклю-
чается?
Глава 9. Нарушители и вирусы
This page intentionally left blank
ГЛАВА
10
Брандмауэры
10.1. Принципы работы брандмауэров
10.2. Высоконадежные системы
10.3. Рекомендуемые источники дополнительной
информации
10.4. Задачи
Брандмауэры могут быть эффективным средством защиты локальной системы
или компьютерной сети от угроз, имеющих сетевую природу, в то же время не
ограничивающим связь с внешним миром через глобальные сети и Internet.
Мы начнем эту главу с обзора функциональных возможностей брандмауэров
и принципов, на основе которых выполняется их проектирование. Затем мы рас-
смотрим вопросы защиты самих брандмауэров и, в частности, обсудим концеп-
цию высоконадежной системы (т.е. системы, заслуживающей доверия с точки
зрения обеспечения защиты данных) или, другими словами, защищенной опера-
ционной системы.
10.1. ПРИНЦИПЫ РАБОТЫ БРАНДМАУЭРОВ
Информационные системы корпораций, правительственных учреждений и
других организаций постоянно развиваются в следующих направлениях.
• Система централизованной обработки данных, работающая на базе мэйн-
фрейма, к которому непосредственно подключено некоторое число терминалов.
• Локальная сеть, объединяющая персональные компьютеры и терминалы
друг с другом и мэйнфреймом.
• Объединенная сеть, состоящая из нескольких локальных сетей, связанных
друг с другом персональных компьютеров, серверов и, возможно, одного
или двух мэйнфреймов.
• Сеть масштаба предприятия, состоящая из нескольких находящихся на дос-
таточно большом расстоянии друг от друга объединенных сетей, связывае-
мых между собой с помощью ведомственной глобальной сети.
• Связь через Internet, при которой различные объединенные сети оказыва-
ются подключенными к Internet и могут быть также связанными друг с
другом ведомственной глобальной сетью.
Сегодня связь с Internet для большинства организаций уже является при-
вычным делом. Для многих организаций информация и услуги Internet жизнен-
но необходимы. Кроме того, доступ к Internet требуется многим индивидуаль-
ным пользователям, и если их локальная сеть не обеспечивает такого доступа,
они самостоятельно используют средства удаленного доступа для подключения
своих персональных компьютеров к Internet через поставщика услуг Internet
(провайдера). Но, хотя доступ к Internet и дает организации очевидные преиму-
щества, он в то же время открывает ресурсы внутренней сети организации
внешнему миру. Ясно, что это несет в себе определенную угрозу для организа-
ции. Для защиты от этой угрозы можно оборудовать каждую рабочую станцию и
каждый сервер внутренней сети надежными средствами защиты типа системы
защиты от вторжений, но такой подход, очевидно, непрактичен. Рассмотрим,
например, сеть с сотнями или даже тысячами отдельных систем, на которых ра-
ботают самые разные версии UNIX, да еще и Windows 95, Windows 98 и Win-
dows NT. Если будет выявлен какой-либо изъян в системе защиты, придется
внести изменения в средства защиты всех систем, которые потенциально могут
оказаться уязвимыми. Альтернативой, которая становится все более популяр-
ной, является использование брандмауэра. Это устройство размещается между
386
Часть III. Защита систем
внутренней сетью организации и Internet, обеспечивая контролируемую связь и
воздвигая внешнюю стену, или границу. Целью создания такой границы являет-
ся защита внутренней сети от несанкционированного проникновения извне через
Internet и организация единого центра, в котором должны применяться средства
защиты и контроля. Брандмауэр может представлять собой как отдельный ком-
пьютер сети, так и группу специально выделенных компьютеров, которые осу-
ществляют функции брандмауэра сети, взаимодействуя между собой.
В этом разделе мы сначала обсудим общие характеристики брандмауэров, а
затем рассмотрим брандмауэры самых распространенных типов. В конце раздела
приводятся некоторые типичные конфигурации брандмауэров.
Характеристики брандмауэров
В [BELL94] приводится следующий список основных задач, стоящих перед
разработчиками брандмауэров.
1. Весь поток данных, направляемых из внутренней сети во внешний мир, как
и идущих в обратном направлении, должен проходить через брандмауэр.
Для этого физически блокируется любой доступ к локальной сети в обход
брандмауэра. Как будет показано ниже, эта задача имеет несколько различ-
ных конструктивных решений.
2. Из всего потока поступающих к брандмауэру данных пройти его могут
только данные, прошедшие аутентификацию в соответствии с локальной
политикой защиты. Как будет показано ниже, в брандмауэрах реализуются
различные типы политик защиты.
3. Брандмауэр сам по себе должен быть недоступен для вторжения извне. Это
предполагает наличие высоконадежной системы с защищенной операцион-
ной системой. Данная тема обсуждается в разделе 10.2.
В [SMIT97] перечислены четыре основных средства, с помощью которых
брандмауэры осуществляют контроль доступа и обеспечивают реализацию поли-
тик защиты соответствующей вычислительной системы. Изначально брандмау-
эры осуществляли в основном управление сервисами, но сегодня на них возло-
жены и остальные задачи.
• Управление сервисами. Определение типов служб Internet, к которым можно
получить доступ из внутренней сети наружу и из внешнего окружения во-
внутрь. Брандмауэр может фильтровать поток данных на основе IP-адресов и
номеров портов TCP. Он предлагает такой компонент, как прокси-сервер, через
который может проходить каждый запрос сервиса и который принимает реше-
ние о том, пропустить данный запрос или нет. Брандмауэр может содержать и
сами серверные компоненты, например, Web-сервер или почтовую службу.
• Управление направлением движения. Определение направления, в котором
могут инициироваться и проходить через брандмауэр запросы к тем или
иным службам.
• Управление пользователями. Предоставление доступа к службам в зависи-
мости от прав доступа пользователей, обращающихся к этим службам. Эта
функция обычно применяется к пользователям внутри сети, защищаемой с
помощью брандмауэра (локальным пользователям). Однако она может при-
Глава 10. Брандмауэры
387
меняться и к потоку данных, поступающему от внешних пользователей, но
это требует реализации в какой-то форме технологии аутентификации, на-
пример, обеспечиваемой протоколом IPSec (см. главу 6).
• Управление поведением. Контроль за использованием отдельных служб.
Так, брандмауэр может фильтровать электронную почту, отсеивая “спэм”,
или же разрешать доступ извне только к определенной части информации,
находящейся на локальном Web-сервере.
Перед рассмотрением особенностей конфигурации брандмауэров различных
типов определим требования, выдвигаемые к ним. Брандмауэр может предлагать
следующие возможности.
1. Брандмауэр определяет единственную точку входа, в которой пресекается
несанкционированный доступ внешних пользователей к защищаемой сети,
запрещается потенциально уязвимым службам вход в сеть извне или вы-
ход изнутри во внешний мир, а также обеспечивается защита от различ-
ных атак вторжения, использующих изменение маршрута или указание
ложных IP-адресов. Наличие единственной точки входа упрощает задачу
контроля безопасности, так как все средства защиты оказываются сосре-
доточенными в одном месте.
2. Брандмауэр — это место, где осуществляется мониторинг событий, имею-
щих отношение к защите сети. Для этого в брандмауэре могут быть преду-
смотрены соответствующие компоненты контроля и извещения.
3. Брандмауэр является удобной платформой для ряда функций Internet, не
имеющих непосредственного отношения к безопасности. К таким функциям
можно отнести трансляцию локальных сетевых адресов в адреса Internet, а
также средства управления сетью, контролирующие использование Internet
и ведение соответствующего журнала.
4. Брандмауэр может служить платформой для IPSec. Возможности туннель-
ного режима такого брандмауэра (описанные в главе 6) можно использовать
при построении виртуальных частных сетей.
Брандмауэры имеют свои ограничения, описанные ниже.
1. Брандмауэр не защищает от атак, идущих в обход. Внутренние компьютер-
ные системы могут иметь средства удаленного доступа к внешнему постав-
щику услуг Internet. Внутренняя локальная сеть может иметь модемную
стойку, обеспечивающую удаленный доступ к сети сотрудникам, находя-
щимся в командировке или работающим дома.
2. Брандмауэр не может защитить от внутренних угроз безопасности, напри-
мер, со стороны неудовлетворенного служащего или сотрудника, вступив-
шего в сговор с внешним нарушителем.
3. Брандмауэр не может защитить от угрозы передачи инфицированных виру-
сами программ или файлов. В связи с тем что в рамках защищаемых
брандмауэром границ может использоваться множество различных опера-
ционных систем и приложений, для брандмауэра оказывается практически
невозможным проверять все входящие файлы, электронную почту и полу-
чаемые сообщения на предмет наличия вирусов.
388
Часть III. Защита систем
Типы брандмауэров
На рис. 10.1, созданном на основе иллюстраций из [SEME96], показано три
типа брандмауэров: фильтр пакетов, шлюз прикладного уровня и шлюз уровня
коммутации. Мы рассмотрим каждый из этих типов по очереди.
а) фильтрующий маршрутизатор
Внешний узел
Внешнее
соединение
Шлюз прикладного
уровня
б) шлюз прикладного уровня
Шлюз уровня
коммутации
в) шлюз уровня коммутации
Рис. 10.1. Типы брандмауэров
Внутреннее
соединение
Глава 10. Брандмауэры
389
Фильтрующий маршрутизатор
Фильтрующий маршрутизатор (packet-filtering router) на основе определен-
ного набора правил принимает решение о том, передавать по сети поступивший
пакет IP дальше или отвергнуть его. Обычно маршрутизатор настраивается та-
ким образом, чтобы фильтровать пакеты, проходящие в обоих направлениях
(как извне во внутреннюю сеть, так и из внутренней сети во внешний мир). Пра-
вила фильтрования основываются на значениях полей в заголовках IP и транс-
портного уровня (TCP или UDP), включая IP-адреса источника и адресата, поле
IP-протокола (задающее транспортный протокол), а также номер порта TCP или
UDP (определяющий приложение, например SNMP или TELNET).
Фильтр пакетов обычно представляется в виде списка правил, использую-
щих значения полей заголовков IP и TCP. Если обнаруживается соответствие
одному из правил, на основании этого правила принимается решение о том,
можно ли передать пакет дальше или его следует отвергнуть. При несоответст-
вии всем правилам выполняется операция, предусмотренная для использования
по умолчанию. Существуют следующие возможности.
• Default = discard. Все, что не разрешено, запрещено.
• Default = forward. Все, что не запрещено, разрешено.
Очевидно, что первая политика соответствует более консервативному подхо-
ду. Изначально все оказывается запрещенным, и добавление сервисов должно
осуществляться для каждого из них в отдельности. В рамках этой политики по
отношению к пользователям брандмауэр выступает как препятствие. Вторая по-
литика в значительной степени облегчает работу конечных пользователей, но
обеспечивает более низкий уровень защиты, поскольку в данном случае админи-
стратору системы защиты приходится принимать меры по каждой новой обна-
руженной угрозе безопасности.
В табл. 10.1, взятой из [BELL94], представлены примеры наборов правил
для брандмауэра, использующего фильтрацию пакетов. В каждом наборе прави-
ла применяются “сверху вниз”. Символ в поле обозначает соответствие лю-
бому значению. Предполагается, что применяется политика default = discard.
А. Разрешено поступление входящей почты (порт 25 предназначен для входя-
щих сообщений SMTP), но только на компьютер, выполняющий роль шлю-
за (OUR-GW). Однако поступление почты с внешнего узла SPIGOT блокиру-
ется, поскольку этот узел печально известен рассылкой сообщений элек-
тронной почты, содержащих очень большие по объему файлы.
В. Явное использование политики по умолчанию. Все наборы правил неявно
включают это правило в качестве последнего правила.
С. Любому узлу внутренней сети позволено отправлять сообщения во внешний
мир. Пакеты TCP с номером порта адресата 25 направляются SMTP-серверу
системы получателя. Проблема применения этого правила заключается в
том, что использование порта 25 для SMTP является только значением по
умолчанию. Внешняя машина может быть сконфигурирована так, что порт
25 будет связан с другим приложением. При использовании этого правила
нарушитель может получить доступ к внутренним компьютерам сети, от-
правляя пакеты с номером TCP-порта источника, равным 25.
390
Часть III. Защита систем
Таблица 10.1. Примеры правил фильтрации пакетов
action ourhost port theirhost port comment
block * * SPIGOT * Мы им не доверяем
allow OUR-GW 25 * * Подключение к нашему SMTP-порту
action ourhost port theirhost port comment
block * * * * По умолчанию
action ourhost port theirhost port comment
allow * * * 25 Подключение к их SMTP-порту
action src port dest port flags comment
allow {наши узлы} * * 25 Наши пакеты для их SMTP-портов
allow * 25 * * ACK Их ответы
action src port dest port flags comment
allow {наши узлы} * * * Наши исходящие вы- зовы
allow * * * * ACK Ответы на наши вы- зовы
allow * * * >1024 Поток к узлам, не яв- ляющимся серверами
D. Этот набор правил решает проблему, возникающую с набором правил С. В
нем используется следующая возможность TCP-соединений. После создания
соединения флаг АСК сегмента TCP используется для сегментов подтвер-
ждения, отправляемых второй стороной. Таким образом, данный набор
правил разрешает пропускать IP-пакеты с IP-адресами источника из ука-
занного списка адресов внутренних узлов сети и с номером TCP-порта на-
значения, равным 25. Кроме того, пропускаются входящие пакеты с номе-
ром порта источника 25, содержащие флаг АСК в сегменте TCP. Обратите
внимание на то, что здесь явно указаны системы отправителя и получате-
ля, чтобы явно определить правила.
Е. Данный набор правил представляет один из подходов к обработке FTP-
соединений. FTP предполагает использование двух TCP-соединений: управ-
ляющего соединения для настройки канала передачи файлов и соединения
для передачи данных, по которому происходит пересылка файлов. Соедине-
ние для передачи данных использует свой номер порта, который назначает-
ся динамически. Большинство серверов, а значит, и большинство наруши-
телей ориентированы на порты с малыми номерами. Исходящие же вызовы
Глава 10. Брандмауэры
391
обычно используют порты с номерами, превышающими 1023. Поэтому дан-
ный набор правил разрешает следующие пакеты.
• Пакеты, отправляемые из внутренней сети.
• Пакеты ответов на соединения, установленные компьютерами внут-
ренней сети.
• Пакеты, предназначенные для компьютеров внутренней сети и адресо-
ванные портам с достаточно большими номерами.
Эта схема требует настройки систем, при которой задействуются только
порты с подходящими номерами.
С помощью набора правил Е выявляется проблема работы с приложениями
на уровне фильтрации пакетов. Организовать работу с FTP и другими подобны-
ми приложениями позволяет описываемый ниже шлюз прикладного уровня.
Одним из достоинств фильтрующего маршрутизатора является его простота.
Кроме того, фильтры пакетов, как правило, остаются незаметными для пользовате-
лей и обеспечивают высокую скорость работы. Основными недостатками являются
сложность верного выбора правил фильтрации и отсутствие средств аутентификации.
В [SEME96] приводится следующий список возможных атак нарушения за-
щиты фильтрующего маршрутизатора с указанием соответствующих контрмер.
• Фальсификация IP-адресов. Нарушитель передает извне пакеты, в которых
поле отправителя содержит IP-адрес внутреннего узла сети. Нарушитель
надеется, что использование такого адреса даст возможность проникнуть в
системы, в которых реализуется простая защита адресов источника, про-
пускающая пакеты с адресами внутренних узлов, считающихся надежными.
Контрмерой является отторжение поступающих извне пакетов, в которых в
качестве адреса источника указываются внутренние адреса.
• Использование маршрутизации от источника. Отправитель указывает мар-
шрут, по которому пакет должен пересылаться по Internet, в надежде на то,
что удастся обойти средства защиты, не проверяющие информацию о мар-
шруте, заданном отправителем. Контрмера — запрет прохождения всех па-
кетов, использующих данную возможность.
• Разделение на мелкие фрагменты. Нарушитель использует фрагментации
IP-пакетов для создания фрагментов исключительно малой длины, чтобы
информация заголовка TCP попала в отдельный фрагмент. Задача такой
атаки —обойти правила фильтрации пакетов, использующие информацию
заголовка TCP. Нарушитель надеется, что фильтрующим маршрутизатором
будет просмотрен только первый пакет, а остальные фрагменты будут про-
пущены. Контрмера — отторжение всех пакетов, в которых указан прото-
кол TCP, а значение параметра Fragment Offset протокола IP равно 1.
Шлюз прикладного уровня
Шлюз прикладного уровня, который также часто называют прокси-
сервером (proxy server), работает как ретранслятор данных прикладного уровня
(см. рис. 10.1, б). Пользователь связывается с этим шлюзом с помощью такого
построенного на основе TCP/IP приложения, как Telnet или FTP. Шлюз запра-
шивает у пользователя имя удаленного узла, к которому необходимо получить
392
Часть III. Защита систем
доступ. Если пользователь отвечает на этот запрос, сообщая правильный иден-
тификатор пользователя и информацию, необходимую для аутентификации, то
шлюз связывается с соответствующим приложением удаленного узла и ретранс-
лирует сегменты TCP, содержащие данные приложения. Если в шлюзе не реали-
зована поддержка прокси-кода для того или иного приложения, соответствую-
щий сервис не предоставляется, и данные соответствующего типа через бранд-
мауэр пройти не могут. Более того, шлюз можно настроить так, чтобы он
поддерживал только определенные возможности приложения, которые админи-
стратор сети считает приемлемыми с точки зрения безопасности.
В общем случае шлюзы прикладного уровня обеспечивают более надежную
защиту, чем фильтры пакетов. Вместо того чтобы проверять многочисленные
возможные комбинации разрешений и запретов на уровне TCP и IP, шлюзу при-
кладного уровня приходится рассматривать лишь ограниченное число приложе-
ний. Кроме того, при этом легко протоколировать и контролировать весь входя-
щий поток данных прикладного уровня.
Основным недостатком шлюзов данного типа является дополнительная на-
грузка на процессор, создаваемая каждым соединением. В действительности ме-
жду двумя конечными пользователями устанавливается два связанных соедине-
ния, общей точкой которых является шлюз, и шлюзу приходится проверять весь
поток данных в обоих направлениях, чтобы переправить его дальше.
Шлюз уровня коммутации
Третьим типом брандмауэров являются шлюзы уровня коммутации
(рис. 10.1, в). Данный шлюз может быть реализован как в виде отдельной ком-
пьютерной системы, так и в виде дополнительной функции шлюза прикладного
уровня, предлагаемой для некоторых приложений. Шлюзы уровня коммутации
не разрешают внешним узлам устанавливать сквозные TCP-соединения с узлами
внутренней сети, а вместо этого устанавливают два TCP-соединения: одно между
самим шлюзом и внутренним узлом, а второе — между шлюзом и внешним уз-
лом. Если оба соединения установлены, шлюз обычно ретранслирует сегменты
TCP от одного соединения к другому, не проверяя их содержимого. Защита осу-
ществляется путем разрешения или запрета тех или иных соединений.
Чаще всего шлюзы уровня коммутации используются тогда, когда систем-
ный администратор доверяет внутренним пользователям. Шлюз можно настро-
ить так, чтобы он поддерживал работу на уровне приложений или выполнял
функции прокси-сервера для входящих соединений и функции шлюза уровня
коммутации — для исходящих. В такой конфигурации шлюз испытывает высо-
кую нагрузку, связанную с необходимостью проверки входящих данных прило-
жений на предмет выполнения ими запрещенных функций, однако для исходя-
щих данных такой нагрузки нет.
Примером реализации шлюза уровня коммутации является пакет SOCKS
[KOBL92]. Версия 5 этого пакета описана в документе RFC 1928. В этом доку-
менте RFC пакет SOCKS определяется следующим образом.
“Протокол, описанный в данном документе, призван обеспечить каркас для прило-
жений клиент/сервер в доменах TCP и UDP, обеспечивающий удобное и безопасное
использование сервисов брандмауэра сети. Протокол концептуально является
“прослойкой” между прикладным и транспортным уровнем, поэтому он не обеспе-
чивает сервис шлюза сетевого уровня, например пересылку сообщений ICMP”.
Глава 10. Брандмауэры
393
В пакет SOCKS включены следующие компоненты.
• Сервер SOCKS, работающий в составе брандмауэра на базе UNIX.
• Библиотека клиента SOCKS, работающая на внутренних узлах, защищен-
ных брандмауэром.
• Адаптированные для использования с SOCKS стандартные приложения
клиента типа FTP и TELNET. Реализация протокола SOCKS обычно требует
перекомпиляции или перекомпоновки использующих TCP приложений
клиента, чтобы последние получили возможность обращения к соответст-
вующим процедурам библиотеки SOCKS.
Если использующему протокол TCP клиенту необходимо установить соеди-
нение с объектом, к которому можно получить доступ только через брандмауэр,
клиент должен открыть TCP-соединение с соответствующим SOCKS-портом сис-
темы, в которой установлен SOCKS-сервер. По умолчанию сервис SOCKS исполь-
зует порт TCP с номером 1080. Если на запрос об установке соединения получен
положительный ответ, клиент начинает процесс согласования для выбора метода
аутентификации, проходит аутентификацию в соответствии с выбранным мето-
дом, а затем посылает запрос на ретрансляцию. SOCKS-сервер проверяет посту-
пивший запрос и либо устанавливает соответствующее соединение, либо посыла-
ет отказ. При использовании протокола UDP выполняются аналогичные дейст-
вия. По существу, для аутентификации пользователя, который намеревается
отправлять и получать сегменты UDP, открывается специальное соединение
TCP. Сегменты UDP при этом могут пересылаться до тех пор, пока указанное со-
единение TCP остается открытым.
Бастионный узел
Бастионный узел представляет собой систему, выбранную администратором
брандмауэра в качестве критически важной точки в схеме защиты сети. Как прави-
ло, бастионный узел служит платформой для шлюза прикладного уровня или шлюза
уровня коммутации. Бастионный узел имеет следующие характеристики.
• На базе аппаратных средств бастионного узла выполняется защищенная
версия операционной системы, в результате чего бастионный узел оказыва-
ется высоконадежной системой.
• На бастионном узле устанавливаются только те службы, которые сочтет не-
обходимыми сетевой администратор. К таким службам относятся прокси-
приложения типа Telnet, DNS, FTP, SMTP и средства аутентификации
пользователей.
• Бастионный узел может требовать дополнительной аутентификации, прежде
чем предоставить пользователю доступ к прокси-приложениям. Кроме того,
каждое прокси-приложение может запросить дополнительную аутентифи-
кацию перед тем, как предоставить доступ пользователю.
• Каждое прокси-приложение поддерживает только определенный набор
стандартных команд из общего множества команд приложения.
• Каждое прокси-приложение предоставляет доступ только к определенным
узлам. Это значит, что вышеупомянутый ограниченный набор команд и
394
Часть ТТТ Яяттттт-ра
возможностей можно применить только к определенной части систем за-
щищаемой сети.
• Каждое прокси-приложение обеспечивает широкие возможности для кон-
троля, регистрируя весь поток данных, каждое соединение и длительность
его использования. Контрольный журнал является исключительно важным
средством выявления попыток вторжения.
• Каждый прокси-модуль представляет собой небольшой программный пакет,
специально созданный для защиты сети. Относительная простота модулей
позволяет легко проверить их программный код на предмет отсутствия воз-
можных изъянов с точки зрения защиты. Например, исходный текст ти-
пичного приложения электронной почты в UNIX может содержать свыше
20000 строк, тогда как длина исходного текста прокси-модуля электронной
почты может оказаться менее 1000 строк [SEME96].
• Все прокси-приложения бастионного узла являются независимыми. Если воз-
никает проблема с работой какого-либо прокси-приложения или в нем выявля-
ется изъян защиты, такое приложение может быть удалено без каких-либо по-
следствий для других прокси-приложений. Кроме того, если пользователям по-
требуется доступ к новой службе, администратор сети может просто установить
дополнительный прокси-модуль на бастионный узел.
• Прокси-приложения обычно не используют доступ к диску, кроме чтения
своего файла исходной конфигурации. Это делает задачу внедрения
“троянского коня” и других опасных файлов на бастионном узле очень
трудной для нарушителя.
• Каждое прокси-приложение выполняется в режиме непривилегированного
пользователя в личном защищенном каталоге бастионного узла.
Конфигурации брандмауэров
Помимо конфигурации, при которой брандмауэр представлен отдельной
системой типа фильтрующего маршрутизатора или шлюза (см. рис. 10.1), воз-
можны более сложные конфигурации. И именно такие конфигурации использу-
ются чаще всего. На рис. 10.2, в основу которого положены соответствующие
иллюстрации из [SEME96], показаны три самые распространенные конфигура-
ции брандмауэров. Рассмотрим эти конфигурации по очереди.
В конфигурации брандмауэра с экранированным одноточечным бастион-
ным узлом, показанной на рис. 10.2, а, брандмауэр состоит из двух систем:
фильтрующего маршрутизатора и бастионного узла. Как правило, маршрутиза-
тор при этом настраивается следующим образом.
1. Из потока данных, поступающего из Internet, пропускаются только IP-
пакеты, предназначенные для бастионного узла.
2. Из потока данных, поступающего из внутренней сети, пропускаются только
пакеты, исходящие из бастионного узла.
Бастионный узел выполняет задачи аутентификации и функции прокси-
сервера. Эта конфигурация обеспечивает гораздо более высокий уровень защиты,
чем обычный фильтрующий маршрутизатор или шлюз прикладного уровня по
Глава 10. Брандмауэры
395
следующим причинам. Во-первых, в данной конфигурации реализована фильтра-
ция как на пакетном, так и на прикладном уровне, что обеспечивает достаточную
гибкость в выборе политики защиты. Во-вторых, нарушителю для вторжения во
внутреннюю сеть приходится преодолевать защиту двух отдельных систем.
маршрутизатор
а) брандмауэр с экранированным одноточечным бастионным узлом
маршрутизатор
б) брандмауэр с экранированным двухточечным бастионным узлом
в) брандмауэр с экранированной подсетью
Рис. 10.2. Конфигурации брандмауэров
Данная конфигурация оказывается достаточно гибкой для прямого доступа
к Internet. Например, внутренняя сеть может содержать общедоступный инфор-
мационный сервер типа Web-сервера, для которого не требуется высокий уро-
396
Часть III. Защита систем
вень защиты. В таком случае маршрутизатор можно настроить так, чтобы он по-
зволял прямой доступ к данному серверу из Internet.
Если фильтрующий маршрутизатор в только что описанной конфигурации с
одноточечным бастионным узлом будет скомпрометирован (т.е. его защита будет
взломана), поток данных из Internet может пойти прямо через маршрутизатор в
узлы внутренней частной сети. Брандмауэр с экранированным двухточечным
бастионным узлом сконфигурирован так, чтобы физически исключить возмож-
ность появления такой бреши в системе защиты (рис. 10.2, б). Все преимущества
двухуровневой защиты, которыми обладает описанная выше конфигурация, ос-
таются при этом в силе. Опять же, информационный сервер и некоторые другие
узлы могут быть подключены к маршрутизатору напрямую, если это согласуется
с принятой политикой защиты.
Конфигурация брандмауэра с экранированной подсетью (рис. 10.2, в) из
всех рассматриваемых здесь вариантов обеспечивает самую надежную защиту. В
этой конфигурации установлено два фильтрующих маршрутизатора: один между
бастионным узлом и Internet, а второй — между бастионным узлом и внутрен-
ней сетью. Данная конфигурация создает изолированную подсеть, которая мо-
жет состоять только из бастионного узла, но может также иметь и один или не-
сколько информационных серверов, а также модемы, с помощью которых осу-
ществляется удаленный доступ к сети. Обычно к узлам, входящим в состав
экранированной подсети, можно получить доступ как из Internet, так и из внут-
ренней сети, однако поток данных сквозь подсеть блокируется. Данная конфигу-
рация обладает следующими преимуществами.
• Предусмотрено три уровня защиты от вторжения нарушителей.
• Внешний маршрутизатор объявляет в Internet только о существовании экрани-
рованной подсети, поэтому внутренняя сеть остается для Internet невидимой.
• Точно так же внутренний маршрутизатор сообщает узлам внутренней сети
только о существовании экранированной подсети, поэтому системы внутренней
сети не имеют возможности проложить прямые маршруты в Internet.
10.2. ВЫСОКОНАДЕЖНЫЕ СИСТЕМЫ
Один из способов расширить возможности системы, чтобы противостоять
вторжениям нарушителей и вредоносных программ, заключается в реализации
технологии высоконадежных систем. Следующий раздел содержит краткий об-
зор соответствующего предмета. Мы начнем с рассмотрения некоторых базовых
концепций управления доступом к данным.
Управление доступом к данным
Вслед за получением доступа к системе пользователь получает доступ к
:дному или нескольким узлам и приложениям. Как правило, такое положе-
ние дел не согласуется с требованиями безопасности для тех систем, в кото-
рых хранятся важные данные. Процедура разрешения доступа к системе по-
зволяет идентифицировать пользователя. Каждому пользователю может со-
: тветствовать файл профиля со списком всех допустимых для данного
пользователя действий и типов доступа к файлам. Операционная система
Глава 10. Брандмауэры 397
может на основе файла профиля поддерживать определенные правила рабо-
ты. При этом система управления доступом к базам данных должна контро-
лировать доступ не только к файлам баз данных, но и к отдельным записям
и даже к отдельным полям. Например, список сотрудников компании может
быть доступным для любого работника административного отдела, но только
некоторым из них должен быть разрешен доступ к информации о зарплатах.
Кроме того, здесь может быть несколько уровней детализации. Если доступ к
файлам и использование приложений может разрешить операционная систе-
ма, после чего уже не проводится никаких проверок на безопасность, то сис-
тема управления базами данных должна принимать решение о разрешении
или запрещении доступа при каждой попытке доступа к данным. Такое ре-
шение должно зависеть не только от идентификатора пользователя, но и от
того, какие данные и какие части данных запрашиваются, и даже от того,
какие данные были открыты данному пользователю раньше.
Общая модель управления доступом, реализуемая на уровне файловой сис-
темы или системы управления базами данных, представляется в виде матрицы
доступа (рис. 10.3, а). Основные элементы данной модели перечислены ниже.
• Субъект. Сущность, которая может получать доступ к объектам. В об-
щем случае понятие субъекта отождествляется с понятием процесса.
Любой пользователь или приложение получают доступ к объекту с по-
мощью процесса, представляющего этого пользователя или соответст-
вующее приложение.
• Объект. Сущность, доступ к которой контролируется. Примерами являются
файлы, их части, программы и сегменты памяти.
• Право доступа. Способ доступа субъекта к объекту. Примерами являются
чтение, запись или выполнение.
Вдоль одной оси матрицы представлены идентифицированные субъекты,
которые могут пытаться получить доступ к данным. Обычно список состоит из
отдельных пользователей или пользовательских групп, хотя можно также кон-
тролировать доступ терминалов, узлов или приложений. Вдоль другой оси ото-
бражаются объекты, к которым субъекты могут получать доступ. При самом
высоком уровне детализации объектами могут быть отдельные поля базы дан-
ных. Более общие группы (т.е. записи, файлы или же вся база данных в це-
лом) тоже могут быть объектами, представленными в матрице. Каждый эле-
мент матрицы указывает права доступа соответствующего субъекта к соответ-
ствующему объекту.
На практике матрица доступа обычно является почти пустой и поэтому ис-
пользуется в виде декомпозиции, получаемой одним из следующих двух мето-
дов. Может использоваться декомпозиция матрицы по столбцам, в результате
чего получаются списки управления доступом (рис. 10.3, б). Для каждого объек-
та в списке управления доступом приводятся пользователи и их права доступа к
данному объекту. Список может содержать элемент, используемый по умолча-
нию, или элемент открытого доступа. Использование этого элемента позволяет
рассматривать представленных в списке пользователей, как пользователей,
имеющих права доступа, определенные по умолчанию. Элементами списка могут
быть как отдельные пользователи, так и группы пользователей.
398
Часть III. Защита систем
Programi ... SegmentA Segment!!
Чтение Выполнение Чтение Запись
Чтение
а) матрица доступа
Список управления доступом для Program 1
Process! (Чтение, выполнение)
Список управления доступом для SegmentA
Process! (Чтение, дапись)
Список управления доступом для SegmentB
Pi'ocess2 (Чтение)
б) список управления доступом
Перечень возможностей для Process 1
Program 1 (Чтение, выполнение)
SegmentA (Чтение, запись)
Перечень возможностей для Process2
SegmentB (Чтение)
в) перечень возможностей
Рис. 10.3. Структуры управления доступом
В результате декомпозиции по строкам создаются мандаты возможно-
стей (рис. 10,3, в). Мандат возможностей определяет для данного пользова-
теля объекты и операции, на использование которых пользователь имеет
разрешение. Каждый пользователь получает несколько мандатов возможно-
:тей, и, кроме того, он может обладать привилегией на использование ман-
датов других пользователей и предоставлять другим пользователям право
использовать свои. Поскольку мандаты могут быть распределены по всей
:истеме, задача их защиты представляет собой гораздо более сложную зада-
чу, чем задача защиты списков управления доступом. В частности, необхо-
димо предотвратить возможность фальсификации мандатов. Защитить ман-
даты можно с помощью операционной системы, которая поместит их в об-
ласть, недоступную пользователям.
. лава 10. Брандмауэры
399
Принципы использования высоконадежных систем
Многие вопросы, которые мы обсуждали на страницах этой книги до сих
пор, были связаны с проблемой защиты отдельного сообщения или объекта от
пассивных или активных атак отдельного пользователя. Однако существует еще
одна задача с не менее широкой областью применения — защита данных или ре-
сурсов на основе уровней безопасности. Эта задача часто встречается в военном
деле, где информация обычно классифицируется как открытая (U — unclassi-
fied), для служебного пользования (С — confidential), секретная (S — secret), со-
вершенно секретная (TS — top secret) или как-то иначе. Данный подход приме-
няется и в других областях, где информацию можно разбить на большие катего-
рии, а пользователям предоставить доступ к данным той или иной категории.
Например, самый высокий уровень безопасности может требоваться для доку-
ментов и данных стратегического планирования предприятия, к которым долж-
ны иметь доступ только руководители предприятия и их помощники, далее мо-
гут идти важные финансовые и персональные данные, к которым может иметь
доступ только администрация, и т.д.
Если для данных определено несколько категорий или уровней безопасно-
сти, говорят о многоуровневой системе безопасности. Общим требованием мно-
гоуровневой системы безопасности является то, что субъект на более высоком
уровне не может сообщить информацию субъекту на более низком или несрав-
нимом уровне, если только соответствующий поток не вызван действием пользо-
вателя, имеющего право на доступ к данной информации. Данное требование за-
писывается в виде следующих двух более простых требований.
• Запрет чтения вверх. Любому субъекту разрешается выполнять операции чте-
ния только в отношении объектов с тем же или более низким уровнем безопас-
ности. Это требование иногда называют простым требованием безопасности.
• Запрет записи вниз. Субъект может выполнять операции записи только в
отношении объектов с тем же или более высоким уровнем безопасности. Это
требование иногда называют свойством *, что произносится как “свойство
звездочка”.1
Аккуратная реализациях обоих правил обеспечивает многоуровневую сис-
тему безопасности. Данный подход был апробирован в системах обработки дан-
ных, где после долгих исследований была выработана концепция монитора об-
ращений (reference monitor). Схема соответствующего подхода представлена на
рис. 10.4. Монитор обращений представляет собой контролирующий элемент,
реализованный на аппаратном уровне и уровне операционной системы компью-
тера и управляющий доступом субъектов к объектам на основе параметров безо-
пасности субъектов и объектов. Монитор обращений имеет доступ к файлу, на-
зываемому базой данных ядра безопасности, где указаны привилегии доступа
(категории допуска) субъектов и атрибуты защиты (грифы секретности) объек-
^Сам символ здесь не означает ровно ничего. Просто никто не смог придумать
подходящего названия для этого свойства. "Звездочка” оказалась замещающим симво-
лом в черновике отчета, чтобы с помощью текстового редактора можно было быстро
найти этот символ и заменить его, как только будет придумано название для данного
свойства. Но названия предложено не было, и отчет был опубликован с оставшимися в
нем "звездочками".
400
Часть III. Защита систем
тов. Монитор обращений реализует два упомянутых выше требования (запрет
чтения вверх и запрет записи вниз) и ему присущи следующие характеристики.
• Неизбежное посредничество. Правила безопасности навязываются при лю-
бой попытке получить доступ, а не только, скажем, при открытии файлов.
• Изолированность. Монитор обращений и его база данных защищены от вне-
сения несанкционированных изменений.
• Доказуемость. Корректность работы монитора обращений должна быть до-
казуемой. Это значит, что должна существовать возможность доказать ма-
тематически, что монитор обращений обеспечивает выполнение правил
безопасности, гарантируя неизбежное посредничество и изолированность.
Монитор
обращений
(политика)
Субъект: категории
допуска
Объект: грифы
секретности
Рис. 10.4. Схема работы монитора обращений
J________
Объекты
Эти требования являются жесткими. Требование неизбежного посредничества
означает, что любая операция доступа к данным в оперативной памяти, на диске
или магнитной ленте должна быть опосредованной. Чисто программная реализация
приводит к слишком большим потерям производительности и поэтому на практике
не применяется. Практическое решение находится в области хотя бы частичной ап-
паратной реализации системы. Требование изолированности означает, что у наруши-
теля, независимо от уровня его квалификации, не должно быть возможности изме-
нить логику работы монитора обращений или содержимое базы данных ядра безо-
пасности. Наконец, требование математической доказуемости в некоторых
отношениях кажется настолько сложным, насколько сложной является задача соз-
Глава 10. Брандмауэры
401
Дания универсального компьютера. Система, для которой обеспечена такая доказуе-
мость, называется высоконадежной системой.
На рис. 10.4 показан также файл аудита. В файле аудита регистрируются
события, важные с точки зрения безопасности, например, выявленные наруше-
ния защиты и авторизованные изменения в базе данных ядра безопасности.
Министерство обороны США для того, чтобы решить собственные задачи и по-
мочь в решении соответствующих задач другим организациям, учредило в 1981 г.
Центр компьютерной безопасности (Computer Security Center — CSC) в рамках На-
ционального агентства по безопасности (National Security Agency — NSA). Одной из
целей этого центра было содействие распространению и доступности высоконадеж-
ных компьютерных систем. Данная цель достигается с помощью программы оценки
коммерческих продуктов (Commercial Product Evaluation Program). В рамках этой
программы центр, по сути, пытается оценить имеющиеся на рынке коммерческие
продукты на предмет их соответствия описанным выше требованиям. Центр компь-
ютерной безопасности классифицирует продукты по диапазону предлагаемых ими
средств защиты. Эти сведения необходимы Министерству обороны, но они публику-
ются и для широкой общественности. Следовательно, этими данными могут восполь-
зоваться и потребители, приобретающие предлагаемое на рынке стандартное обору-
дование.
Защита от “троянских коней”
Одним из способов защиты от атаки “троянского коня” является использование
защищенной, высоконадежной операционной системы. Пример такой схемы защиты
показан на рис. 10.5 [ВОЕВ85]. В данном случае “троянский конь” используется для
обхода стандартного механизма защиты, применяемого большинством файловых и
операционных систем, а именно, для обхода списка управления доступом. В нашем
примере пользователь Боб обращается с помощью некоторой программы к файлу,
содержащему критически важную с точки зрения безопасности строку
“CPE1704TKS”. Этот пользователь создал файл с правом чтения и записи, предостав-
ляемым только программам, работающим от его имени (т.е. доступ к этому файлу
разрешается только процессам, владельцем которых является Боб).
Атака с использованием “троянского коня” начинается с того, что имеющий
враждебные планы пользователь Алиса получает законный доступ к системе, ус-
танавливает в ней программу “троянского коня” и личный файл, который будет
выполнять в ходе атаки роль “кармана”. Алиса устанавливает себе право чтения
и записи для этого файла, а пользователю Бобу — право только записи в файл
(рис. 10.5, а). Теперь Алиса провоцирует Боба запустить программу “троянского
коня”, например, представив ее как новую полезную утилиту. Когда программа
выясняет, что ее запустил Боб, она копирует секретную строку из файла Боба в
“карман” Алисы (рис. 10.5, б). И операция чтения, и операция записи в данном
случае полностью соответствуют ограничениям, налагаемым с помощью списка
управления доступом. Алисе остается только проверить полученный файл позже,
чтобы узнать значение секретной строки.
Теперь рассмотрим тот же сценарий, но применительно к защищенной опе-
рационной системе (рис. 10.5, в). В этом случае уровни допуска присваиваются
субъектам во время входа в систему на основе критериев, учитывающих, помимо
идентификатора пользователя и пароля, например, и терминал, с которого осу-
ществляется вход в систему. В данном примере имеется два уровня допуска —
402
Часть III. Защита систем
секретный и открытый (предполагается, что секретный уровень допуска выше
открытого). Процессам, которые инициирует Боб, и его файлам с данными при-
своен гриф секретности, а файлы и программы Алисы имеют статус открытых.
Если Боб запустит программу Алисы, содержащую “троянского коня”
(рис. 10.5, г), эта программа получит статус секретной, как процесс, иницииро-
ванный Бобом. В силу “простого требования безопасности” данная программа
сможет прочитать секретную строку. Но когда программа попытается сохранить
данную строку в открытом файле (в “кармане” Алисы), это приведет к наруше-
нию правила *, и попытка будет пресечена монитором обращений. Таким обра-
зом, попытка записи в файл-“карман” будет запрещена, даже если она разреша-
ется списком управления доступом: политика безопасности имеет более высокий
приоритет в сравнении с механизмом списков управления доступом.
Рис. 10.5. "Троянский конь" и защищенная операционная система
10.3. РЕКОМЕНДУЕМЫЕ ИСТОЧНИКИ
ДОПОЛНИТЕЛЬНОЙ ИНФОРМАЦИИ
Классической работой на тему брандмауэров, до сих пор заслуживающей
самого пристального внимания, является [CHES94]. Другой классической кни-
гой, к тому же недавно обновленной, является [СНАР00]. Хорошие обзорные
статьи на эту тему предлагаются в [LODI98], [OPPL97] и [BELL94].
Глава 10. Брандмауэры
403
Всеобъемлющее описание высоконадежных компьютерных систем вы най-
дете в [GASS88J. Неплохим источником информации является [PFLE97], Ре-
принты некоторых важных статей по этой тематике включены в [ABRA87].
! ABRA87 Abrams, М., and Podell, Н. Computer and Network Security. Los Alamitos, ;
CA: IEEE Computer Society Press, 1987.
> BELL94 Bellovin, S., and Cheswick, W. “Network Firewalls”, IEE Communications >
i Magazine, September 1994. s
i CHAP95 Chapman, D., and Zwicky, E. Building Internet Firewalls. Sebastopol, CA: >
> O’Reilly, 1995.
! CHESOO Cheswick, W. and Bellovin, S.. Firewalls and Internet. Security: Repelling the
г Wily Hacker. Reading, MA: Addison-Wesley, 2000
। GASS88 Gasser, M. Building a Secure Computer System. New York: Van Nostrand Re-
: inhold, 1988.
s LODI98 Lodin, S., and Schuba, C. “Firewalls Fend Off Invasions from the Net.” IEEE >
Spectrum, February 1998.
; OPPL97 Oppliger, R. “Internet Security: Firewalls and Beyond.” Communications of <
i the ACM, May 1997.
i PFLE97 Pfleeger, C. Security in Computing. Upper Saddle River, NJ: Prentice Hall,
1997. •
10.4. ЗАДАЧИ
10.1. Необходимость правила “запрет чтения вверх” для многоуровневой системы
безопасности достаточно очевидна. Но чем продиктована необходимость исполь-
зования правила “запрет записи вниз”?
10.2. На рис. 10.5 одно звено в цепочке выполняемого “троянским конем” копирования с
целью последующего просмотра оказывается разорванным. Но существуют два дру-
гих возможных варианта атаки: Алиса может войти в систему и попытаться либо
прочитать строку непосредственно, либо присвоить “файлу-карману” статус секрет-
ного. Сможет ли монитор обращений пресечь эти попытки?
404
Часть III. Защита систем
ПРИЛОЖЕНИЕ
Список
документов RFC,
на которые
ссылается книга
Номер документа RFC Название Дата публикации
768 User Datagram Protocol (UDP) Август 1980
791 Internet Protocol (IP) Сентябрь 1981
821 Simple Mail Transfer Protocol (SMTP) Август 1982
822 Standard for the Format of ARPA Internet Text Messages Август 1982
1155 Structure and Identification of Management Information for TCP/IP-Based Networks Май 1990
1157 Simple Network Management Protocol Май 1990
1213 Management Information Base for Network Management of TCP/IP- Based Internets: MIB-II Март 1991
1321 The MD5 Message-Digest Algorithm Апрель 1992
1510 The Kerberos Network Authentica- tion Service (V5) Сентябрь 1993
1636 Security in the Internet Architecture Июнь 1994
1752 The Recommendation for the IP Next Generation Protocol Январь 1995
Номер документа RFC Название Дата публикации
1901 Introduction to Community-Based SNMPv2 Январь 1996
1904 Conformance Statements for SNMPv2 Январь 1996
1905 Protocol Operations for SNMPv2 Январь 1996
1906 Transport Mappings for SNMPv2 Январь 1996
1907 Management Information Base for SNMPv2 Январь 1996
1908 Coexistence Between Version 1 and Version 2 of the Internet-Standard Network Management Framework Январь 1996
1928 SOCKS Protocol Version 5 Апрель 1996
2026 The Internet Standards Process — Revision 3 Октябрь 1996
2040 The RC5, RC5-CBC, RC5-CBC-Pad, and RC5-CTS Algorithms Октябрь 1996
2045 Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies Ноябрь 1996
2046 Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types Ноябрь 1996
2047 MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCH Text Ноябрь 1996
2048 Multipurpose Internet Mail Extensions (MIME) Part Four: Registration Procedures Ноябрь 1996
2049 Multipurpose Internet Mail Extensions (MIME) Part Five: Conformance Criteria and Examples Ноябрь 1996
2068 Hypertext Transfer Protocol — HTTP/1.1 Январь 1997
2104 HMAC Keyed-Hashing for Message Authentication Февраль 1997
2119 Key words for Use in RFCs to Indicate Requirement Levels Март 1997
2144 The CAST-128 Encryption Algorithm Май 1997
2246 The TLS Protocol Version 1 0 Январь 1998
2311 S/MIME Version 2 Message Specification Март 1998
2312 S/MIME Version 2 Certificate Handling Март 1998
2401 Security Architecture for the Internet Protocol Ноябрь 1998
2402 IP Authentication Header Ноябрь 1998
2406 IP Encapsulating Security Payload (ESP) Ноябрь 1998
2408 Internet Security Association and Key Management Protocol Ноябрь 1998
2411 IP Security Document Roadmap Ноябрь 1998
2460 Internet Protocol, Version 6 Specification Декабрь 1998
2570 Introduction to Version 3 of the Internet-Star.-/1 ~n Network Management Framework Апрель 1999
2571 An Architecture for Describing SNMP Management Frameworks Апрель 1999
2572 Message Processing and Dispatching for SNMP Апрель 1999
2573 SNMP Applications Апрель 1999
2574 User-Based Security Model for SNMPv3 Апрель 1999
2575 View-Based Access Control Model (A7ACM) ttr ~NVp Апрель 1999
2578 Structure of Management Information for SNMPnrn Апрель 1999
2579 Textual Conventions for SNMPv2 Апрель 1999
406
Приложение 1
ПРИЛОЖЕНИЕ шил
Проекты
для курса
W
по защите сетей
Многие преподаватели считают, что проекты по
практической реализации решений очень важны. Без та-
ких проектов студентам будет сложно разобраться в ос-
новных понятиях и взаимосвязях между компонентами
защиты. Проекты призваны укрепить понимание опреде-
ленных в книге принципов и предоставить студентам воз-
можность лучше понять, как работает тот или иной крип-
тографический алгоритм или приложение защиты. При
этом учащиеся смогут не только понять теорию, но и
практически реализовать возможности защиты.
В тексте книги я попытался представить основные
принципы защиты сетей настолько ясно, насколько
возможно, и сформулировал множество задач для само-
стоятельного решения, направленных на углубление
понимания этих принципов. Многие преподаватели за-
хотят дополнить этот материал конкретными практиче-
скими заданиями. Данное приложение предлагает опи-
сание материала, вошедшего в соответствующие реко-
мендации преподавателям. Этот материал охватывает
три типа проектов:
• исследовательские проекты,
• проекты по программированию,
• задания по изучению/реферированию дополнитель-
ной литературы.
2.1. ИССЛЕДОВАТЕЛЬСКИЕ ПРОЕКТЫ
Исследовательский проект может включать поиск соответствующих публи-
каций в литературе и программных продуктов в Internet, лабораторные исследо-
вания и разработку предложений по стандартизации. Проекты можно предло-
жить группам учащихся или отдельным студентам. В любом случае лучше всего
требовать планы проектов заранее, чтобы у преподавателя было время оценить
перспективность предлагаемой темы исследования и требующиеся для его вы-
полнения усилия. Руководство для учащихся по написанию исследовательских
проектов должно включать следующее.
• Форму заявки проекта.
• Форму отчета по проекту.
• План с указанием промежуточных и конечного сроков.
• Список предлагаемых тем для проектов.
Студенты могут выбрать одну из предлагаемых тем или разработать собст-
венный проект подходящего уровня. Руководство преподавателя включает при-
мерную форму для заявки проекта и форму для отчета по проекту, а также спи-
сок из пятнадцати возможных тем для исследований.
2.2. ПРОЕКТЫ ПО ПРОГРАММИРОВАНИЮ
Проект по программированию является не менее полезным средством обу-
чения. Независимые программные проекты, не являющиеся частью существую-
щих средств защиты, имеют ряд привлекательных свойств.
1. Преподаватель имеет широкий выбор из множества понятий, касающихся
защиты сетей, для которых могут быть предложены проекты.
2. Программирование в рамках проектов может выполняться студентами на
любом доступном компьютере и на любом подходящем языке программиро-
вания: проекты являются независимыми от платформы и языка.
3. Преподавателю для автономных проектов не приходится загружать, уста-
навливать или конфигурировать никакой специальной инфраструктуры.
По объему проекты варьируются в широком диапазоне, что обеспечивает
дополнительную гибкость. Большие проекты дают студентам шанс почувствовать
вкус к исследовательской работе, но студенты с меньшими возможностями или
менее основательной подготовкой могут при этом остаться за бортом. Более объ-
емные проекты обычно требуют больше усилий и предлагаются лучшим студен-
там. В меньших проектах доля теоретического материала выше (по отношению к
программированию), а поскольку таких проектов больше, существует возмож-
ность охватить с их помощью больше областей.
Как и при выполнении исследовательских проектов, студенты должны сначала
представить предложения. Предложение студента должно быть оформлено в соответ-
ствии с требованиями, которые упоминались в разделе 2.1. Руководство для препо-
давателей включает двенадцать примеров проектов по программированию.
408
Приложение 2
Исследовательские проекты и проекты по программированию, вошедшие в
руководство для преподавателей, предоставили Хеннинг Шюльцринне (Henning
Schulzrinne) из Университета Колумбии, Сетин Кайя Кок (Cetin Kaya Кос) из
Университета штата Орегон, а также Дэвид М. Баленсон (David М. Balenson) из
Университета Дж. Вашингтона и Trusted Information System.
2.3. ЗАДАНИЯ ПО ИЗУЧЕНИЮ/
РЕФЕРИРОВАНИЮ ЛИТЕРАТУРЫ
Другой прекрасной возможностью добиться от студентов более глубокого
понимания рассматриваемых концепций, является предложение студентам спи-
ска статей из различных источников с целью изучения и анализа. Это даст уча-
щимся опыт исследовательской работы. Руководство для преподавателей вклю-
чает примерный список статей, которые можно предложить для изучения и ре-
ферирования, и при этом учитывается соответствие материалу каждой из глав
данной книги. Все статьи легко найти либо в Internet, либо в технической биб-
лиотеке любого хорошего колледжа.
Проекты для курса по защите сетей
409
This page intentionally left blank
Словарь
терминов
Определения некоторых терминов в оригинальном
(англоязычном) издании книги взяты из Словаря тер-
минологии по компьютерной безопасности [NIST91J.
Здесь они отмечены звездочкой.
Абсолютная защищенность. Защищенность даже от про-
тивника с безграничными возможностями по вре-
мени и по вычислительным ресурсам.
Алгоритм RSA. Алгоритм шифрования с открытым
ключом, основанный на использовании возведения
в степень в арифметике классов вычетов. Является
единственным алгоритмом шифрования с открытым
ключом, получившим широкое распространение и
считающимся достаточно защищенным.
Асимметричное шифрование. Криптосистема, в которой
шифрование и дешифрование выполняются с ис-
пользованием двух разных ключей, при этом один
из ключей называется открытым ключом, а дру-
гой — личным. То же, что и шифрование с откры-
тым ключом.
Атака воспроизведения. Атака, при которой копия ус-
пешно завершенного процесса авторизации доступа
к сервису используется кем-то другим для того,
чтобы попытаться повторить команды авторизации.
Аутентификатор. Дополнительная информация, присоеди-
няемая к сообщению и дающая получателю возмож-
ность убедиться в подлинности принятого сообщения.
Аутентификатор может быть функционально незави-
симым от содержимого сообщения (как при использо-
вании оказии или идентификатора источника сообще-
ния) или быть функцией содержимого (как при ис-
пользовании значений хэширования или криптогра-
фической контрольной суммы).
Аутентификация.* Процесс, используемый для про-
верки целостности полученных данных, в частно-
сти сообщения.
Бактерия. Программа, поглощающая ресурсы системы
путем воспроизведения себе подобных.
Биграмма. Последовательность из двух букв. В английском языке и других язы-
ках относительная частота появления биграмм в открытом тексте может
служить для криптоанализа некоторых шифров.
Блочный шифр. Алгоритм симметричной схемы шифрования, в котором некото-
рый достаточно большой блок битов (как правило, 64 бит) открытого текста
преобразуется как целое в блок шифрованного текста такой же длины.
Вектор инициализации. Случайный блок данных, используемый в начале шиф-
рования открытого текста, состоящего из множества блоков, когда приме-
няется шифрование со сцеплением шифрованных блоков. Применение век-
торов инициализации позволяет помешать атакам с использованием извест-
ного открытого текста.
Вирус. Программный код, внедренный в программу и внедряющий свои копии в
другие программы. Помимо функции распространения, вирус обычно вы-
полняет еще и некоторую нежелательную для системы функцию.
Высоконадежная система. Компьютер и операционная система, для которых
можно проверить соответствие определенной политике защиты.
Генератор псевдослучайных чисел. Функция, детерминированным образом гене-
рирующая последовательность чисел, кажущуюся статистически случайной.
Главный ключ. Достаточно долго используемый ключ, который применяется цен-
тром распределения ключей и доверителем для шифрования данных при пере-
даче сеансовых ключей. Обычно главные ключи распределяются некриптогра-
фическими средствами. Также называется ключом для шифрования ключей.
Дешифрование. Перевод шифрованного текста или данных (называемых шифро-
ванным текстом) в оригинальный текст или данные (называемые открытым
текстом). То же, что и расшифровка.
Дифференциальный криптоанализ. Метод, основанный на применении шифро-
вания избранных образцов открытого текста с заданными значениями XOR-
разностей. Значения разностей получаемого при этом шифрованного текста
дают информацию, позволяющую определить ключ шифрования.
Диффузия. Криптографический подход, при котором ставится цель замаскиро-
вать статистические особенности открытого текста путем распределения
влияния каждого отдельного элемента открытого текста на множество эле-
ментов шифрованного текста.
Защищенность по вычислениям. Защищенность в силу того, что затраченные на
преодоление защиты время и/или стоимость оказываются слишком высо-
кими и поэтому нецелесообразными.
Код. Жесткое правило замены элемента информации (например, буквы, слова, фра-
зы) другим объектом, не обязательно того же сорта. В общем случае при этом
не ставится цель скрыть смысл. Примерами являются ASCII-коды символов
(для представления каждого символа используется 7 бит) и частотная манипу-
ляция (каждое двоичное значение представляется определенной частотой).
Код аутентичности сообщения (МАС). Криптографическая контрольная сумма.
Конфузия. Криптографический подход, при котором ставится цель сделать связь
между статистическими характеристиками шифрованного текста и значени-
ем ключа шифрования настолько сложной, насколько это вообще возможно.
412
Словарь терминов
Достигается за счет применения сложного алгоритма кодирования, завися-
щего и от ключа, и от вводимых данных.
Криптоанализ. Область криптологии, в которой рассматриваются вопросы взло-
ма шифров с целью восстановить информацию в открытом виде или фаль-
сифицировать шифрованную информацию, которая должна восприниматься
как подлинная.
Криптографическая контрольная сумма. Аутентификатор, являющийся крипто-
графической функцией как подлежащих аутентификации данных, так и
секретного ключа. Называется также кодом аутентичности сообщения
(Message Authentication Code — MAC).
Криптография. Область криптологии, в которой рассматриваются вопросы соз-
дания алгоритмов шифрования и дешифрования с целью обеспечения га-
рантий секретности и/или достоверности сообщений.
Криптология. Наука о защите средств коммуникации, охватывающая крипто-
графию и криптоанализ.
Лавинный эффект. Характеристика алгоритма шифрования, в котором малые
изменения в открытом тексте или ключе порождают большие изменения в
шифрованном тексте. Для хэш-кода лавинный эффект означает большие
изменения в профиле сообщения, вызываемые малыми изменениями в са-
мом сообщении.
Личный ключ. Один из двух ключей, применяемых в асимметричной схеме
шифрования. Для защищенности связи требуется, чтобы секретный ключ
был известен только его владельцу.
Логическая бомба. Логика, встроенная в компьютерную программу и ожидаю-
щая выполнения в системе определенной комбинации условий. Когда эти
условия удовлетворены, происходит выполнение некоторой функции, обыч-
но имеющей своей целью несанкционированные действия.
Люк (или лазейка). Секретный недокументированный вход в программу, используе-
мый для получения доступа в обход обычной процедуры аутентификации.
Мандатный контроль за доступом. Средства ограничения доступа к объектам,
основанные на фиксированных атрибутах защиты, присваиваемых пользо-
вателям, а также файлам и другим объектам. Эти средства контроля явля-
ются мандатными (обязательными), т.е. не могут быть изменены пользова-
телями или их программами.
Многократное шифрование. Повторное использования функции шифрования с
различными ключами с целью получения более сложной зависимости шиф-
рованного текста от открытого.
Многоуровневая защита. Система, в которой реализуется контроль доступа для
множества уровней категорий защиты данных.
Нарушитель. Индивидуум, пытающийся получить или получивший несанкцио-
нированный доступ к вычислительной системе или несанкционированные
привилегии в такой системе.
Односторонняя функция. Функция, которая сама вычисляется легко, но вычис-
ление обратной по отношению к ней функции практически невозможно.
Словарь терминов
413
Односторонняя функция с лазейкой. Функция, которая сама вычисляется легко,
но вычисление обратной по отношению к ней функции практически невоз-
можно, если только не известна определенная секретная информация.
Оказия. Идентификатор или число, используемые только один раз.
Открытый ключ. Один из двух ключей, используемых в асимметричной схеме
шифрования. Открытый ключ делается доступным всем, чтобы его можно
было использовать в паре с соответствующим личным ключом.
Открытый текст. Ввод функции шифрования или вывод функции дешифрования.
Пароль.* Строка символов, используемая для аутентификации объекта. Знание
пароля и связанного с ним идентификатора пользователя рассматривается
как доказательство права на использование возможностей, связываемых с
данным идентификатором пользователя.
Поточный шифр. Алгоритм симметричной схемы шифрования, в котором выво-
димый шифрованный текст получается поразрядно или байт за байтом из
потока вводимого открытого текста.
Профиль сообщения. Функция хэширования.
Разграничительный (дискреционный) контроль доступа.* Средства ограничения дос-
тупа к объектам, основанные на идентификации субъектов и/или групп, кото-
рым они принадлежат. Эти средства являются дискреционными в том смысле,
что субъект с определенными правами доступа имеет возможность передать свое
право (возможно, косвенным образом) любому другому субъекту (если это не
противоречит принятым мандатным ограничениям контроля).
Сеансовый ключ. Временный ключ шифрования, используемый двумя доверите-
лями (принципалами).
Секретный ключ. Ключ, применяемый в системе симметричного шифрования.
Обе участвующие в обмене данными стороны должны совместно использо-
вать один и тот же ключ, который должен оставаться секретным, чтобы
связь оставалась защищенной.
Симметричное шифрование. Криптосистема, при которой шифрование и дешиф-
рование выполняются с использованием одного и того же ключа. То же, что
и традиционное шифрование.
Сцепление блоков. Процедура схемы симметричного блочного шифрования, в
результате выполнения которой выходной блок данных оказывается зави-
симым не только от текущего вводимого блока открытого текста и ключа,
но и от раннее введенных и/или ранее выведенных данных. В результате
сцепления блоков два встречающихся в сообщении одинаковых блока от-
крытого текста порождают разные блоки шифрованного текста, что должно
затруднять криптоанализ.
Тайный канал. Канал связи, который дает возможность передавать информацию
способом, не предусмотренным разработчиками средства коммуникации.
Традиционное шифрование. Симметричное шифрование.
“Троянский конь”.* Компьютерная программа с кажущимися или действительно по-
лезными функциями, содержащая дополнительные (скрытые) функции, тайно
использующие законные права выполняющего ее процесса во вред защите.
414
Словарь терминов
Функция хэширования. Функция, отображающая блок данных или сообщение
переменной длины в значение фиксированной длины, называемое хэш-
кодом. Подобная функция выбирается таким образом, чтобы при соответст-
вующей защите она могла играть роль аутентификатора данных или сооб-
щения. То же, что и профиль сообщения.
Центр распределения ключей. Система, уполномоченная доставлять временные се-
ансовые ключи доверителям. Каждый сеансовый ключ передается в шифрован-
ном виде, для чего используется главный ключ, применяемый центром распре-
деления ключей совместно с доверителем, которому передаются данные.
Цифровая подпись. Механизм аутентификации, дающий создателю сообщения воз-
можность добавить к сообщению код, который может служить подписью. Под-
пись гарантирует аутентичность источника и целостность сообщения.
“Червь”. Программа, которая способна воспроизводить себя, создавая копии, и
пересылать эти копии от компьютера к компьютеру через сетевые соедине-
ния. Будучи принятым системой, “червь” может активизироваться, чтобы
продолжить размножение, и распространяться дальше. Кроме распростра-
нения, “червь” обычно выполняет еще и некоторую нежелательную для
системы функцию.
Шифр. Алгоритм шифрования и дешифрования. Шифр заменяет имеющийся фраг-
мент информации (элемент открытого текста) другим объектом с целью сокры-
тия сути информации. Обычно правило замены зависит от секретного ключа.
Шифрование. Преобразование открытого текста или данных в форму непонятно-
го содержимого с помощью обратимой трансляции, основанной на таблице
перевода или алгоритме трансляции.
Шифрование с открытым ключом. Асимметричное шифрование.
Шифрованный текст. Данные вывода алгоритма шифрования, представляющие
собой шифрованную форму сообщения или данных.
Kerberos. Имя, присвоенное сервису аутентификации в рамках проекта Athena.
Словарь терминов
415
This page intentionally left blank
Список
сокращений
AES Advanced Encryption Standard (усовершенствованный стандарт шифрования)
АН Authentication Header (заголовок аутентификации)
ANSI American National Standards Institute (Американский национальный институт стандартов)
СВС Cipher Block Chaining (сцепление шифрованных блоков)
CESG Communications-Electronics Security Group (Группа защиты электронных коммуникаций)
CFB Cipher Feedback (шифрованная обратная связь)
DEA Data Encryption Algorithm (алгоритм шифрова- ния данных)
DES Data Encryption Standard (стандарт шифрова- ния данных)
DSA Digital Signature Algorithm (алгоритм цифровой подписи)
DSS Digital Signature Standard (стандарт цифровой подписи)
ЕСВ Electronic Codebook (электронная шифроваль- ная книга)
ESP Encapsulating Security Payload (включающее защиту содержимое)
FIPS Federal Information Processing Standard (федеральный стандарт обработки информации)
IAB Internet Architecture Board (Совет по архитек- туре Internet)
IDEA International Data Encryption Algorithm (международный алгоритм шифрования данных)
IETF Internet Engineering Task Force (Проблемная группа проектирования Internet)
IP Internet Protocol (протокол межсетевого взаи- модействия)
IPSec IP Security (протокол защиты IP)
ISO International Organization for Standardization (Международная организация по стандартизации)
ITU International Telecommunication Union (Международный союз телекоммуникаций)
ITU-T ITU Telecommunication Standardization Sector (Сектор стандартизации
Международного союза телекоммуникаций)
IV Initialization Vector (вектор инициализации)
KDC Key Distribution Center (центр распределения ключей)
LAN Local Area Network (локальная сеть)
MAC Message Authentication Code (код аутентичности сообщения)
MIC Message Integrity Code (код целостности сообщения)
MIME Multi-Purpose Internet Mail Extension (многоцелевые расширения элек-
тронной почты в сети Internet)
MD5 Message Digest, Version 5 (алгоритм вычисления профиля сообщения,
версия 5)
MTU Maximum Transmission Unit (максимальная единица передачи)
NIST National Institute of Standards and Technology (Национальный институт
стандартов и технологий)
NSA National Security Agency (Управление национальной безопасности)
OFB Output Feedback (обратная связь по выходу)
PGP Pretty Good Privacy (набор алгоритмов и программ шифрования с ис-
пользованием открытых ключей)
PRNG Pseudorandom Number Generator (генератор псевдослучайных чисел)
RFC Request for Comments (серия документов IETF, выпуск которых начат в
1969 году. Содержит описания набора протоколов Internet и связанную
с ними информацию)
RNG Random Number Generator (генератор случайных чисел)
RSA Rivest-Shamir-Adelman (алгоритм Райвеста-Шамира-Аделмана)
SET Secure Electronic Transaction (протокол защищенных электронных
транзакций)
SHA Secure Hash Algorithm (алгоритм защищенного хэширования)
SHS Secure Hash Standard (стандарт защищенного хэширования)
S/MIME Secure MIME (защищенные многоцелевые расширения электронной
почты в сети Internet)
SNMP Simple Network Management Protocol (простой протокол сетевого управ-
ления)
SNMPv3 Simple Network Management Protocol, Version 3 (простой протокол сете-
вого управления версии 3)
SSL Secure Sockets Layer (протокол защищенных сокетов)
TCP Transmission Control Protocol (протокол управления передачей)
TDEA Triple Data Encryption Algorithm (“тройной” DEA)
TLS Transport Layer Security (протокол защиты транспортного уровня)
UDP User Datagram Protocol (протокол передачи дейтаграмм пользователя)
WAN Wide Area Network (глобальная сеть)
418
Список сокращений
Список литературы
СТОЛ01 Столлингс В. Криптография и защита сетей: принципы и практика, 2-е
издание, “Вильямс”, 2001. (Перевод с английского языка книги [STAL99a].)
ЯЩЕН00 Ященко В. В., ред. Введение в криптографию. МЦНМО-ЧеРо, Москва,
2000.
ABRA87 Abrams, М., and Podell, Н. Computer and Network Security. Los Alamitos,
CA: IEEE Computer Society Press, 1987.
ABRA95 Abrams, M.; Jajodia, S.; and Podell, H. eds. Information Security: An Inte-
grated Collection of Essays. Los Alamitos, CA: IEEE Computer Society Press, 1995.
ADAM92 Adam, J. “Virus Threats and Countermeasures.” IEEE Spectrum, August
1992.
ADAM97 Adams, C. “Constructing Symmetric Ciphers Using the CAST Design.”
Designs, Codes, and Cryptography, 1997.
ALVA90 Alvare, A. “How Crackers Crack Passwords or What Passwords to Avoid.”
Proceedings, UNIX Security Workshop II, August 1990.
ANDE80 Anderson, J. Computer Security Threat Monitoring and Surveillance. Fort
Washington, PA: James P. Anderson Co., April 1980.
BAUE88 Bauer, D., and Koblentz, M. “NIDX — An Expert System for Real-Time
Network Intrusion Detection.” Proceedings, Computer Networking Symposium,
April 1988.
BELL90 Bellovin, S., and Merritt, M. “Limitations of the Kerberos Authentication
System.” Computer Communications Review, October 1990.
BELL92 Bellovin, S. “There Be Dragons.” Proceedings, UNIX Security Symposium
III, September 1992.
BELL93 Bellovin, S. “Packets Found on an Internet.” Computer Communications Re-
view, July 1993.
BELL94 Bellovin, S., and Cheswick, W. “Network Firewalls.” IEEE Communications
Magazine, September 1994.
BELL96a Bellare, M.; Canetti, R.; and Krawczyk, H. “Keying Hash Functions for
Message Authentication.” Proceedings, CRYPTO '96, August 1996; опубликовано
изд-вом Springer-Verlag. Расширенная версия доступна по адресу http://www-
cse.ucsd.edu/users/mihir.
BELL96b Bellare, M.; Canetti, R.; and Krawczyk, H. “The HMAC Construction.” Cryp-
toBytes, Spring 1996.
BERG97 Berg, A. “Viruses: More Infections than Ever, Users Say.” LAN Times, June
23,1997.
BERS92 Berson, T. “Differential Cryptanalysis Mod 232 with Applications to MD5.”
Proceedings, EUROCRYPT '92, May 1992; опубликовано изд-вом Springer-Verlag.
BLOO70 Bloom, B. “Space/time Trade-Offs in Hash Coding with Allowable Errors.”
Communications of the ACM, July 1970.
BLUM97a Blumenthal, U.; Hien, N.; and Wijnen, B. “Key Derivation for Network
Management Applications.” IEEE Network, May/June 1997.
BLUM97b Blumenthal, U., and Wijnen, B. “Security Features for SNMPv3.” The Sim-
ple Times, December 1997.
ВОЕВ85 Boebert, W; Kain, R.; and Young, W. “Secure Computing: the Secure Ada
Target Approach.” Scientific Honey welter, July 1985; имеется перепечатка
в [ABRA87].
BOER93 Boer, В., and Bosselaers, A. “Collisions for the Compression Function of
MD5.” Proceedings, EUROCRYPT '93, 1993; опубликовано изд-вом Springer-
Verlag.
BOSS97 Bosselaers, A.; Dobbertin, H.; and Preneel, B. “The RIPEMD-160
Cryptographic Hash Function.” Dr. Dobb's Journal, January 1997.
BOWL92 Bowles, J., and Pelaez, C. “Bad Code.” IEEE Spectrum, August 1992.
BRYA88 Bryant, W. Designing an Authentication System: A Dialogue in Four Scenes.
Project Athena document, February 1988. Доступен по адресу
http://web.mit.edu/kerberos/www/dialogue.html.
CERT99 CERT Coordination Center. CERT Coordination Center 1998 Annual Report.
Carnegie-Mellon University, 1999. Доступен по адресу
h ttp: / /www. cert. or g/ annual_rpts/cert_rpt_98. html.
CHAP95 Chapman, D., and Zwicky, E. Building Internet Firewalls. Sebastopol, CA:
CTReilly, 1995.
CHEN98 Cheng, P., et al. “A Security Architecture for the Internet Protocol.” IBM
Systems Journal, Number 1,1998.
CHESOO Cheswick, W., and Bellovin, S. Firewalls and Internet Security: Repelling the
Wily Hacker. Reading, MA: Addison-Wesley, 2000.
CHES97 Chess, D. “The Future of Viruses on the Internet.” Proceedings, Virus Bulle-
tin International Conference, October 1997.
COHE94 Cohen, F. A Short Course on Computer Viruses. New York: Wiley, 1994.
COME95 Comer, D. Internetworking with TCP/IP, Volume I: Principles, Protocols and
Architecture. Upper Saddle River, NJ: Prentice Hall, 1995.
COOP89 Cooper, J. Computer and Communications Security: Strategies for the 1990s.
New York: McGraw-Hill, 1989.
DAMG89 Damgard, I. “A Design Principle for Hash Functions.” Proceedings, CRYPTO
p '89, 1989; опубликовано изд-вом Springer-Verlag.
I>AVI89 Davies, D., and Price, W. Security for Computer Networks. New York: Wiley,
1989.
DAVI93 Davies, C., and Ganesan, R. “BApasswd: A New Proactive Password
Checker.” Proceedings, 16th National Computer Security Conference, September
1993.
DENN87 Denning, D. “An Intrusion-Detection Model.” IEEE Transactions on Soft-
ware Engineering, February 1987.
DENN90 Denning, P. Computers Under Attack: Intruders, Worms, and Viruses.
Reading, MA: Addison-Wesley, 1990.
DIFF76 Diffie, W., and Hellman, M. “New Directions in Cryptography.” IEEE
Transactions on Information Theory, November 1976.
DIFF88 Diffie, W. “The First Ten Years of Public-Key Cryptography.” Proceedings
of the IEEE, May 1988. Имеется перепечатка в [SIMM92a].
DOBB96a Dobbertin, H. “The Status of MD5 After a Recent Attack.” Crypto Bytes,
Summer 1996.
DOBB96b Dobbertin, H.; Bosselaers, A.; and Preneel, B. “RIPEMD-160: A
Strengthened Version of RIPEMD.” Proceedings, Third International Workshop on
Fast Software Encryption, 1996; опубликовано изд-вом Springer-Verlag.
DORA99 Doraswamy, N., and Harkins, D. IPSec. Upper Saddle River, NJ: Prentice
Hall, 1999.
420
Список литературы
DREW99 Drew, G. Using SET for Secure Electronic Commerce. Upper Saddle River,
NJ: Prentice Hall, 1999.
EFF98 Electronic Frontier Foundation. Cracking DES: Secrets of Encryption Re-
search, Writeap Politics, and Chip Design. Sebastopol, CA: O’Reilly, 1998.
ENGE80 Enger, N., and Howerton, P. Computer Security. New York: Amacom, 1980.
FEIS73 Feistel, H. “Cryptography and Computer Privacy.” Scientific American. May
1973.
FORD95 Ford, W. “Advances in Public-Key Certificate Standards.” ACM SIGSAC Re-
view, July 1995.
FORR97 Forrest, S.; Hofmeyr, S.; and Somayaji, A. “Computer Immunology.” Com-
munications of the ACM, October 1997.
FREE93 Freedman, D. “The Goods on Hacker Hoods.” Forbes ASAP, 13 September
1993.
GARD77 Gardner, M. “A New Kind of Cipher That Would Take Millions of Years to
Break.” Scientific American, August 1977.
GARF97 Garfinkel, S., and Spafford, G. Web Security & Commerce. Cambridge, MA:
CTReilly and Associates, 1997.
GASS88 Gasser, M. Building a Secure Computer System. New York: Van Nos-trand
Reinhold, 1988.
HEBE92 Heberlein, L.; Mukherjee, B.; and Levitt, K. “Internetwork Security Monitor:
An Intrusion-Detection System for Large-Scale Networks.” Proceedings, 15th Na-
tional Computer Security Conference, October 1992.
HELD96 Held, G. Data and Image Compression: Tools and Techniques. New York:
Wiley, 1996.
HOFF90 Hoffman, L., editor. Rogue Programs: Viruses, Worms, and Trojan Horses.
New York: Van Nostrand Reinhold, 1990.
HUIT98 Huitema, C. IPv6: The New Internet Protocol. Upper Saddle River, NJ:
Prentice Hall, 1998.
IANS90 FAnson, C., and Mitchell, C. “Security Defects in CCITT Recommendation
X.509 — The Directory Authentication Framework.” Computer Communications
Review, April 1990.
ILGU93 Ilgun, K. “USTAT: A Real-Time Intrusion Detection System for UNIX.” Pro-
ceedings, 1993 IEEE Computer Society Symposium on Research in Security and
Privacy, May 1993.
JAVI91 Javitz, H., and Valdes, A. “The SRI IDES Statistical Anomaly Detector.”
Proceedings. 1991 IEEE Computer Society Symposium on Research in Security and
Privacy, May 1991.
JUEN85 Jueneman, R.; Matyas, S.; and Meyer, C. “Message Authentication.” IEEE
Communications Magazine, September 1985.
KEPH97a Kephart, J.; Sorkin, G.; Chess, D.; and White, S. “Fighting Computer
Viruses.” Scientific American, November 1997.
KEPH97b Kephart, J.; Sorkin, G.; Swimmer, B.; and White, S. “Blueprint for a
Computer Immune System.” Proceedings, Virus Bulletin International Conference,
October 1997.
KLEI90 Klein, D. “Foiling the Cracker: A Survey of, and Improvements to, Password
Security.” Proceedings, UNIX Security Workshop II, August 1990.
KOBL92 Koblas, D., and Koblas, M. “SOCKS.” Proceedings, UNIX Security Sympo-
sium III, September 1992.
KOHL89 Kohl, J. “The Use of Encryption in Kerberos for Network Authentication.”
Proceedings, Crypto '89, 1989; опубликовано изд-вом Springer-Verlag.
Список литературы
421
KOHL94 Kohl, J.; Neuman, B.: and Ts’o, T. “The Evolution of the Kerberos
Authentication Service.” In Brazier, F., and Johansen, D. Distributed Open Sys-
tems. Los Alamitos, CA: IEEE Computer Society Press, 1994. Доступна по адресу
http://web.mit.edu/kerberos/www/papers.html.
LAI91 Lai. X., and Massey, J. “Markov Ciphers and Differential Cryptanalysis.”
Proceedings, EUROCRYPT '91, 1991; опубликовано изд-вом Springer-Verlag.
LEUT94 Leutwyler, K. “Superhack.” Scientific American, July, 1994.
LODI98 Lodin, S., and Schuba, C. “Firewalls Fend Off Invasions from the Net.”
IEEE Spectrum. February 1998.
LUNT88 Lunt, T., and Jagannathan, R. “A Prototype Real-Time Intrusion-Detection
Expert System.” Proceedings. 1988 IEEE Computer Society Symposium on Re-
search in Security and Privacy, April 1988.
MACG97 Macgregor, R.; Ezvan, C.; Liguori, L.; and Han, J. Secure Electronic Trans-
actions: Credit Card Payment on the Web in Theory and Practice. IBM RedBooi
SG24-4978-00, 1997. Доступна по адресу www.redbooks.ibm.com/SG244978.
MADS93 Madsen, J. “World Record in Password Checking.” Usenet, comp, security,
misc newsgroup, August 18, 1993.
MARK97 Markham, T. “Internet Security Protocol.” Dr. Dobb's Journal, June 1997.
MENE97 Menezes, A.; Oorshcot, P.; and Vanstone, S. Handbook of Applied Cryptogra-
phy. Boca Raton, FL: CRC Press, 1997.
MERK79 Merkle, R. Secrecy, Authentication, and Public Key Systems. Ph.D. Thesis,
Stanford University, June 1979.
MERK89 Merkle, R. “One Way Hash Functions and DES.” Proceedings, CRYPTO
'89,1989; опубликовано изд-вом Springer-Verlag.
MEYE82 Meyer, C., and Matyas, S. Cryptography: A New Dimension in Computer Data
Security. New York: Wiley, 1982.
MILL88 Miller, S.; Neuman, B.; Schiller, J.; and Saltzer, J. “Kerberos Authentication
and Authorization System.” Section E.I.I, Project Athena Technical Plan, M.I.T
Project Athena, Cambridge, MA. 27 October 1988.
>MILL98 Miller, S.. IPv6: The New Internet Protocol, Upper Saddle River, NJ:
J Prentice Hall, 1998.
MITC90 Mitchell, C.; Walker, M.; and Rush, D. “CCITT/ISO Standards for Secuie
Message Handling.” IEEE Journal on Selected Areas in Communications, May
1989.
MURH98 Murhammer, M., et al. TCP/IP: Tutorial and Technical Overview. Upper
Saddle River, NJ: Prentice Hall, 1998.
NACH97 Nachenberg, C. “Computer Virus-Antivirus Coevolution.” Communications of
the ACM, January 1997.
NEED78 Needham, R., and Schroeder, M. “Using Encryption for Authentication in
Large Networks of Computers.” Communications of the ACM, December 1978.
NEUM93 Neuman, B. “Proxy-Based Authorization and Accounting for Distributed
Systems.” Proceedings of the 13th International Conference on Distributed Comput-
ing Systems, May 1993.
NIST91 National Institute of Standards and Technology, Glossary of Computer Secu-
rity Terminology. NISTIR4659, 1991.
OPPL97 Oppliger, R. “Internet Security: Firewalls and Beyond.” Communications of
the ACM. May 1997.
PFLE97 Pfleeger, C. Security in Computing. Upper Saddle River, NJ: Prentice Hall,
1997.
PORR92 Porras, P. STAT: A State Transition Analysis Tool for Intrusion Detection.
Master’s Thesis, University of California at Santa Barbara, July 1992.
422
Список литературы
RIVE78 Rivest, R.; Shamir, A.; and Adieman, L. “A Method for Obtaining Digital
Signatures and Public Key Cryptosystems.” Communications of the ACM, February
1978.
RIVE94 Rivest, R. “The RC5 Encryption Algorithm.” Proceedings, Second Interna-
tional Workshop on Fast Software Encryption, December 1994; опубликовано изд-
вом Springer-Verlag.
RIVE95 Rivest, R. “The RC5 Encryption Algorithm.” Dr. Dobb's Journal, January
1995.
RUBI97 Rubin, A.; Geer, D.; and Ranum, M. Web Security Sourcebook. New York:
Wiley, 1997.
SAFF93 Safford, D.; Schales, D.; and Hess, D. “The TAMU Security Package: An
Ongoing Response to Internet Intruders in an Academic Environment.” Proceed-
ings, UNIX Security Symposium IV, October 1993.
SAL096 Salomaa, A. Public-Key Cryptography. New York: Springer-Verlag, 1996.
SCHN93 Schneier, B. “Description of a New Variable-Length Key, 64-bit Block Cipher
(Blowfish).” Proceedings, Workshop on Fast Software Encryption, December 1993;
опубликовано изд-вом Springer-Verlag.
SCHN94 Schneier, R. “The Blowfish Encryption Algorithm.” Dr. Dobb's Journal, April
1994.
SCHN96 Schneier, B. Applied Cryptography. New York: Wiley, 1996.
SEBE89 Seberry, J., and Pieprzyk, J. Cryptography: An Introduction to Computer Se-
curity. Englewood Cliffs, NJ: Prentice Hall, 1989.
SEME96 Semeria, C. Internet Firewalls and Security. 3Com Corp., 1996. Доступна no
адресу www.3com.com.
SIMM92a Simmons, G., ed. Contemporary Cryptology: The Science of Information In-
tegrity. Piscataway, NJ: IEEE Press, 1992.
SIMM92b Simmons, G. “A Survey of Information Authentication," in [SIMM92a].
SMIT97 Smith, R. Internet Cryptography. Reading, MA: Addison-Wesley, 1997.
SNAP91 Snapp, S., et al. “A System for Distributed Intrusion Detection.” Proceed-
ings, COMPCON Spring '91, 1991.
SPAF89 Spafford, E.; Heaphy, K.; and Ferbrache, D. Computer Viruses. Arlington,
VA: ADAPSO, 1989.
SPAF92a Spafford, E. “Observing Reusable Password Choices.” Proceedings, UNIX Se-
curity Symposium III, September 1992.
SPAF92b Spafford, E. “OPUS: Preventing Weak Password Choices.” Computers and
Security, No. 3, 1992.
STAL99a Stallings, W. Cryptography and Network Security: Principles and Practice,
2nd edition. Upper Saddle River, NJ: Prentice Hall, 1999. (Имеется перевод на
русский язык: см. [СТОЛ01].)
STAL99b Stallings, W. SNMP, SNMPv2, SNMPv3, and RMON 1 and 2. Reading,
MA: Addison-Wesley, 1999.
STALOO Stallings, W. Data and Computer Communications, 6th Edition. Upper
Saddle River, NJ: Prentice Hall, 2000.
STEI88 Steiner, J.; Neuman, C.; and Schiller, J. “Kerberos: An Authentication
Service for Open Networked Systems.” Proceedings of the Winter 1988 USENIX
Conference, February 1988.
STEP93 Stephenson, P. “Preventive Medicine.” LAN Magazine, November 1993.
STER92 Sterling, B. The Hacker Crackdown: Law and Disorder on the Electronic
Frontier. New York: Bantam, 1992.
STEV94 Stevens, W. TCP/IP Illustrated, Volume 1: The Protocols. Reading, MA:
Addison-Wesley, 1994.
Список литературы
423
STIN95 Stinson, D. Cryptography: Theory and Practice. Boca Raton, FL: CRC Press,
1995.
STOL88 Stoll, C. “Stalking the Wily Hacker.” Communications of the ACM, May
1988; имеется перепечатка в [DENN90].
STOL89 Stoll, C. The Cuckoos Egg. New York: Doubleday, 1989.
THOM84 Thompson, K. “Reflections on Trusting Trust (Deliberate Software Bugs).”
Communications of the ACM, August 1984.
TIME90 Time, Inc. Computer Security, Understanding Computers Series. Alexandria,
VA: Time-Life Books. 1990.
TSUD92 Tsudik, G. “Message Authentication with One-Way Hash Functions.” Pro-
ceedings, INFOCOM '92, May 1992.
TUCH79 Tuchman, W. “Hellman Presents No Shortcut Solutions to DES.” IEEE Spec-
trum, July 1979.
VACC89 Vaccaro, H., and Liepins, G. “Detection of Anomalous Computer Session
Activity.” Proceedings of the IEEE Symposium on Research tn Security and Pri-
vacy, May 1989.
WEIS93 Weiss, J., and Schremp, D. “Putting Data on a Diet.” IEEE Spectrum,
August 1993.
ZIV77 Ziv, J., and Lempel, A. “A Universal Algorithm for Sequential Data
Compression.” IEEE Transactions on Information Theory, May 1977.
424
Список литературы
Предметный указатель
A О
АН, 208 AutoExec, 376 C Oakley, 229 p
PGP, 152
CAST-128, 59 D proxy, 302 R
DES, 49 radix-64, 158; 197
DSS. 98 E RFC 822, 173 RIPEMD-160, 84 RSA, 92
ESP,208 F S/MIME, 173 SET, 257; 277 S
Fortezza, 261; 267 H SHA-1, 80 SMTP, 174 SNMP, 294 SSL, 257
HMAC, 85 I TLS, 257 T
internet, 18 IPSec, 205 ISAKMP, 229; 234 К X.509, 135 X ГЖ
Kerberos, 114 M ZIP, 194 z
A
MAC, 73 MD5, 84 Автомакрос, 376
MIME, 174 Авторитетный процессор SNMP, 317
Агент
монитора локальной сети, 364
пользователя, 189
узла, 364
Агент управления, 295
Анализ потока данных, 26
Анализ трафика, 316
Антивирусная защита, 376
Арифметика в классах вычетов, 108
Аутентификатор, 100
Аутентификация, 28; 117; 120; 140;
256
двухшаговая, 142
одношаговая, 141
трехшаговая, 142
Б
База MIB. См. информационная база
системы управления
База данных ядра безопасности, 400
Бактерия, 370
Бастионный узел, 394
Безопасность
информационная, 18
компьютерная, 18
сетевая, 18
Блокирование сервиса, 316
Брандмауэр, 386
с экранированной подсетью, 397
с экранированным двухточечным
бастионным узлом, 397
с экранированным одноточечным
бастионным узлом, 395
Буфер упреждающей выборки, 196
в
Вектор инициализации, 259
Взаимно простые числа, 108
Взломщик, 338
Вирус, 369
загрузочный, 374
невидимка, 374
паразитный, 374
полиморфный, 374
резидентный, 374
Включающий защиту полезный груз.
См. ESP
Воспроизведение, 26
Вредоносная программа, 367
Вторжение, 340
Выбор пароля, 348
Высоконадежная система, 397; 402
Вычет, 108
г
Генерирование паролей, 348
Группа, 326
д
Датчик, 358
Делитель, 106
Диффи-Хеллмана алгоритм, 95
Доказуемость, 401
Доступность, 29; 255
Дуальная подпись, 282
3
Заголовок аутентификации. См. АН
Запрет
записи вниз, 400
чтения вверх, 400
Защищенная операционная система,
402
Защищенная связь, 210
Защищенный список рассылки, 193
и
Идентификатор ключа, 161
Идентификация преодоления защиты,
362
Извещение, 263
Изолированность, 401
Имитатор, 338
Имитация, 26; 316
Интервальный таймер, 359
Информационная база системы
управления, 295
Информационный обмен, 240
Истинно случайное число, 200
к
Квитирование, 264
Ключ
главный, 259
записи, 259
личный, 90
локализованный, 324
426
Предметный указатель
открытый, 90
секретный, 90
Код аутентичности сообщения (МАС),
73
• Сод контроля целостности, 216
Кодировка MIME, 179
Командный макрос, 376
Контекст MIB, 327
Контрольная запись, 356
системная, 356
специальная, 356
Конфиденциальность, 27; 255
Криптоанализ, 44
л
Лазейка, 367
Логическая бомба, 368
Локализация ключей SNMP, 323
Локализованный ключ, 324
Люк. См. лазейка
м
Макровирус, 375
Максимальная единица передачи. См.
MTU
Мандат возможностей, 399
Марковская модель, 350
Маршрут сертификации, 144
Матрица доступа, 398
Механизм защиты, 21
Механизм посредничества, 298
Многоуровневая система
безопасности, 400
Мобильная программа, 379
Модель USM, 316
Модель VACM, 326
Модель доверия, 171
Модель защиты сети, 29
Модификация
информации, 316
потока сообщений, 316
Модификация сообщений, 26
Модуль-посредник, 298
Мэйнфрейм, 386
н
Наибольший общий делитель, 107
Нарушение защиты, 20; 24
активное, 26
пассивное, 26
Нарушитель, 338
Начальное инфицирование. 374
Невозможность обмана, 29
Неизбежное посредничество, 401
Номинальная база данных политики
защиты, 211
о
Область Kerberos, 126
Область интерпретации. См. DOI
Обмен рецептами, 231
Обнаружение нарушений, 353
Объединение SNMP, 303
Объект SNMP, 306
Объект доступа, 398
Операционный центр, 280
Отзыв
открытого ключа, 172
Отзыв сертификата, 140
Отношения посредничества
внешние, 299
внутренние, 299
Отчет CERT, 204
Пароль, 342
Повторное туннелирование, 226
Показатель использования
ресурса, 359
Поле
доверия владельцу, 169
доверия подписи, 169
соответствия ключа, 169
Полезный груз, 234
Политика доступа SNMP, 304
Политика сертификации, 143
Помехи в обслуживании, 27
Поставщик услуг Internet, 386
Право доступа, 398
Правонарушитель, 338
Представление MIB, 327
SNMP, 304
Прерывание, 296
Примитив SNMP, 311
Провайдер, 386
Проверка паролей
реактивная, 349
Предметный указатель
427
упреждающая, 349
Прокси-сервер, 392
Простое
требование безопасности, 400
число, 106
Протокол межсетевого
взаимодействия, 242
Протокольная единица данных, 301
Профиль объединения SNMP, 304
Процессор SNMP, 306
авторитетный, 317
Псевдослучайная функция, 273
Псевдослучайное число, 200
Пучок защищенных связей, 225
р
Разглашение информации, 316
Раскрытие содержимого сообщений,
26
Распределение ключей, 65
Распределенная система обнаружения
нарушений, 363
Режим
ЕСВ, 59
РСВС, 129; 148
транспортный, 213
туннельный, 213
Режим доступа SNMP, 304
Рейтинг подозрения, 363
>> Рецепт, 231
1
с
Свойство *, 400
Связка ключей, 159; 163
Сеанс SSL, 258
Сегментация, 154
Селектор защищенной связи, 211
Сервис посредничества, 302
Сервисная служба защиты, 21
Сертификат
VeriSign, 190
возвратный, 139
открытого ключа, 135
пользователя, 137
прямой,139
Сжатие данных, 194
Сигнатура, 365
вируса, 378
Сканер сигнатур вирусов, 378
Скользящий буфер предыстории, 196
Содержимое MIME, 176
каноническая форма, 182
собственная форма, 182
Соединение SSL, 258
Сообщение
многокомпонентное, 180
Список
отозванных сертификатов, 140
управления доступом, 398
Стандартный
агент SNMP, 309
администратор SNMP, 307
Станция управления, 295
Статистическая аномалия, 361
Степень
доверия, 168
защиты. 327
Структура вируса, 371
Субъект
доступа, 398
сертификации, 144
Схема
адресации, 242
Диффи-Хеллмана, 95
шифрования защищенная по
вычислениям, 46
Счетчик, 358
Тайный пользователь, 338
Технология полного декодирования, 378
Транзакция, 277
Транспортная смежность, 225
Транспортно-туннельный пучок, 227
Троянский конь, 369
Управление
доступом, 347
доступом к данным, 397
открытыми ключами, 166
Управление доступом, 29
Управление ключами
автоматизированное, 229
ручное, 229
428
Предметный указатель
ф
Фильтр Блума, 351
Фильтрующий маршрутизатор, 390
Формат BER, 186
Функция хэширования, 74
X
Хакер, 338
ц
Целостность, 28; 255
Центр
сертификации, 135
Центральный администратор, 364
Цепочка сертификатов, 138
Цифровая
иммунная система, 379
подпись, 154
ч
Червь, 370
Числа, сравнимые по модулю п, 108
ш
Шифр
продукционный, 43
Шифрование
асимметричное, 44
симметричное, 42; 44
традиционное, 42
Шлюз
платежной сети, 281
прикладного уровня, 392
уровня коммутации, 393
э
Экспертная система, 362
Электронная почта, 152
Эмитент платежной карточки, 280
Эмулятор процессора, 378
Энергичный обмен, 240
я
Ярлык защиты, 193
л ап
Научно-популярное издание
Вильям Столлингс
Основы защиты сетей. Приложения и стандарты
Литературный редактор
Верстка
Художественный редактор
Корректоры
О.Ю. Белозовская
О.В. Линник
СА. Чернокозинский
ЛА. Гордиенко, О.В. Мишу тина
Издательский дом “Вильямс”.
101509, Москва, ул. Лесная, д. 43, стр. 1.
Изд. лиц. ЛР № 090230 от 23.06.99
Госкомитета РФ по печати.
Подписано в печать 08.07.2002. Формат 70x100/16.
Гарнитура Times. Печать офсетная.
Усл. печ. л. 34,8. Уч.-изд. л. 26,7.
Тираж 3500 экз. Заказ № 789.
Отпечатано с диапозитивов в ФГУП “Печатный двор”
Министерства РФ по делам печати,
телерадиовещания и средств массовых коммуникаций.
197110, Санкт-Петербург, Чкаловский пр., 15.
. « • Вильям Столлингс
Структурная
организация
и архитектура
компьютерных систем,
5-е издание
Плановая дата выхода -
3-й кв. 2002 г.
Книга содержит исчерпывающие сведения
о современном состоянии дел в области
организации и архитектуры компьютеров, включая
обсуждение наиболее интенсивно развивающейся
в настоящее время суперскалярной технологии
и параллельной организации процессоров. Ее назначение
состоит в ясном и четком изложении сведений об
особенностях построения и возможностях существующих
компьютеров. Излагаемый материал отвечает всем
требованиям учебного процесса, поскольку его
изложение опирается на фундаментальные принципы,
одновременно сохраняя акцент на важнейшем аспекте
проектирования компьютеров — достижении
максимальной производительности. Обсуждаемые гемы
иллюстрируются большим количеством примеров,
большая часть которых относится к семейству
процессоров Pentium.
Книга будет полезна самому широкому кругу читателей,
включая студентов соответствующих специальностей,
профессионалов в области проектирования
и эксплуатации вычислительной техники, а также всем
гем, кто всерьез интересуется современным состоянием
дел в области архитектуры и организации компьютеров.
Вильям Сталлингс
Компьютерные
системы передачи
данных,
6-е издание
Плановая дата выхода -
3-й кв. 2002 г.
Эта книга, содержащая подробный и всесторонний
обзор всех областей передачи данных, является в то
же время учебником по ведущим сетевым
технологиям и протоколам. В течение последних 15 лет
она считается стандартом в своей отрасли. Книга
удовлетворяет потребностям как студентов, так и ученых
или специалистов. Существенное внимание в ней
уделяется фундаментальным принципам, а так же
подчеркивается решающая роль вопросов
производительности при разработке протоколов и сетей.
В новом издании обстоятельно и полно рассматриваются
важнейшие технические аспекты собственно передачи
данных, а также организации локальных и глобальных
сетей и действия сетевых протоколов.
ОСНОВЫ ЗАЩИТЫ
ПРИЛОЖЕНИЯ И СТАНДА
ВИЛЬЯМ СТОЛЛИНГС
В эпоху глобального распространения электронных средств связи, когда процветание
корпораций и продуктивность труда отдельных людей подвергаются новым угрозам со
стороны вирусов, хакеров, электронного подслушивания и мошенничества, вопросы
безопасности и защиты информации выходят на первый план. К счастью, здесь
оказывается весьма кстати уже вполне сформировавшаяся методика защиты сетей
и созданные на ее основе достаточно надежные приложения, обеспечивающие
безопасность и сетевую защиту на практике. Эта книга предлагает построенный на
основе целостного подхода, достаточно всеобъемлющий и вполне современный обзор
средств сетевой защиты и соответствующих приложений, обеспечивающих безопасность
при межсетевом взаимодействии, что на сегодняшний день является одним из жизненно
важных вопросов при использовании сетей и коммуникаций для обмена данными.
В своем бестселлере Вильям Столлингс, четырежды удостоенный наград TEXTY за
лучшие книги по компьютерным и прикладным наукам, предлагает обзор как основных
идей, так и практических средств защиты сетей.
Хорошо организованный материал книги оптимально подходит как для использования
преподавателями, так и для самостоятельного изучения предмета, предлагая вниманию
читателей следующее.
о Описание основных средств сетевой защиты и соответствующих приложений, включая
Kerberos, X.509v3, PGP, S/MIME, IPsec, SSL/TLS и SET.
о Обсуждение вопросов защиты Web и сетевого управления (SNMPv3).
о Обсуждение вопросов защиты системного уровня, включая защиту от нарушителей
и вирусов, а также вопросов использования брандмауэров и высоконадежных систем.
о По адресу http://www.shore.net/~ws/NetSec.html вы найдете оригиналы рисунков книги,
список адресов Internet и ссылки на другие Web-узлы, которые могут оказаться
полезными при изучении материала книги.
Вилъям Столлингс внес неоценимый вклад в целый ряд областей, связанных
с техническим прогрессом компьютерных сетей и сетевой архитектуры. Он является
автором семнадцати (а с учетом переработанных изданий — сорока двух) книг,
освещающих различные аспекты этой темы. Он является независимым консультантом,
услугами которого пользуются фирмы, производящие компьютеры и предлагающие
законченные сетевые решения, а также их клиенты, производители программного
обеспечения и государственные научно-исследовательские организации. Вильям
Столлингс имеет степень доктора в области вычислительной техники от
Массачусетсского технологического института и степень бакалавра в области
электротехники от университета Нотр-Дама (Hotre Dame). Список всех его книг,
выпущенных издательством Prentice Hall, можно найти по адресу http://www.prenhall.com.
ВИЛЬЯМС
www.williamspublishing.com
Prentice
Hall