/
Автор: Блэк У.
Теги: компьютерные технологии оргсвязь протоколы информационная безопасность интернет компьютерная безопасность
ISBN: 5-318-00002-9
Год: 2001
Текст
V. Блэк
Интернет
протоколы
безопасности
учебный
xjfy курс
безопасная передача
данных в Интернете
PH
PTR
[^ППТЕР
_ . J
V. Блэк
Интернет
протоколы
безопасности
учебный
курс
: й4:;>.^"хйййй-йуййй:йуйй:-::й:й’:-й;;:й'.Х
Санкт-Петербург
Москва • Харьков • Минск
2001
[^ППТСР
У. Блэк
Интернет: протоколы безопасности. Учебный курс
Перевели с английского С. Нефедьев, А. Солоницына
Главный редактор
Заведующий редакцией
Руководитель проекта
Литературный редактор
Корректоры
Художник
Верстка
В. Усманов
Е. Строганова
А. Васильев
А. Шуксто
А. Морозова, И. Смирнова
Н. Биржаков
Л. Чернышова
ББК 32.988-07я7
УДК 681.324(075)
Блэк У.
Б70 Интернет: протоколы безопасности. Учебный курс. — СПб.: Питер, 2001. — 288 с.: ил.
ISBN 5-318-00002-9
Эта книга посвящена описанию проблем безопасности обмена информацией и обеспечивающих се
протоколов передачи данных. В связи с тем, что понятие безопасности в Интернете трактуется очень
широко, основное внимание уделено протоколам передачи данных, применяемым для обмена данными
между узлами — такими как, например, маршрутизаторы и серверы. Дри этом рассматривается большин-
ство используемых в настоящее время протоколов.
Книга предназначена для широкого круга читателей, не являющихся специалистами в данной
области При этом, однако, предполагается, что читатель знаком с архитектурой Интернета и структурой
протокола TCP/IP.
Original English language Edition Copyright © 2000 by Uyless Black
© Перевод на русский язык, С Нефедьев, А. Солоницына, 2001
© Издательский дом «Питер», 2001
Права на издание получены по соглашению с Prentice Hall, Inc.
Все права защищены. Никакая часть данной книги не может быть воспроизведена в какой бы то ни быпо форме без письменного
разрешения владельцев авторских прав.
Информация, содержащаяся в данной книге, получена из источников, рассматриваемых издательством как надежные. Тем не
менее, имея в виду возможные человеческие или технические ошибки, издательство не может гарантировать абсолютную
точность и полноту приводимых сведений и не несет ответственность за возможные ошибки, связанные с использованием книги.
ISBN 5-318-00002-9
ISBN 0-13-014249-2 (англ.)
ЗАО «Питер Бук». 196105, Санкт-Петербург, ул. Благодатная, 67.
Лицензия ИД №01940 от05.06.00.
Налоговая льгота - общероссийский классификатор продукции ОК 005-93, том 2; 953000 - книги и брошюры.
Подписано в печать 23.05.01. Формат 70* 100‘/16. Усл. п. л. 23,22. Тираж 6000 экз. Заказ № 720.
Отпечатано с готовых диапозитивов в ФГУП «Печатный двор» им. А. М. Горького Министерства РФ
по делам печати, телерадиовещания и средств массовых коммуникаций.
197110, Санкт-Петербург, Чкаловский пр., 15.
Краткое содержание
Предисловие..............................................14
Глава 1. Введение.......................................16
Глава 2. Возможные нарушения безопасности...............29
Глава 3. Основные концепции безопасности................38
Глава 4. Брандмауэры ...................................71
Глава 5. Распространенные методы защиты данных в Интернете.83
Глава 6. PPP, ECP, TLS, ЕАР, DESE-bis и 3DESE..........101
Глава 7. Протоколы коммутируемых соединений •
PAP, CHAP, RADIUS и DIAMETER............................118
Глава 8. Архитектура IPSec.............................143
Глава 9. IPSec: протоколы АН и ESP.....................162
Глава 10. Распространение, сертификация
и управление ключами в Интернете........................186
Глава 11. Обмен ключами.................................215
Глава 12. Безопасность беспроводных сетей...............232
Глава 13. Дополнение к этой книге.......................250
Приложение А. Исходные коды наиболее важных
функций защиты..........................................253
Приложение Б. Трансляция сетевых адресов (NAT)..........271
Сокращения..............................................275
Алфавитный указатель.................................. 279
Содержание
Предисловие....................................................................14
Благодарности .............................................................. 14
От издательства............................................................ 15
Глава 1. Введение..............................................................16
Проблемы безопасности...................................................... 16
Насколько распространены попытки взлома систем безопасности?............... 17
Меры безопасности.......................................................... 18
Что такое брандмауэр?...................................................... 20
Политика безопасности...................................................... 20
Внутренние и внешние сети (Trusted and Untrusted Networks)............... 20
Безопасность и управление риском........................................... 21
Виртуальные частные сети (Virtual Private Network — VPN)................... 21
Современные виртуальные частные сети (VPN)............................... 22
Виртуальные частные сети и соглашения о качестве предоставляемых услуг
(Service Level Agreement — SLA)......................................... 25
Конфиденциальность или исполнение закона?.................................. 26
Глава 2. Возможные нарушения безопасности......................................29
Типы проблем в обеспечении безопасности.................................... 29
Отказ в обслуживании: атаки и контратаки....................................29
Вирус...................................................................... 30
Червь.................................................................... 30
Закупорка или затопление............................................... 31
Троянский конь............................................................ 31
Бомба.......................................................................32
Лазейка.................................................................... 33
Салями..................................................................... 33
Повторение................................................................. 33
Cookies.................................................................... 34
Апплеты и песочницы.......................~................................ 36
Другие проблемы............................................................ 37
Заключение................................................................. 37
Содержание 7
Глава 3. Основные концепции безопасности.....................................38
Защищена ли защищаемая информация?.......................................... 38
Определения..................................................................39
Шифрование и дешифрование................................................39
Основные методы шифрования и дешифрования....................................40
Немецкая шифровальная машина «Энигма»....................................41
Подстановка и перестановка...................................................42
Односторонние функции и арифметика в остаточных классах......................43
Пример односторонней функции.............................................44
Идеи Диффи—Хеллмана, использующие арифметику в остаточных классах........44
Хэш-функция..................................................................45
Использование односторонней хэш-функции ..................... .............
Произвольность ключей........................................................47
Недостаток произвольности равен взлому шифра.................................48
Ключевая проблема: обмен ключами.............................................49
Неудобство обмена ключами............................................... 50
Асимметричный ключ...........................................................51
Использование асимметричных ключей для дешифровки ...........................51
Асимметричные ключи: шифрование............................................. 52
Асимметричные ключи: идентификация (цифровая подпись)....................... 53
Следующий шаг: RSA.......................................................... 54
Пары ключей RSA......................................................... 55
Генерация и передача ключей................................................. 56
Код подтверждения подлинности сообщения и хэширование ключей.................57
Совмещение функций безопасности..............................................58
Поль Циммерман и PGP (Pretty Good Privacy — достаточно хорошая секретность). 61
PGP с использованием сертификатов ключей................................ 61
Пример открытого ключа PGP.............................................. 61
OpenPGP................................................................. 62
Совершенная прямая секретность (Perfect Forward Secrecy — PFS).............. 63
Атака типа «человек посередине»..............................................64
Сертификация.................................................................65
Процедура сертификации.......................................................66
Меры против атак типа «повтор».............................................. 67
Безопасность в мобильных сетях...............................................68
Идентификация........................................................... 68
Операции секретности.................................................... 69
Заключение.................................................................. 70
Глава 4. Брандмауэры.........................................................71
Что такое брандмауэр?....................................................... 71
Защита от внешних (untrusted) сетей..........„.......................... 71
Разрешительный и запретительный доступы......................................72
Что могут делать брандмауэры и что они не могут делать.......................73
Фильтрация пакетов...........................................................74
8
Содержание
Прокси-брандмауэры или брандмауэры приложений............................... 75
Документы National computer Security Association (NCSA)..................... 77
Управление брандмауэром (Managed Firewall Service — MFWS)................... 78
Оценка поставщика услуг MFWS.............................................. 79
Брандмауэры с протоколами безопасности Интернета
(Internet Security Protocols — IPSec)....................................80
SOCKS..................................................................... 81
Заключение.................................................................. 82
Глава 5. Распространенные методы защиты данных в Интернете....................83
Диффи—Хеллман............................................................... 84
Диффи— Хеллман и RFC 2631................................................. 85
Ривест, Шамир и Адлеман (RSA)............................................... 87
RSA в RFC 2437 ........................................................... 87
MD5......................................................................... 88
Подвержен ли MD5 атакам?.................................................. 90
RFC 2537: RSA, MD5 и DNS.................................................... 91
Открытые ключи RSA и DNS.................................................. 91
Подписи RSA/MD5 в DNS..................................................... 92
Соображения по поводу эффективности....................................... 92
Стандарт защищенного хэширования (SHA-1) и алгоритм защищенного хэширования. 92
RIPEMD-160 ................................................................. 93
Сравнение MD5, SHA-1, RIPEMD-160 и MD5-HMAC................................. 93
НМАС........................................................................ 94
Производительность и надежность НМАС........................................ 95
НМАС и IPSec................................................................ 96
Протокол определения ключей OAKLEY.......................................... 97
За пределами Диффи—Хеллмана и STS......................................... 98
Обмен ключей в протоколе OAKLEY........................................... 98
Наиболее важные поля сообщения обмена ключей.............................. 99
Заключение..................................................................100
Глава б. PPP, ECP, TLS, ЕАР, DESE-bis и 3DESE..................................101
РРР и HDLC..................................................................101
LCP ........................................................................103
Примеры использования протокола РРР.........................................104
Фазовая диаграмма РРР.......................................................105
Нет связи (нет физического соединения)....................................105
Фаза установления связи...................................................105
Фаза идентификации........................................................105
Фаза протокола сетевого уровня............................................106
Фаза завершения соединения................................................106
Пакеты LCP..................................................................106
Запрос-Конфигурации....................~..................................107
Подтверждение-Конфигурации................................................107
Отказ-Конфигурации........................................................108
Ошибка-Конфигурации.......................................................108
Содержание
9
Запрос-Завершения и Подтверждение-Завершения.................................108
Отказ-Кода...................................................................108
Отказ-Протокола..............................................................108
Эхо-Запрос и Эхо-Ответ.......................................................109
Отвергнуть-Запрос............................................................109
Другие вспомогательные протоколы обеспечения безопасности в РРР................109
Протокол обеспечения безопасности на уровне передачи данных
(Transport Layer Security Protocol — TLS) ...............................109
Предназначение TLS...........................................................110
PPP-протокол управления шифрацией (PPP Encryption Control
Protocol — ECP) .........................................................110
Расширяемый PPP-протокол идентификации (PPP Extensible
AUTHentication Protocol— EAP)............................................Ill
PPP-протокол шифрования DES, версия 2 (PPP DES Encryption Protocol,
Version 2 — DESE-bis)....................................................113
Настройка конфигурации в ECP.................................................113
Формат пакета DESE...........................................................114
PPP-протокол тройной DES-шифрации (PPP Triple-DES Encryption Protocol — 3DESE).114
Алгоритм.....................................................................115
Ключи........................................................................115
Настройка конфигурации 3DESE в ЕСР...........................................116
Формат пакета 3DESE..........................................................116
Заключение ....................................................................117
Глава 7. Протоколы коммутируемых соединений
PAP, CHAP, RADIUS и DIAMETER......................................................118
PAP и CHAP................................................................., 118
PAP............................................................................119
Ключевые аспекты PAP....................................................... 119
CHAP...........................................................................120
Сообщения CHAP...............................................................121
RADIUS.........................................................................122
Настройка RADIUS............................................................. 123
Пример обмена сообщениями в RADIUS.............................................124
Польза UDP...................................................................125
Формат сообщения RADIUS......................................................125
Атрибуты RADIUS..............................................................126
Пример обмена данными с RADIUS...............................................128
Проблемы RADIUS..............................................................130
DIAMETER.......................................................................130
Формат сообщения DIAMETER......................................................130
Заголовок сообщения..........................................................130
Тело сообщения (AVP) ........................................................131
AVP DIAMETER-команда........................w................................132
Команда Отказ-Сообщения-Инд................................................ 133
Как устроены остальные сообщения.............................................133
Базовые операции...............................................................136
10
Содержание
Использование DIAMETER для соединения с SS7 по коммутируемым линиям........137
Обмен сообщениями при установке сеанса Сигнальный
шлюз/НА$-контроллер (SGNC)...............................................138
Пример обмена сообщениями................................................139
Заключение.................................................................142
Глава 8. Архитектура IPS.ec...................................................143
Основы IPSec...............................................................143
Возможности IPSec........................................................144
IPSec-протоколы защиты передачи данных...................................144
Базы данных ассоциаций безопасности (SA).................................144
Туннель IPSec............................................................144
Ассоциация безопасности (SA)...............................................145
Случаи ассоциаций безопасности: обзор......................................146
Типы SA: транспортный режим и туннельный режим ..........................148
Комбинирование ассоциаций безопасности: более подробно.....................150
Местоположение IPSec.......................................................152
Базы данных IPSec..........................................................153
Селекторы и базы данных SAD/SPD............................................153
IP-адрес Получателя......................................................154
IP-адрес Отправителя ....................................................154
Имя......................................................................154
Протокол транспортного уровня............................................155
Порты Отправителя и Получателя ..........................................155
Селекторы и записи в SAD/SPD.............................................155
Поиск SA в SAD...........................................................156
Примеры посылки и получения данных в IPSec.................................157
Выбор и использование SA или пакета SA.....................................160
Заключение.................................................................161
Глава 9. IPSec: протоколы АН и ESP............................................162
Предназначение протоколов IPSec............................................162
Значение проверки сохранности (Integrity Check Value — ICV) ...............163
Взаимоотношения между протоколами АН и ESP и транспортным
и туннельным режимами....................................................164
Управление изменяемыми полями............................................164
Что защищается в пакетах АН и ESP..........................................166
Защита АН................................................................166
Что и как делает АН........................................................167
RFC 1826.................................................................168
RFC 2402...................................v.............................168
Значение проверки сохранности (Integrity Check Value — ICV) для исходящих пакетов.169
Значение проверки сохранности (Integrity Check Value — ICV) для входящих пакетов..170
Содержание
11
Что и как делает ESP........................................................170
Защита ESP................................................................170
RFC 1827................................................................. 172
RFC 2406................................................................. 173
Обработка исходящих пакетов...............................................174
Обработка входящих пакетов................................................174
АН и ESP и «случаи»....................................................... 175
IP-адресация в заголовках...................................................178
Создание пакета ESP.........................................................179
Создание заголовка для туннельного режима...................................181
Применение НМАС в АН и ESP .................................................182
MD5-HMAC-96 ..............................................................183
HMAC-SHA-1-96.............................................................183
IPSec и NAT............................................................... 184
Заключение..................................................................185
Глава 10. Распространение, сертификация
и управление ключами в Интернете...............................................186
Что такое инфраструктура открытого ключа?...................................186
Сертификаты и центры сертификации (СА) .....................................187
Поддержка принятия (non-repudiation) .....................................188
Сохранение и восстановление ключей........................................188
Использование двух пар ключей.............................................189
Обновление ключей и управление их архивом.................................189
Хранилище сертификатов и распространение сертификатов.....................189
Взаимная сертификация.....................................................190
ISAKMP, область интерпретации ISAKMP и IKE..................................190
ISAKMP......................................................................191
«Защитная оболочка»....................................................... 191
Другие соображения по поводу обмена ключами...............................192
Фазы согласования в ISAKMP..................................................192
Сообщения.................................................................194
Общий заголовок...........................................................196
Атрибуты данных...........................................................196
Возможные типы передаваемых данных........................................196
OAKLEY и ISAKMP.............................................................205
Примеры согласований ISAKMP.................................................206
Базовый обмен ............................................................206
Обмен с защитой конфиденциальности........................................207
Обмен идентификации.......................................................208
Агрессивный обмен.........................................................209
Область интерпретации (DOI) ISAKMP............„.............................209
Данные, передаваемые IPSec/ISAKMP...........................................210
Заключение..................................................................214
12
Содержание
Глава 11. Обмен ключами......................................................215
Основы IKE ...............................................................215
Определения.............................................................. 216
Совершенная прямая секретность............................................217
Аспекты IKE и ISAKMP......................................................217
Режимы установления идентифицированного обмена ключей.....................218
Основной режим......................................................... 218
Агрессивный режим ......................................................218
Быстрый режим и режим новой группы........................219
Четыре метода, используемых в основном и агрессивном режимах............219
Примеры обмена сообщенями IKE.............................................220
Фаза 1: обмен идентифицирован при помощи цифровой подписи...............220
Фаза 1: обмен идентифицирован при помощи шифрации с открытым ключом.....222
Фаза 1: обмен идентифицирован при помощи исправленной шифрации
с открытым ключом.......................................................223
Фаза 1: обмен идентифицирован при помощи разделяемого секретного кода...224
Фаза 2: Быстрый режим...................................................224
Режим новой группы......................................................225
Информационный обмен ISAKMP.............................................225
Группы AKLEY..............................................................225
Все сообщения при обмене IKE .............................................226
Фаза 2 с применением быстрого режима....................................227
IPSec, NAT и IKE..........................................................229
Примеры реализаций PKI....................................................230
Заключение................................................................231
Глава 12. Безопасность беспроводных сетей....................................232
Спецификация IS-41-C......................................................232
Модель IS-41-C............................................................232
Пять операций безопасности/конфиденциальности.............................234
Параметры идентификации ................................................234
Процедуры идентификации регистрации передвижного устройства ..............236
Параметры...............................................................236
В беспроводном интерфейсе...............................................237
В сети..................................................................237
Процедуры уникального вызова/ответа.......................................238
Параметры...............................................................238
В беспроводном интерфейсе...............................................239
В сети..................................................................240
Идентификация звонка от передвижного устройства...........................242
Параметры............................................................. 242
В беспроводном интерфейсе.....:....................................... 242
В сети..................................................................243
Содержание
13
Идентификация звонка на передвижное устройство......................244
Параметры.........................................................244
В беспроводном интерфейсе ........................................245
В сети............................................................245
Обновление разделяемых секретных данных (SSD).......................246
Параметры.........................................................246
В беспроводном интерфейсе'и в сети................................247
Заключение..........................................................249
Глава 13. Дополнение к этой книге......................................250
Рабочие документы ..................................................251
RFC................................................................ 252
Приложение А. Исходные коды наиболее важных
функций защиты.......................................................253
Исправленный алгоритм MD5 (RFC 1321, Appendix А, автор Рон Ривест)..254
Исправленный алгоритм MD5 (RFC 1321, Section 3.4, автор Рон Ривест).266
НМАС; Идентификация сообщения при помощи хэширования (RFC 2104, Appendix,
авторы: Хьюго Кравчик, Михир Беллар и Ран Канетти).................267
Создание и извлечение зашифрованного текста в RFC 1969: РРР-протокол
шифрования DES (DESE-bis) (авторы: Кейт Склоуер и Джерри М. Мейер).270
Приложение Б. Трансляция сетевых адресов (NAT)....................271
Сокращения.............................................................275
Алфавитный указатель...................................................279
Предисловие
В этой книге говорится о проблемах безопасности обмена информацией в сети
Интернет, а также о протоколах передачи данных, применяемых для обеспечения
такой безопасности.
В связи с тем что понятие безопасности в Интернете очень широко, в этой книге основ-
ное внимагп те уделяется протоколам передачи данных, применяемым д ля обми га да] пня-
ми между узлами Интернета, такими как маршрутизаторы, серверы и т. д.
Цель этой книги - объяснить читателю суть термина «безопасность в сети Интер-
нет». Книга предназначена для широкого круга читателей, не являющихся специалис-
тами в данной области. При этом, однако, предполагается, что читатель знаком с ар-
хитектурой Интернета и структурой протокола TCP/IP.
Я надеюсь, что вы сочтете эту книгу ценным дополнением вашей библиотеки.
Благодарности
Во многих случаях при объяснении того, как обеспечить безопасность в Интернете,
я ссылаюсь на Request for Comments - RFC и черновые варианты стандартов, опубли-
кованные Сообществом Интернета. Следует поблагодарить эту организацию за публи-
кацию этих материалов. Черновые варианты стандартов сейчас находятся в процессе
разработки и, следовательно, могут быть изменены перед тем, как они станут очеред-
ным документом RFC (если они вообще станут таким документом). И хотя эти стан-
дарты еще не завершены, многие производители уже используют их при разработке
коммерческих продуктов.
От издательства
15
Как для всех действующих стандартов, так и для черновых вариантов стандартов вер-
но следующее:
© Разработано Сообществом Интернета (1998). Все права защищены.
Эти документы и их переводы могут копироваться, передаваться и использоваться в
других работах, которые комментируют данные документы и облегчают их понима-
ние. Такие работы могут подготавливаться к выпуску, копироваться, публиковаться и
распространяться без каких-либо ограничений при условии указания авторских прав,
как это и сделано выше. Однако эти документы не могут подвергаться никаким изме-
нениям, таким как удаление ссылок на авторские права или ссылок на Сообщество Ин-
тернета и другие организации. Это условие должно обязательно соблюдаться во всех
случаях, кроме тех, которые связаны с продолжением разработки стандартов, а в этих
случаях следует придерживаться процедур, указанных в Стандартах Интернета, а так-
же правил перевода документов на язык, отличный от английского.
Эти ограничения действуют постоянно и не будут изменены Сообществом Интернета
или его правопреемниками.
От издательства
Редакция выражает благодарность Сергею Валентиновичу Беззатееву за консульта-
ции в работе над этой книгой.
Ваши замечания, предложения, вопросы отправляйте по адресу электронной почты
comp@piter.com (издательство «Питер», компьютерная редакция).
Мы будем рады узнать ваше мнение!
Исходные тексты, приведенные в приложении А, вы можете найти по адресу
http://www.piter.com/download.
На Web-сайте издательства http://www.piter.com вы найдете подробную информацию
о наших книгах.
g ГЛАВА Введение
В этой главе излагается суть проблем обеспечения безопасности в Интернете
и возможные пути их решения или уменьшения степени риска, связанного
с ними. Разъясняются такие термины, как «политика безопасности» и «управление
риском». Вводится понятие Виртуальной Частной Сети (Virtual Private Network —
VPN). Завершается глава обсуждением проблемы анонимности в Интернет-со-
общсствс.
Проблемы безопасности
С момента появления компьютеров и компьютерных сетей существует неболь-
шая прослойка людей, стремящаяся продемонстрировать свои интеллектуаль-
ные возможности, вмешиваясь в работу компьютерных сетей и систем Иногда
люди, проводящие эти атаки, имеют своей целью получить финансовую выгоду
или отомстить за ущерб, который был им нанесен (как реальный, так и вообра-
жаемый).
Суть этих атак состоит в разработке способов повреждения информационных
систем.
И хотя это может звучать патетично, люди, занимающиеся подобными атаками,
на самом деле проявляют только свою интеллектуальную несостоятельность. Чаще
всею своим успехом они больше обязаны открытости атакуемой системы, чем чему-
либо еще. Тем не менее, бывают случаи, когда люди, вмешивающиеся в систему,
демонстрируют развитый интеллект и глубокие знания технологий связи и ком-
пьютерных операционных систем. Но, как это зачастую и случается, они сами
впоследствии могут стать жертвами атак своих «коллег».
Насколько распространены попытки взлома систем безопасности?
17
Насколько распространены попытки
взлома систем безопасности?
Невозможно определить, как часто системы безопасности подвергаются атакам
и насколько часто эти атаки достигают цели. Бреши, имеющиеся в вашей системе
безопасности, никому не известны. Разумеется, большинство компаний ие раз-
глашают информацию о своих проблемах в области безопасности, так как, со-
гласно весьма распространенному мнению, это может сделать их уязвимыми
для последующих атак (не говоря уж о недовольстве держателей акций).
Многие из вас сталкивались с какими-либо пробелами в системе безопасности
вашего компьютера или компьютера вашей компании. Иногда эти проблемы лишь
слегка раздражают вас, иногда они даже забавны. В других случаях они опасны,
так как могут повлечь за собой потерю программ и данных, зачастую являющихся
результатом многих часов работы.
Чтобы оценить масштаб данной проблемы, в ФБР была создана специальная
организация, занимающаяся безопасностью компьютерных сетей. Эта организа-
ция. расположенная в Сан-Франциско, сообщила, что в 1998 г. 60% компаний
из Fortune 1000 (это список 1000 наиболее богатых компаний) сообщили о своих
проблемах в системах безопасности, что означает возможность успешного взло-
ма этих систем. Скорее всего, эти компании были подвергнуты атакам хакеров
[ZIMI98]1 ФБР также сообщает, что в тех случаях, когда потери были вызваны
кражей данных изнутри системы (так называемым доверенным лицом), компа-
нии затратили па ликвидацию последствий 2,8 млн долларов! Может показать-
ся, что это очень большая сумма, но следует учесть, что вследствие атаки тысячи
сотрудников, деловых партнеров и клиентов могут лишиться доступа к ресур-
сам сети. Даже если система бездействует всего несколько часов, это может при-
вести к большим убыткам.
Возможные потери и сумма, требуемая для восстановления системы, зависят
от типа атаки. Данные исследований ФБР [ZIMI98] по этому вопросу приве-
дены в табл. 1.1.
Таблица 1.1. Средний ущерб от различных типов атак на системы безопасности
Тип атаки Средний ущерб (в USD)
Воровство данных работниками компании 2 809 000
Кража персональных данных 1 677 000
Мошенничество в области связи 539 000
Мошенничество в области финансов 388 000
Саботаж 86 000
Проникновение в систему извне 86 000
' [Z1MI98J. Zin.its Eiic С, and Montano, Christopher. «Public Key Infrastructure: Unlocking the Internet's
Economic Potential», I story, Volume 3, Issue 2, Апрель, 1998. Дополнительную информацию можно
получить по адресам szmits@hamquist.com и amontano@hamquisf.coTn.
18
Глава 1. Введение
Подразделение компании IBM в городе Хауторн, штат Нью-Йорк, включает в се-
бя антивирусный центр. Система безопасности этого центра подверглась уже
более чем 20 000 нападениям. На данный момент этот центр ежедневно полу-
чает и анализирует от шести до десяти новых вирусов [BUDE99]1.
Ущерб от известного вируса «Melissa» (говорят, что он был так назван автором в
честь одной его знакомой — стриптизерши), нарушившего работу системы элект-
ронной почты в марте 1999 года, оценивается в 80 млн долларов [GOLD99]2.
Дэвид Смит (David Smith), программист, создавший и выпустивший этот ви-
рус в Интернет, был осужден на десять лет тюрьмы. То есть примерно по году
тюрьмы за каждые 8 млн долларов.
В феврале 2000 года некоторые сайты в Интернете подверглись атаке со сторо-
ны человека (я буду называть его хакером), который заваливал серверы большим
объемом данных, в результате чего эти серверы не могли обслуживать своих кли-
ентов. Эти атаки широко обсуждались в прессе — признак того, что проблемы
безопасности стали частью нашей жизни. Подозреваемые были арестованы и на-
ходятся под следствием.
Очевидно то, что безопасность данных в Интернете является большой пробле-
мой. Давайте рассмотрим, какие есть решения этой проблемы.
Меры безопасности
Когда речь заходит о безопасности данных в Интернете, некоторые могут ска-
зать, что под этим понимается шифрование данных. Другие могут закричать:
«Уберите эти cookies подальше от моего компьютера!»
Это, конечно, верно. Но кроме этого, безопасность подразумевает принятие спе-
циальных мер для достижения следующих целей (обобщение этих данных при-
ведено в табл. 1.2)'
О Анонимность/Секретностъ/Конфиденциалъностпь: Уверенность в том, что
данные пользователя недоступны посторонним лицам. Другими словами, уве-
ренность в том, что «никто не читает вашу почту».
О Подлинность (authentication): Уверенность в том, что полученные вами дан-
ные (электронные письма, файлы, Web-страницы и т. д.) пришли из того места,
из которого вы их и ожидали получить. Например, если вы получаете дан-
ные с подписью, вы должны быть уверены в том, что они отправлены имен-
но тем человеком, чья подпись там стоит. Это понятие также известно под
названием «подлинность источника данных» (data origin authentication).
О Целостность данных: Уверенность в том, что данные не были изменены на
пути от отправителя к получателю. Это включает в себя меры, предотвра-
щающие повторное введение в поток данных пакетов с удостоверенной под-
линностью. Это требует использования средств проверки целостности всей
1 [BUDE99J. Buderi, Robert. «The Virus Wars», Scientific American, April, 1999.
2 [GOLD99I. Gold, Geffery. Associated Press Dispatch, December 10, 1999, опубликовано в USA Today.
Меры безопасности
19
последовательности пакетов, когда пакет, не отвечающий определенным пра-
вилам (так называемый жульнический1), будет отвергнут. В IP-сетях это по-
нятие также известно как целостность данных, не зависящая от соединения
(connectionless integrity).
О Контроль доступа: Предотвращение доступа к тому или иному ресурсу лиц,
не имеющих на это прав, а также предотвращение неправильного исполь-
зования ресурса. Также в это понятие включается и предотвращение попы-
ток монопольного использования ресурса или запрещения кем-либо доступа
к ресурсу для остальных пользователей. Монополизация ресурса — это рас-
пространенный вид атак, результатом успешного выполнения которого
является недоступность какого-либо ресурса для остальных пользователей.
О Принятие (non-repudiation): Механизм, гарантирующий невозможность от-
каза от факта получения пли отправления сообщений или данных (напри-
мер, сообщений электронной почты). Это понятие является частью проверки
подлинности данных. Примером такого подхода может быть одна из функ-
ций почтового сервиса Х.400. Получатель электронной почты не может про-
смотреть содержимое сообщения до того, как не подтвердит получение этого
сообщения. Это напоминает заказное письмо — вы не можете просмотреть
содержимое конверта до того, как распишетесь в его получении.
Таблица 1.2. Типы мер безопасности в Интернете
Анонимность/Секретность/Конфиденциальность Уверенность в том, что посторонние лица не просматрива- ют данные
Подлинность Уверенность в том, что данные отправлены именно тем, от чьего имени они получены
Целостность Уверенность в том, что принятые данные не были измене- ны по пути от отправителя к получателю
Контроль доступа Предотвращение доступа к ресурсу без соответствующих полномочий
Принятие (non-repudiation) Механизм, гарантирующий невозможность отказа от фак- та получения или отправления сообщений или данных
Для обеспечения этих мер безопасности используются механизмы, не зависимые
от алгоритмов кодирования/декодирования данных. Поскольку алгоритмы шифрова-
ния меняются довольно часто, было бы глупо включать их в сами протоколы.
Более того, эти меры безопасности не обязательно применяются в каждом слу-
чае. Например, некоему пользователю (скажем, Тэду) все равно, если кто-то про-
чтет его почту, он может заботиться только о том, чтобы получатель письма (на-
пример, Кэрол) была уверена в том, что письмо пришло действительно от Тэда.
Разумеется, Кэрол тоже хочет быть уверенной в подлинности писем. В данном
случае Тэд и Кэрол заинтересованы только в подлинности сообщений, а кон-
фиденциальность их не интересует.
О способах определения того, какие меры безопасности нужны в том или ином
случае, мы поговорим позднее.
1 Жульническим (rogue) пакетом данных называют пакет неизвестного происхождения, обычно
присланный из подозрительного источника или предназначенный для использования в уязвимых для
атак приложениях.
20
Глава 1. Введение
Что такое брандмауэр?
Перед тем как продолжить обсуждение, мы должны коротко рассказать о том,
что такое брандмауэр (подробнее этот вопрос рассмотрен в главе 4). Брандмау-
эром называют систему (часто это маршрутизатор или персональный компью-
тер), используемую для реализации правил контроля доступа к данным внутри
организации или между 'организациями. Брандмауэр позволяет разрешать или
запрещать проходящие через пего потоки данных. Чтобы быть пропущенным
через брандмауэр из одной сети в другую или из одного компьютера в другой,
любой поток данных должен соответствовать правилам безопасности и опреде-
лен в планах контроля доступа организации.
Политика безопасности
Одной из важнейших проблем в организации эффективной системы безопас-
ности является определение тех, кто имеет право получить доступ к данным
компании, и тех, кто пет. Инструменты, которые позволяют реализовать такие
решения (кодирование данных, брандмауэры и т. д.), будут совершенно беспо-
лезны без продуманной политики безопасности. Более того, подобные системы
должны реализовываться как единое целое. Следует учесть, что, например, бу-
дучи использован неправильно, брандмауэр может не только не разрешить име-
ющиеся проблемы, но и создать новые.
Для того чтобы получить представление о сложности этой проблемы, давайте
рассмотрим частную компанию с локальной компьютерной сетью. Время ог вре-
мени сотрудники увольняются и нанимаются, некоторые переключаются с од-
ного проекта па другой. Кроме того, могут происходить такие процессы, как ре-
организация компании, смена владельцев, слияние и т. д. Все эти процессы
сопровождаются циркуляцией потоков информации, часто — конфиденциаль-
ной. Сеть компании должна быть достаточно гибкой для того, чтобы обеспечить
необходимый доступ к ресурсам или данным и, в то же время, быть достаточно
защищенной для предотвращения нежелательного проникновения.
Эта проблема становится еще острее, если организация вынуждена взаимодей-
ствовать с общедоступными сетями, такими как Интернет. Когда новые сети и
домены становятся доступны со стороны Интернета, добавляются новые серверы
или выпускаются новые продукты, перед органпзацией встает проблема их без-
опасной интеграции и обеспечения сотрудникам компании доступа к ним.
Внутренние и внешние сети (Trusted and Untrusted
Networks)
Чтобы построить систему безопасности, организация должна в первую очередь
разработать политику контроля для внутренних и внешних сетей и сетевых ресурсов.
Виртуальные частные сети (Virtual Private Network — VPN)
21
В некоторых организациях считают, что их внутренним сетям (например, ло-
кальным сетям внутри их зданий) можно доверять. При этом считают, что сети
вне организации — внешние (им доверять нельзя). Для изоляции внутренней
сети от внешней используют брандмауэр.
Важно помнить, что и внутренние сети представляют определенную опасность и
должны обеспечивать некоторый уровень защиты. Почему это так — видно из табл. 1.1.
Разумеется, политика безопасности по отношению к внутренним сетям может от-
личаться от политики безопасности по отношению к внешним сетям. Например,
поток данных внутри рабочих групп может обрабатываться по-иному, чем поток
данных между рабочими группами. При этом внешний пользователь не сможет увидеть
этих подробностей благодаря защите брандмауэра. Подробнее эти аспекты систем
безопасности рассматриваются в последующих главах.
Безопасность и управление риском
Устанавливая линию поведения в политике безопасности, организация должна
определить, какие данные или ресурсы важны для нее настолько, чтобы принять
в отношении к ним меры безопасности. Среди таких данных и ресурсов неко-
торые могут быть более ценными с^Ьчки зрения возможных потерь в случае взлома
системы. Например, в системе электронного перевода денег (такой как в Феде-
ральном резервном банке) раскрытие финансовой и к) ррмании может привес-
ти к гораздо большему ущербу, чем раскрытие данных о работнике Более того,
оценка риска и возможного ущерба позволяет находить рейл шя, опгимальные
с точки зрения соотношения затрат и эффективности
11екоторые учреждения предпочит ают проверить эффективность системы безопасности,
подвергнув се испытанию в течение некоторого времени. Этот период разработки,
создания системы и ее тестирования может занять некоторое время. В некоторых
организациях па формулирование плана, его воплощение и проверку уходит боль-
ше года. Если вы приступаете к разработке системы безопасности, учтите, что сто-
ит запастись терпением и разработать план, который в результате позволит постро-
ить согласованную систему безопасности при низких затратах.
Виртуальные частные сети (Virtual Private
Network — VPN)
Этот термин используется уже много лет. Впервые он был применен в 70-х го-
дах в пакетных сетях общего пользования Х.25 для описания сети, доступной
пользователям так же, как телефонная сегь доступна для потребителей. На рис. 1.1
показана схема построения первых VPN-сетей. Идея заключается в том, что эта
сеть обслуживает пользователя таким образом, чтобы у него сложилось впечат-
ление работы с локальной сетью, созданной исключительно для его нужд. На
самом же деле эта сеть обслуживает множество пользователей одновременно.
22
Глава 1. Введение
Ранние сети такого типа не предоставляли большого числа услуг, приспособлен-
ных под нужды клиентов, но, в частности, они были привлекательными из-за того,
что позволяли снизить оплату за междугородние звонки (благодаря использованию
общедоступной сети) и получить экономический выигрыш за счет большого числа
пользователей. Пользователь должен был дозвониться с помощью модема до
устройства доступа, называемого Сборщик/разборщик пакетов — Packet Assembler/
Disassembler (PAD). Это устройство играло роль шлюза в Х.25-сети. PAD был раз-
работан с тем, чтобы поддерживать асинхронные старт-стоп протоколы, так что это
было достаточно простой задачей — соединить пользователя с VPN.
Рис. 1.1. Первоначальная концепция VPN: Х.25-сеть и формирователи пакетов (PAD)
Современные виртуальные частные сети (VPN)
Современные VPN предоставляют те же услуги, что и раньше, но с некоторыми
дополнениями. Новая схема построения такой сети показана на рис. 1.2. Такая
сеть обладает следующими дополнительными свойствами:
О Пользователь не знает, какими средствами организуется соединение (напри-
мер, через Интернет).
О Пользователю предоставляются средства безопасности, включая обеспечение
конфиденциальности и достоверности информации.
О Сотрудники и клиенты организации могул соединиться с несущей сетью и по-
лучить все необходимые настройки автоматически.
О Обычно пользователи дозваниваются до местного сервера и получают через
Интернет доступ к удаленным серверам (например, VPN-сервер на рис. 1.2).
Используя Интернет, пользователь может сократить затраты на междугород-
ние звонки.
Виртуальные частные сети (Virtual Private Network — VPN)
23
О PPP (Point-to-Point Protocol — протокол двухточечного соединения), удален-
ные серверы RADIUS (Remote Authentication Dial-In Service — система уда-
ленной авторизации пользователей по коммутируемым линиям) и IPSec (Internet
Security Protocol — протокол безопасности Интернета) становятся важными
инструментами поддержания такой структуры (зти вопросы обсуждаются ниже).
Здесь следует еще раз подчеркнуть, что пользоваться сетью Интернет для без-
опасной связи между устройствами пользователей значительно дешевле, чем
в случае использования выделенных телефонных линий или других способов.
Более подробно топология VPN представлена на рис. 1.3. Это всего лишь пример,
однако он позволит сделать несколько замечаний по поводу построения VPN.
Интернет выступает в роли несущей сети. Пользователь подключается к интер-
нет-провайдеру, который передает данные на маршрутизаторы Интернета (и на-
оборот). Эти устройства иногда используются как брандмауэры доступа (access
firewall), в этом случае их основная функция заключается в проверке IP-адре-
сов входящих сообщений на подлинность. Эти же компьютеры могут исполь-
зоваться и в качестве серверов VPN. В этом случае они выполняют расшифров-
ку данных, зашифрованных отправителем.
Сервер VPN может также быть расположен за брандмауэром доступа (в данном
случае — маршрутизатором Интернета), при этом он будет являться частью ло-
кальной сети, как показано на рис. 1.3. При такой реализации маршрутизатор
или сервер должен передать данные на сервер VPN для их последующей расшиф-
ровки. Если эти данные — запрос на соединение с системой, то они передаются
на соответствующий сервер для проверки данных пользователя. Часто такой
сервер выполняет и функции автоматической настройки соединения.
24
Глава 1. Введение
На рис. 1.3 показаны несколько узлов сети, некоторые из которых принимают
участие в работе VPN, а другие — нет. Может оказаться более удобным и эффективным
(с точки зрения затрат) совместить функции сервера проверки прав пользователя
и VPN-сервера на одном компьютере, так как функции обеспечения конфи-
денциальности и идентификации могут быть наиболее эффективно реализова-
ны в рамках одной функции (и следовательно, одного компьютера). Таким обра-
зом, пет ничего необычного в размещении функций идентификации, кодирования
потока данных и настройки на входном шлюзе VPN-сети. Из рис. 1.3 также вид-
но, что наиболее важные узлы системы дублируются вспомогательными компыо-
гсрамп.
Пользователи
Маршрутизаторы
доступа к Интернету
Рис. 1.3. Топология виртуальной локальной сети
Где бы пи был расположен VPN-сервер, его основной задачей будет обеспечение
безопасности логических соединений (так называемых IPSec-тупиелей) через
Интернет.
На рис. 1.3 показано, что пользователи могут быть подключены к системе двумя
способами. При первом способе туннели безопасности устанавливаются один раз
Виртуальные частные сети и соглашения о качестве предоставляемых услуг
25
и остаются без изменений. Они организуются между сайтами, которые всегда
находятся па одном и том же месте (например, между отделением компании и ее
штаб-квартирой). Другой способ применяется при работе с отдельными пользо-
вателями, которые могут звонить из разных мест: с мобильных телефонов, из
номеров в гостинице и т. п.
Работе VPN-сетей уделено достойное место в этой книге.
Виртуальные частные сети и соглашения
о качестве предоставляемых услуг
(Service Level Agreement — SLA)
Глобальные сети (Wide Area Network — WAN), предлагающие услуги виртуаль-
ной частной сети, могут располагать возможностями контроля качества предос-
тавляемых услуг (Quality of Service — QOS). Примерами показателей качества
могут служить пропускная способность сети, время ожидания или гарантии со-
хранности потока данных. Суть соглашения о качестве предоставляемых услуг
(Service Level Agreement — SLA) — контракта между потребителем и поставщи-
ком услуг — заключается в установлении обязательств поставщика услуг VPN
перед пол ьзователем
В большой сети могут одновременно осуществляться сотни соединений, прихо-
дящих от многих провайдеров, но коль скоро соглашение подписано, оно должно
соблюдаться.
В общедоступной компьютерной сети предприятие-пользователь часто оплачи-
вает оказанные услуги в соответствии с количеством данных, переданных через
отдельный постоянный виртуальный канал (Permanent Virtual Circuit — PVC).
Для пользователя может оказаться важным знать, сколько стоит отдельный PVC
и каков поток данных через этот PVC. В прошлом программное обеспечение не
могло отслеживать работу каналов передачи данных и предоставлять пользова ге-
лю соответствующую информацию. Сейчас ситуация изменяется и многие раз-
работчики уже предлагают программы, которые позволяют пользователям сле-
дить за выполнением договора.
Па рис. 1.4 показана топология системы, обеспечивающей применение SLA-mo-
пптора. Обладающий расширенными возможностями модуль обслуживания
капала и данных (Channel service unit/Date service unit — CSU/DSU) собирает
данные о производительности системы, наблюдая за потоком данных, проходя-
щим через пего Этими данными пользуются специальные программы, генери-
рующие отчеты согласно следующим показателям: работоспособность, время
ожидания, пропускная способность PVC или физического порта, сбои в потоке
данных, использование порта в единицу времени, а также какой процент зани-
мает тот или иной протокол в общем потоке данных (SNA, IP и другие).
26
Глава 1. Введение
Рис. 1.4. Средства мониторинга
Стоимость CSU/DSU-модуля, обладающего соответствующими возможностя-
ми, колеблется от $1000 до $4000. Приобрести их можно у многих поставщи-
ков - [TAYL98]1 и [JAND99]2.
Конфиденциальность или исполнение
закона?
Дискуссии о том, что важнее: право личности на конфиденциальность информа-
ции или исполнение закона и защита общества от действий некоторых его чле-
нов, ведутся давно. Но с широким распространением компьютеров и появлением
недорогих коммерческих криптографических систем эта проблема предстала в
новом свете. Но хорошей новостью является то обстоятельство, что все больше
людей осознают эту проблему.
Как это ни смешно, те самые криптографические системы, которые позволяют
людям защитить свою личную жизнь, по мнению многих, мешают обществу бо-
роться с преступностью и принимать эффективные меры защиты.
Я понимаю тех людей, которые считают, что органы власти должны иметь право
следить за пользователями Интернета, когда есть для этого законные основа-
ния — когда это необходимо для борьбы с серьезными преступлениями или если
речь идет о национальной безопасности. Во время моей работы в Службе связи
ВМФ США я прошел курс криптографии и позднее работал совместно с
Разведывательным управлением Министерства обороны США, где я был
хранителем документации разведки Агентства национальной безопасности. Тогда
я понял, как важно иметь возможность собирать разведывательную информа-
цию.
1 [TAYL98J. Taylor, Steven and Wexler, Joanie, “Maturing Frame Relay Makes New Demands”, Business
Communications Review. July, 1998.
2 [JAND99], Jander, Mary, “SLA Monitoring Tools”, Data Commutations, February, 1999.
Конфиденциальность или исполнение закона?
27
Тем не менее, я считаю себя «партизаном конфиденциальности», я считаю себя
таковым потому, что право на конфиденциальность является одной из основ сво-
бодного общества. С уважением к личной жизни человека приходит и уважение
к личности. Одно вытекает из другого. Однажды утраченное право очень трудно
вернуть. Уступите немного сначала здесь, потом — там, и начнется...
Пожалуй, в связи с этой проблемой не найти лучшего примера, чем номер социального
страхования США (Social Security Number — SSN). Номера социального стра-
хования вводились дтя того, чтобы можно было хранить данные о программе социального
страхования, и, таким образом, этот номер может использоваться для данных
о зарплате и налоговых записей. В начале 70-х так оно и было. Те, кто имеет
доступ к номерам социального страхования (ревизоры, бухгалтеры), часто рас-
сматривают его как нечто неприкосновенное и не позволяют использовать его
в других целях.
В то время я сделал ошибочное предположение о том, что правительство США
защитит данные о номерах социального страхования и не допустит их использо-
вания в коммерческих целях. Почему этого не произошло? Возможно, оказалось,
что ими можно очень просто и эффективно пользоваться для идентификации
личности, при этом никто не следил за тем, не пользуются ли ими в неблаговид-
ных целях.
Номер социального страхования остается эффективным средством идентифика-
ции личности и сейчас. Несколько лет назад я был оштрафован полицией за пре-
вышение скорости. А спустя всего несколько дней (не месяцев или недель, а дней!)
я получил уведомление от моей страховой компании о том, что мои страховые
взносы увеличились из-за этого случая.
Эффективно? Очень эффективно! Раздражающе? Для меня — да. Раздражает не
столько то, что были повышены страховые взносы, а то, что государственное уч-
реждение поделилось информацией обо мне с коммерческим предприятием (или
продало ее). Такие случаи встречаются все чаще. Конфиденциальность уходит в
прошлое.
Некоторые мои коллеги в области телекоммуникаций говорят: «У тебя есть что
скрывать? Если тебе нечего скрывать, то тебе не о чем беспокоиться». Я в таких
случаях отвечаю: «Мне больше не имеет смысла ничего скрывать из-за чрезмер-
ной эффективности нашего “информационного сообщества”». Так что это вынуж-
денная открытость! Может быть, уже поздно что-либо изменить!
Тем не менее, предполагая, что человек, который знает все о ком-либо другом, не
имеет злых намерений, мои коллеги могут обманывать сами себя. Все ли люди
так доброжелательны друг к другу?
На другом уровне эта проблема имеет подкрепление на уровне ежедневного опыта.
Практически каждый день во время ужина мне звонят различные компании, ко-
торые каким-то образом знают, что я предпочитаю (но им еще предстоит выяс-
нить, когда я ужинаю). Этим они вторгаются в область, что была изначально пред-
назначена для частного использования, — телефон. Мое возражение против
28
Глава 1. Введение
таких звонков одно, но очень важное: существенной частью права на личную
жизнь является право быть оставленным в покое.
Мы могли бы обсуждать эту тему до бесконечности. Я бы хотел завершить эту
эскападу утверждением, что в США понятие личной жизни размыто до пора-
зительных пределов. Более того, те средства, которые используются для «раз-
мытия», по-прежнему здесь и продолжают эксплуатироваться. Одним из таких
средств могут быть названы cookies, которые мы обсудим в следующей главе.
В последнее время появились некоторые обстоятельства, которые внушают опти-
мизм. В США до недавнего момента не хватало национальной дискуссии на эту
гему, дискуссии, в которой принимали бы участие не только специалисты. Эта
дискуссия, скорее всего, заинтересует пассивные слои населения, поскольку Ин-
тернет становится частью жизни многих и многих людей. Я очень надеюсь, что
в результате этот! дискуссии будет выработан компромисс между частными и
общественными интересами.
Эта книга посвящена техническим проблемам и не является социологическим
пли политическим исследованием. Таким образом, мы сфокусируемся па про-
блемах безопасност данных в Интернете и средствах обеспечения такой без-
опасности.
О) ГЛАВА
Возможные нарушения
безопасности
В этой главе обсуждается, какие виды атак могут быть произведены на ваши
данные. Будут рассмотрены такие способы нарушения защиты, как вирусы и
программы-черви. Заканчивается глава обсуждением пользы и вреда cookies.
Типы проблем в обеспечении безопасности
От каких способов нарушения защиты должна защищаться организация? Боль-
шинство проблем в обеспечении безопасности связаны с такими известными
терминами, как вирус, программа-червь и т. д. В этой части книги дается обзор
этих проблем.
Отказ в обслуживании: атаки и контратаки
Атаки на сеть, принадлежащие к некоторым из видов, описываемых в этой час-
ти книги, ведут к отказу в обслуживании пользователям атакуемого сетевого
ресурса. Сетевой ресурс может быть выведен из строя троянским программным
кодом или перегружен в том случае, когда хакер посылает на атакуемый ком-
пьютер огромное количество запросов. Эта проблема называется атакой типа «отказ
в обслуживании» (denial of service). Сервис становится недоступным для остальных
пользователей ресурса.
Контрдействия состоят в принятии превентивных мер. При этом система отка-
зывает атакующему в доступе к сервису посредством, например, проверки адре-
сов входящих пакетов данных и отбрасывания пакетов с подозрительными адресами.
Это называется контратакой «отказ в обслуживании», поскольку в этом случае
сервис становится недоступным для атакующего.
30
Глава 2. Возможные нарушения безопасности
Вирус
Обычно вирус — это фрагмент кода, который копирует себя в программу и ак-
тивизируется при ее выполнении. Впоследствии он может инфицировать и другие
программы, но это может произойти не сразу. Вирус может не проявляться до тех
пор, пока не произойдет некоторое событие, например наступление какой-нибудь
даты, удаление из базы данных определенного имени и т. д. Он может модифици-
ровать и другие программы. На рис. 2.1 показано, как работает вирус.
Результаты действий компьютерного вируса могут быть просто слегка раздра-
жающими, такими как выполнение большого количества избыточного кода, что
приводит к понижению производительности системы. Но вирус может произво-
дить и существенные разрушения. Надо заметить, что некоторые специалисты
определяют вирус как программу, которая вызывает потерю или порчу данных
или программ.
Программа-вирус
Программа-вирус
Что-то делает
Что-то записывает
Что-то удаляет
Что-то делает
Что-то записывает
Что-то удаляет
Программа-вирус
Выполняет операции
Записывает
Читает и т. д.
Рис. 2.1. Схема работы вируса
Обнаружение вируса в системе может быть весьма трудной задачей. Вирус может
даже в какой-то момент самоликвидироваться. Другими словами, он может
выполниться и затем уничтожить себя.
Червь
Червя иногда путают с вирусом (рис. 2.2). Они имеют общие черты, так как и червь
является кодом. Однако червь — это независимая программа, которая не моди-
фицирует другие программы, а воспроизводит сама себя, что приводит к сниже-
нию производительности, а то и полной остановке компьютера или целой сети.
Название «червь» появилось, в частности, благодаря двум исследователям из
Троянский конь
31
PARC — John Schoch и Jon Hupp, описавшим червя как программный код,
существующий на компьютере. Программа-червь может разделиться (создав копию
самой себя) с тем, чтобы заразить компьютеры, соединенные с данным*. Ее можно
сравнить с отрезанными частями живого червя, которые могут выжить сами по себе.
Программа-червь
Программа-червь
Делает что хочет,
но не ломает
Делает что хочет,
но не ломает
Программа-червь
Делает что хочет,
но не ломает
Программа-червь
Делает что хочет,
но не ломает
Рис. 2.2. Схема работы червя
Закупорка или затопление
Закупорка или затопление (flogging or flooding) является разновидностью про-
граммы-червя, которая вызывает пересылку большого объема ненужной инфор-
мации на узел, такой как сервер или маршрутизатор. В результате принимаю-
щий компьютер перегружается и не может обслуживать своих пользователей из-за
перегрузки своих вычислительных ресурсов. Очевидно, это подходит под описа-
ние атаки «отказ в обслуживании», данное выше.
Троянский конь
Троянский конь — это также программный код, причем программа-червь или
вирус могут быть классифицированы как троянский конь. Своим названием он
обязан тому факту, что он прячется внутри другой программы. Это напоминает
историю о том, как древнегреческие солдаты проникли в город Троя внутри
деревянного коня, а потом открыли ворота своим товарищам.
‘John Е Shoch and Jon A. Hupp. «The Worm Programs — Early Experience with a Distributed Computation»,
Communications of the ACM, Vol, 25, Number 3. Кроме того, Deborah Russel and G. T. Gangemi Sr. [RUSS91]
также рассказывает нам интересную историю возникновениялирусов и червей. Обратите внимание
на книгу тех же авторов Computer Security Basics, O’Reilly & Associates, Inc. 1991. Я использую их
классификацию видов компьютерных атак.
32 ‘ Глава 2. Возможные нарушения безопасности
На рис. 2.3 показана ситуация, где фрагмент кода спрятан внутри программы
входа в систему. Когда пользователь подключается к такой системе, его паро-
ли перехватываются и становятся доступными для «солдата» внутри этого троянского
коня. Перехватив имя и пароль пользователя, хакер может получить доступ к
его ресурсам. Троянский конь может оказаться незамеченным, так как после
сбора необходимой информации он покидает систему, не оставляя никаких следов.
Рис. 2.3. Троянский конь
Бомба
Бомба — это еще один вид угрозы системе безопасности. Она может принимать
форму троянского коня и производить такие же разрушения, как вирус или червь.
Бомба характерна тем, что приводится в действие часовым или логическим
«взрывателем». Уместно вспомнить одну из разновидностей бомб, «взрывате-
лем» для которой служит дата: после того как проходит некоторый срок, бомба
не позволяет выполняться программе, в которой она находится. Другой пример
непреднамеренной бомбы — проблема 2000 года, которая разрешилась с его
наступлением.
Логический «взрыватель» основан на том, что бомба реагирует на событие, происходящее
в ходе нормальной работы программного обеспечения. В качестве примера опять
можно назвать удаление записи из базы данных. Например, служащего уволь-
няют и его данные удаляются из базы данных персонала. Предположим, быв-
ший служащий был программистом и имел дело с программой для работы с данными
о персонале. Поэтому рассерженный программист разрушает программу, кото-
рую он создал1. «Взрывателем» является подпрограмма, которая, обнаружив отсутствие
записи о данном программисте-злодее, инициирует действия, направленные на
повреждение системы.
1 В начале своей карьеры я был соучредителем консультационной фирмы в области телекоммуникаций.
Один из моих коллег написал код для нашей бухгалтерии. После того как компания была перепродана,
бомбы были помещены в этот код. С тех пор я стараюсь делать сам наиболее чувствительные части
программ или каким-либо образом удостовериться, что чужой код не подвергнет меня опасности.
Поговорка «Доверяй/но проверяй» уместна и в области систем безопасности данных.
Повторение
33
Лазейка
Лазейка — это механизм, посредством которого можно пробраться в систему.
Источник такой возможности кроется в ошибках в организации системы без-
опасности. Однако, эта «дверь» может быть сознательно включена в текст про-
граммы самим программистом. Я, например, нахожу, что такие лазейки доста-
точно удобны, потому что они давали мне доступ в программное обеспечение,
которое стало коммерческим продуктом, но все же в особых случаях требовало
моего вмешательства. В определенных приложениях доступ к лазейкам может
быть запрещен после того, как система становится коммерческим продуктом*.
Для обеспечения большей безопасности хорошей практикой является удаление
лазеек из программы, как только она отлажена и сдается заказчику. Если лазейки
необходимо сохранить (что происходит нередко), то вход через них должен быть
сильно затруднен. Один из методов состоит в том, что для преднамеренного или
непреднамеренного доступа к лазейке требуется, чтобы вход производился через
другую, более скрытую лазейку, требующую, например, знания пароля. Надо заметить,
что обеспечить безопасность в случае лазеек очень непросто, так как исходный
код может попасть в чужие руки со всеми вытекающими последствиями.
Салями
Еще один способ нарушения защиты заслуживает нашего внимания. Он назы-
вается салями; автор столкнулся с ним во время работы в качестве программи-
ста в банковской сфере. Пакость эта заключается в небольшом изменении цифр
в файле (это небольшое изменение, в конце концов, становится большим кус-
ком салями). Примером могут служить округление вверх или вниз десятичных
дробей в банковском счете или небольшое увеличение числа в инвентаризаци-
онной системе для искажения количества товара на складе.
Повторение
Повторение (replay) — это активная атака на сетевой ресурс, она вызывает пере-
хват данных, модифицирование их (не обязательно) и дальнейшую их пересыл-
ку. Пример повторения — это посылка изменений в базу данных более чем один
раз, когда предполагается, что такое изменение должно иметь место только один
1 На одной из моих работ я был ведущим программистом проекта Федерального резервного банка США,
в котором разрабатывалась система симуляции обращения денег, которая использовалась Комитетом
Свободного Рынка этого банка. Разумеется, вся эта система, как и ее база данных, были засекречены,
поскольку выдаваемая ею информация использовалась для определения количества денег, которое нужно
напечатать или уничтожить. Внесенная мною в систему лазейка позволяла быстро проникнуть в нее,
что, поскольку все разрабатывалось в сжатые сроки, а члены комитета постоянно требовали внесения
различных исправлений, было очень полезно. Замечание для ФБР: я удалил эту лазейку, когда покинул
проект.
34
Глава 2. Возможные нарушения безопасности
раз. Такая транзакция в случае, к примеру, накопительного счета в банке может
быть даже повторена без изменений, но конечный результат — это нарушение
точности накопительного счета в пользу того, кто совершает атаку, и убыток
держателю накопительного счета. Атака повторением может использоваться вместе
с атакой салями.
Cookies
Эта часть главы описывает cookies и связанные с ними проблемы. Частично
это описание взято из статьи [SCHO99]', которую я бы порекомендовал вам
прочитать целиком.
Cookies — это небольшой объем данных, посылаемый с web-сервера для сохра-
нения на локальной машине с тем, чтобы они потом могли быть считаны. Это
позволяет экономить время, сохраняя информацию о соединениях данного сер-
вера с данным клиентом.
Но, кроме того, это также позволяет системе, которая использует cookies, сохра-
нять информацию о пользователе, что в основном и вызывает споры. Cookies
ограничены в правах доступа к компьютеру пользователя, поэтому они не счита-
ются опасными с точки зрения порчи программ или данных. Это утверждение,
разумеется, справедливо только на данный момент, завтра все может измениться.
Интернет построен на очень простом принципе. Все материалы в Сети имеют
общий формат — HTML (HyperText Markup Language — язык разметки гипер-
текста), и все запросы и ответы делаются в соответствии со стандартным прото-
колом HTTP (Hypertext Transfer Protocol — протокол передачи гипертекстовых
файлов). Эти стандарты стали настолько популярны и всеобъемлющи, что дру-
гие технологии адаптируются для использования HTML и HTTP для того, что-
бы легко интегрироваться в Сеть. HTTP используется для передачи информа-
ции между web-сайтами и клиентами, новые технологии, такие как 1Р-телефония
(VoIP), используют HTML и HTTP.
Cookies генерируются web-сервером и сохраняются в компьютере пользователя,
уже готовые к дальнейшему использованию. Cookies помещаются в поток данных
HTML/HTTP, циркулирующий между компьютером пользователя и web-сервером.
В большинстве случаев не только сохранение персональной информации в cookies,
но и доступ к ним происходят незаметно. Когда пользователь устанавливает со-
единение с web-сервером, тот автоматически получает доступ (обычно в форме
web-запроса) к соответствующим cookies.
Использование cookies происходит в два приема. На первой стадии cookies со-
храняются на компьютере пользователя. Например, пользователь может выбрать
интересующие его темы на web-странице Му Yahoo!, настраиваемой поисковой ма-
шине. Затем web-сервер создает соответствующее cookie, которое по сути являет-
ся строкой отформатированного особым образом текста, содержащей описание
1 [SCHO99] http://www.wvjolt.wvu.edu/wvjolt/current/issue1/article, статья под авторством Mayer-
Schonberger.
Cookies 35
настроек пользователя, и передает это cookie на компьютер пользователя. Web-броузер
пользователя, если он настроен соответствующим образом, получает это cookie
и сохраняет его в специальном файле, называемом списком cookies. Отметим еще
раз, что эти операции происходят без уведомления пользователя или получения
его согласия. В результате, персональная информация (в данном случае, темы,
интересующие пользователя) собирается на web-сервере, затем передается и со-
храняется на компьютере пользователя.
На второй стадии использования cookies они автоматически передаются через
HTTP с компьютера пользователя на web-сервер без уведомления пользовате-
ля. Всякий раз, когда пользовательский web-броузер отображает определенную
web-страницу с сервера, броузер будет без какого-либо извещения пользовате-
ля передавать на этот сервер соответствующее cookie, содержащее персональ-
ную информацию.
Например, когда вы вводите свой идентификатор и пароль, скажем, для досту-
па к вашему биржевому счету, cookie сохраняет данные о вашей манере исполь-
зования данного сайта, например какие виды отчетов вы получали. Или другой
пример: допустим, вы не хотите, чтобы на какой-нибудь web-странице вас бес-
покоили прогнозом погоды или чем-то подобным. В этом случае cookies могут
быть использованы для фильтрации того, что вы хотите видеть, а что нет. Cookie
может храниться очень долго, и, если вы заходите на сайт после длительного
перерыва, то этот сайт все еще может получить информацию о вас (например,
инг)юрмацию о кредите), позволяя избежать нудной работы по введению такой
информации заново.
Все это выгодно как для клиентов, так и для web-серверов. Однако в таком спо-
собе сбора информации есть и свои «но». Принцип работы cookies позволяет ис-
пользовать их для отслеживания мест в Интернете, посещаемых пользователем,
а некоторые люди (в том числе и я) считают это вторжением в личную жизнь.
Конечно, хороший анализатор протоколов может шпионить за вами через IP-
адреса и имена доменов, но при использовании cookies отслеживание ваших
действий в Интернете значительно упрощается.
[СООКОО]1 дает следующие инструкции для избавления от cookies.
Если вы хотите запретить использование cookies, то это можно сделать, если у
вас установлен Netscape версии 3.0 или выше. Войдите в меню Options. Выбе-
рите пункт меню Network Preferences. В появившемся окне выберите Protocols.
Выберите раздел Show an alert before. Установите флажок Accepting a cookie. С этого
момента каждый раз, когда сервер попытается сохранить cookie, вы будете пре-
дупреждены. Окно Alert сообщит вам, что это за cookie и насколько долго оно
просуществует до того, как будет удалено.
В табл. 2.1 приводятся инструкции по установке поддержки вставок в броузере.
Запретить их использование вы можете, выполнив обратные операции.
1 [СООКОО]. Вы можете найти на Web-сайте hUp//www.cookiecentral.com очень полезную информацию
о cookies.
36
Глава 2. Возможные нарушения безопасности
Таблица 2.1. Установки, разрешающие использование cookies _________________________________________
Для разрешения использования cookies в Netscape Navigator 3.x:
• Щелкните на пункте меню Options и выберите Network/Preferences
• Установите флажок Accepting cookies
Для разрешения использования вставок в Netscape Navigator 4.x:
• Щелкните на пункте меню Edit и выберите Preferences/Advanced
• Щелкните на переключателе Accept all cookies
• Снимите флажок с пункта Warn me before accepting a cookie, если хотите отменить предупреждение
о сохранении cookies
Для разрешения использования вставок в Internet Explorer 3.x:
• Щелкните на пункте меню View и выберите Options/Advanced
• Если хотите, снимите флажок с пункта Warn me before selecting a cookie
• Нажмите кнопку OK
Для разрешения использования вставок в Internet Explorer 4.x:
• Щелкните на пункте меню View и выберите Options/AdvanCed
• Выберите Accept all cookies
• Нажмите кнопку ОК
Для разрешения использования вставок в Internet Explorer 5.x:
• Щелкните на пункте меню Tools и выберите Internet Options/Security
• Щелкните на Custom Level
• Выберите Enable в обоих элементах, касающихся cookies
• Нажмите кнопку ОК
Апплеты и песочницы
В течение последних нескольких лет Java стала популярным языком программи-
рования, который используется во многих Интернет-приложениях. Этот язык часто
выбирают для написания маленьких программ, называемых апплетами. Апплеты
предназначены для загрузки на компьютер пользователя с другого компьютера,
например сервера. Эта операция предоставляет возможности для нарушений
безопасности системы. Компьютерный хулиган может написать апплет, который
будет вмешиваться в работу компьютера, разрушать файлы и программы.
Для борьбы с этой ситуацией Suh Microsystems разработала программный про-
дукт, называемый Java Virtual Machine. Любой апплет, который запускается на машине,
будет исполняться этой программой. Когда^апплет загружен, вначале он не об-
ладает правами доступа к жизненно важным ресурсам компьютера, таким как
жесткие диски, /цзайьсры устройств и т. д. Эта часть операции известна как «песочница»
Заключение
37
(sandbox) Java. Это напоминает ребенка, которого посадили в песочницу: с одной
стероны, он находится в безопасности, с другой стороны, ничего не портит вне
песочницы.
Апплету разрешается выходить из «песочницы» и получать доступ к ресурсам
компьютера только в том случае, если известно, что апплет пришел из известного
и надежного источника.
Виртуальная машина Java встроена в броузер пользователя и исполняет апплет
в защищенном участке памяти, ограничивая доступ к ресурсам.
Виртуальная машина выполняет две основные функции: во-первых, она проверя-
ет код апплета для того, чтобы убедиться, что код не содержит ошибок, во-вто-
рых, она проверяет цифровую подпись, сопровождающую апплет, которая опре-
деляет источник программы и отсутствие несанкционированных изменений кода.
Если апплет благополучно прошел эти проверки, ему разрешается доступ к ре-
сурсам компьютера (например, жестким дискам). Кроме того, виртуальная машина
определяет, какие права доступа будут предоставлены апплету; возможно, она разрешит
ему выполнять только определенные действия.
Если же апплет эти проверки не прошел, ему все же разрешается выполнять какие-
нибудь действия, в зависимости от того, насколько они безопасны, но в любом слу-
чае он должен сидеть в «песочнице».
Другие проблемы
Существуют и другие проблемы безопасности, и многие из них являются вариан-
тами тех типов, которые были нами рассмотрены. Многие коммерческие программные
продукты снабжены средствами зашиты от злоумышленников. Но есть и те, ко-
торые таких средств не имеют. В целях безопасности следует ознакомиться с осо-
бенностями любой программы, которая используется на компьютере, существен-
ном для работы компании. Если вы не имеете системы обеспечения безопасности
и соединены с Интернетом, проникновение в вашу систему — это только вопрос
времени, и весьма вероятно, что последствия будут плачевными.
Заключение
Целью атак в компьютерной сети является отказ в обслуживании для пользова-
телей того или иного ресурса, например программы, данных или даже самого
компьютера. Большинство атак имеют вид вируса или червя, как вариант — троянского
коня. Cookies уделяется повышенное внимание из-за их потенциальной возможности
подвергать риску конфиденциальность пользователя, но они не могут быть ис-
пользованы для взлома пользовательских компьютеров.
:ф ГЛАВА
Основные концепции
безопасности
В этой части книги рассказывается о методах защиты информации, передавае-
мой по каналам связи. Для начала даются определения основных терминов,
а затем мы коротко поговорим о ранних методах шифровки и дешифровки. Объяс-
няются операции с индивидуальными и открытыми ключами, а также хэш-фун-
кции. Уделяется внимание цифровым подписям, дается несколько примеров
операций проверки конфиденциальности и идентификации. На одном из этих
примеров демонстрируется, как сотовая сеть идентифицирует владельца мобиль-
ного телефона, а затем — как шифруется и дешифруется поток данных с такого
телефона. Также приводятся сведения из истории некоторых из этих операций.
Если вы имеете опыт работы с операциями обеспечения безопасности, такими
как хэш-функции, односторонние функции, открытые и сеансовые ключи, вам
нет необходимости читать эту главу. Если же такого опыта у вас нет, вам следует
ознакомиться с этими темами, иначе вам будет труднее понять материал, кото-
рый будет изложен в дальнейшем. Например, вам будет тяжело понять наши
рассуждения о протоколах обмена ключами, о которых пойдет речь в последую-
щих главах, еЪли не будете иметь представления об открытых (асимметричных)
ключах.
Защищена ли защищаемая информация?
Важная информация, такая как «защищенная» библиотека программного обес-
печения, «защищенное» сообщение или «защищенная» база данных, может быть
защищена против одних форм атак и уязвима для других. Уровень безопасности
системы зависит от того, какие меры приняты для обеспечения безопасности
системы. Нет такого понятия, как полностью защищенная система, так как при-
нятые в системе операции по обеспечению безопасности могут быть слишком
упрощенными. Система может быть подвержена риску из-за человеческих сла-
бостей и бюрократических ошибок. И действительно, газеты каждый день пуб-
ликуют статьи о нарушении безопасности вследствие ошибок, которые допуска-
ются людьми.
Определения
39
Несмотря на возможность человеческих ошибок, система все-таки может быть
защищенной по вычислениям. Этот термин подразумевает, что к защищаемой
информации (программные продукты, сообщения или база данных) может быть
применен настолько сложный метод шифрования, что становится невозможным
постороннему человеку, не знающему соответствующего пароля, расшифровать
эти данные, даже при использовании высокоскоростных компьютеров. По край-
ней мере, это невозможно сделать за осмысленное время.
Кроме того, из этой главы вы узнаете, что для обеспечения безопасности системы
можно использовать несколько методов одновременно. Например, один метод для
идентификации пользователей, а другой — для защиты потока данных.
Определения
Перед тем как перейти к изложению материала данной главы, следует дать не-
сколько определений. Для начала эти определения будут иметь общий характер,
просто для того, чтобы ввести читателя в курс дела. Позднее будут даны более
подробные разъяснения.
Шифрование и дешифрование
Первый термин — «шифрование». Он подразумевает под собой изменение син-
таксиса сообщения (открытого текста) для того, чтобы сделать его непонятным
для случайного наблюдателя, который воспримет его как случайный набор сим-
волов. Эти измененные данные часто называют шифровкой. Дешифрование —
это процесс, обратный шифрованию. Он подразумевает изменение зашифрован-
ного текста таким образом, чтобы вернуться к начальному, понятному тексту, то
есть обратно к открытому тексту.
Шифрование и дешифрование производятся одним из двух методов, а часто их
комбинацией. Первый метод известен под тремя названиями: секретный, сим-
метричный или обычный. Независимо от названия, в этом методе используется
один и тот же ключ для шифрования и дешифрования. Этот ключ засекречен и
известен и отправителю, и получателю сообщения, поэтому он называется об-
щим секретным ключом (shared secret key). Отправитель использует этот ключ
для преобразования открытого текста в зашифрованный текст, а получатель ис-
пользует тот же самый ключ для дешифрования этой шифровки в исходный текст.
Второй метод известен под двумя названиями: открытый или асимметричный.
В этом методе используются два различных ключа (в действительности, два на-
бора ключей): один из них используется для шифрования, а другой — для де-
шифрования. Один из ключей называется открытым ключом, другой — индиви-
дуальным ключом. Ниже мы обсудим эти ключи более подробно.
Еще один термин, который требуется ввести, — .это цифровая подпись. Она ис-
пользуется в процедуре идентификации, которая предназначена для проверки того
факта, что сторона, которая предположительно послала сообщение, действительно
40
Глава 3. Основные концепции безопасности
является его отправителем. Б дальнейшем мы покажем, как методы шифрова-
ния открытым ключом используются в цифровой подписи.
Наконец, введем термин хэш, хэш-функция, хэш-код или дайджест сообщения
(Message Digest — MD). Это операция, возвращающая величину фиксированной
длины после выполнения обработки сообщения любой длины. После соответ-
ствующего шифрования этот метод может использоваться для подтверждения
личности отправителя.
Давайте рассмотрим эти операции более подробно.
Основные методы шифрования
и дешифрования
Шифрование и дешифрование производятся путем перестановки/изменения
открытого текста в соответствии с определенным алгоритмом (криптографиче-
ской функцией) в шифровку. Эта функция имеет два входных параметра: откры-
тый текст и специальная величина, называемая ключом.
Криптографическая функция может быть доступна любому, то есть она не обя-
зательно является секретом. Ключ же не должен быть общедоступен. Если кто-
то имеет ключ и знает криптографическую функцию, то он может легко дешиф-
ровать зашифрованный текст. Так что такое название очень удачно — вам нужен
«ключ», который открывает «сундук шифровки» для того, чтобы узнать, что
внутри.
Впервые я столкнулся с секретным ключом много лет назад в аптеке. Я был зна-
ком с ее владельцем. Разглядывая товары на полках, я увидел, что на каждой
упаковке есть набор символов под ценой товара, например, $4.95/RSM.
Это был подстановочный шифр, и владелец аптеки пользовался им для того, чтобы
помнить цену, которую он платил за лекарство. Он сказал мне, что такая практи-
ка очень полезна при продаже витаминов (товар, который приносил ему наиболь-
ший доход), благодаря этому он легко ориентировался, насколько он может сни-
зить продажную цену. Кстати, кто-нибудь может догадаться, какой у этой системы
шифрования был ключ? Для правильного ответа посмотрите сноску внизу стра-
ницы1.
Приведем еще один пример простых операций шифрования и дешифрования.
Ключом является 26-знаковый ключ (не стоит пользоваться им для перевода ва-
ших денег в Женеву, но поговорим об этом позднее). Ключ (в данном примере
это шифровальный алфавит) связан с 26-буквенным алфавитом следующим об-
разом (для примера я просто переставил буквы в обратном порядке).
Ключ: ZYXWVUTSRQPONMLKJIHGFEDCBA
Алфавит: abcdefghijklmnopqrstuvwxyz
1 Шифровальной системой аптекаря было слово PHARMOCIST, где каждая буква этого слова соответ-
ствовала цифре 1, 2, 3 ..0
Основные методы шифрования и дешифрования
41
Так же как и мой друг-аптекарь, любой может сделать из открытого текста за-
шифрованный, если воспользуется этой системой как ключом.
Примером использования этой системы может служить шифрование фразы «Show
me the money!» («Покажите деньги!»). Если вы не имеете шифровального клю-
ча, вы увидите вместо этой простой фразы следующий набор символов (в дан-
ном примере восклицательный знак не кодируется, а пробел опускается):
HSLDNVGSVNLMVB!
Другим примером простого (и древнего) метода шифрования может служить
метод, известный как сдвиговый шифр Цезаря, иначе — шифр Цезаря. Он обя-
зан своему названию тому, что впервые был использован во времена Юлия Це-
заря. В приведенном примере буквы алфавита сдвигаются на пять позиций:
Алфавит: abcdefghi jkl mnopqrstuvwxyz
Шифр: FGHIJKLMNOPQRSTUVWXYZABCDE
Приведенные примеры показывают, до чего же много шифров можно изобрести.
В простом примере, когда сдвиг ограничен пятью позициями, для того чтобы
расшифровать текст, достаточно просто найти этот сдвиг. Однако если буквы
алфавита располагать не в алфавитном порядке, то тогда существует более
400 000 000 000 000 000 000 000 000 возможных способов расположения букв
[SING99]1. Человеку, пытающемуся разгадать этот шифр, предстоит проделать,
прямо скажем, немалую работу.
Основой процесса дешифровки являются или знание «шифровального алфави-
та», который является ключом в этом примере, или возможность перепробовать
все различные комбинации ключей, применяя их к зашифрованному тексту и
проверяя, имеет ли результат какой-нибудь смысл. Из этого следует, что чем
больше набор возможных вариантов ключей, тем сложнее задача подбора пра-
вильного ключа, то есть выше вычислительная устойчивость.
Из сказанного становится понятно, почему наши Интернет-провайдеры, финан-
совые компании и пр. советуют пользоваться паролями с большим количеством
цифр. Пароль является частью ключа шифрования (а иногда и всем ключом
шифрования), а ключ с малым количеством вариаций не является «прочным»
ключом. В этом контексте термин «прочный» соответствует системе безопасно-
сти, которую трудно взломать.
Немецкая шифровальная машина «Энигма»
В качестве другого примера рассмотрим созданную в 1930-х годах знаменитую
шифровальную машину «Энигма», которой пользовались немцы во время Вто-
рой мировой войны. Машина была рассчитана на ввод данных с клавиатуры. Каж-
дый раз, когда нажималась клавиша, цилиндрическое колесо передвигалось на
одну из своих 26 позиций, и таким образом образовывалась новая последователь-
ность для каждой введенной буквы. После 26 нажатий клавиш среднее колесо
1 [SING99] Singh, Simon. The Code Book, Fourth Estate Limited, 6 Salem Road, London, W24BU, 1999.
Несомненно, это одна из лучших книг о криптографии.
42 Глава 3. Основные концепции безопасности
поворачивалось на одну позицию, а еще после 26 нажатий клавиш третье, и пос-
леднее, колесо поворачивалось на одну позицию. Конструкция машины предпо-
лагала 60 вариантов размещения колес. Всего для каждого колеса было 17 576
вариантов положений. Если при этом использовался коммутатор, то можно было
произвести 150 000 000 000 000 изменений последовательности. Общее число
возможных положений в «Энигме» равнялось 159 000 000 000 000 000 000
[SMIT98]1.
Немцы пребывали в уверенности, что их система неуязвима, остальные в тече-
ние какого-то времени считали так же. Однако излишняя уверенность в безопас-
ности системы часто чревата неприятными последствиями. Плохой метод шиф-
рования хуже, чем отсутствие такового. Немцы думали, что, поскольку «Энигма»
никогда не допускала, чтобы исходная буква была представлена одним и тем же
кодом, дешифровщики просто никогда не наберут достаточного количества ин-
формации об их системе.
В то время (до войны) казалось, что большое количество установок колес для
«Энигмы» делает ее неуязвимой. Тем не менее, в начале войны англичане рас-
крыли систему «Энигмы» благодаря талантливо проведенным разведывательным
операциям, а также благодаря грубым ошибкам немцев. Обратите внимание на
эту историю в параграфе главы, озаглавленном «Случайность ключей».
Подстановка и перестановка
Как уже говорилось, приведенные выше примеры известны как криптографиче-
ская подстановка, которая получила такое название, потому что определенная
величина заменяется другой определенной величиной. В противоположность
этому перестановка заключается в том, что буквы в сообщении переставляются
местами. И так же как и с подстановкой, способ перестановки должен быть изве-
стен и отправителю, и получателю. Очень старый пример такой перестановки —
это перестановка типа «изгородь», когда сообщение записывается в две линии,
первая буква вверху, вторая внизу и т. д. Для получения зашифрованного сооб-
щения к концу набора символов из верхней линии дописывается набор симво-
лов из нижней линии. Пример (мы взяли его из книги Singh):
THY SECRET IS THY PRISONER: IF THOU LET. IT GO. THOU ART A PRISONER TO IT
TYERTSHPIOEI TOLTTOHURARSNROT
HSCE I TYRSNRFHUEIGTOATPIOE T I
TYERTSHPIOEITOLTTOHURARSNROTHSCEITYRSNRFHUEIGTOATPIOETI
' [SMIT98] Smith, Michael. Station X, The Codebreakers of Bletchley Park, Channel 4 Books of Macmillan
Publishers, Ltd., London, 1998. Это ецк одна прекрасная книга, рассказывающая о разведывательных
операциях англичан во время Второй мировой войны.
Односторонние функции и арифметика в остаточных классах
43
Односторонние функции и арифметика
в остаточных классах
Многие из современных систем безопасности, использующие асимметричные/
открытые операции, основаны на односторонних функциях. Односторонняя
функция — это функция, которая легко выполняется в одном направлении (лег-
ко выполняет прямую операцию), но для которой очень трудно выполнить об-
ратную операцию. Примером двухсторонней функции является произведение в
степень, ведь легко вычислить 23 - 8 и так же легко вычислить V8-2. В боль-
шинстве ранних криптографических систем использовались такие двухсторон-
ние функции: и прямая, и обратная операции выполнялись легко.
Современные системы безопасности используют преимущества односторонних
функций, применяя при этом арифметику в остаточных классах. Скорее всего,
вы уже пользовались такого рода арифметикой в своей работе с компьютерами.
Даже если вы не знаете, что это такое, вы, скорее всего, работали с системами,
в которых применяется этот арифметический подход.
Поскольку арифметика в остаточных классах используется при создании одно-
сторонних функций, она находит свое применение в шифровальных алгоритмах.
Посмотрим на рис. 3.1 (я взял его из примера протокола передачи данных, в ко-
тором использовался алгоритм, называемый некоторыми часовой арифметикой
или циклическим счетчиком). На круге нанесено 8 цифр, от 0 до 7. Этот пример
называется «деление по модулю 8» (или mod 8). Давайте предположим, что мы
хотим вычислить 2+1. Начиная с 2, мы смещаемся на одну позицию к 3, что яв-
ляется ответом задачи и в обычной, и в арифметике в остаточных классах. А теперь
давайте вычислим 2+8. В обычной арифметике ответом является 10, но в mod 8
ответ будет равен 2, что и записывается как 2+8-2 (mod 8). Это работает так, как
будто вы вращаете стрелку «настенных часов».
Как мы можем видеть из функции mod 8, ответ задачи интуитивно не ясен. Может
быть, это слишком простой пример; давайте рассмотрим пример сравнения меж-
ду обычной арифметикой и арифметикой в остаточных классах [SING99]. Рас-
смотрим функцию 3х при х-2. Ответ будет 32=,3?3=9. Если мы возьмем х-3 и
т. д., то чем больше будет х, тем больше будет результат. Таким образом, доволь-
но просто выполнить обратную операцию и найти х. Пока значения х достаточ-
но малы, мы даже помним все ответы или можем легко вычислить, что при 3Х-243
значение х равно 5.
Но рассмотрим функцию 3х-1 (по модулю 7, или mod 7). В этом примере я ис-
пользую другой mod. Теперь выполнить обратную операцию и найти х достаточно
сложно. Другими словами, использование арифметики в остаточных классах дает
возможность строить односторонние функции. Кстати, правильный ответ — 6.
Кто-то может, конечно, утверждать, что высокоскоростной процессор может спра-
виться с этой задачей благодаря своей способности проверить много вариантов
возможных ответов за очень короткое время. Но" проблема в том, что поведение
44
Глава 3. Основные концепции безопасности
функций в такой арифметике очень переменчиво. В табл. 3.1 показан простой
пример того, насколько противоречиво поведение арифметики в остаточных
классах.
Таблица 3.1. Сравнение обычной арифметики и арифметики в остаточных классах [SING99]
X 1 2 3 4 5 б
3* 3 8 27 81 243 729
3* mod 7 3 *2 6 4 5 1
Функцию 543х (mod 21 997) легко вычислить, если х задан. Но если дано, напри-
мер, 5 787 и требуется найти х, то за осмысленное время получить решение не-
возможно, даже если будут использованы сверхбыстрые компьютеры. Еще на-
гляднее это можно продемонстрировать на примерах других алгоритмов, которые
будут рассмотрены в главе 5.
Рис. 3.1. Арифметика в остаточных классах
Пример односторонней функции
Примером односторонней функции может служить дискретный логарифм:
• gx-y (mod р)
Требуется найти х при заданном g, у и р, где р — это большое простое число.
Этот пример представлен здесь для того, чтобы показать, что проблема односто-
ронних функций и простых чисел гораздо шире, чем кажется на первый взгляд.
Идеи Диффи—Хеллмана, использующие арифметику
в остаточных классах
В главе 5 дано описание RFC 2362, стандарта Интернета, реализующего идеи,
обсуждаемые в этой части главы. В той же~главе приводится краткая история
того, как Винфилд Диффи (Winfield Diffie) и Мартин Хеллман (Martin Hellman)
Хэш-функция
45
пришли к этим революционным представлениям о ключах. Большинство этих
соображений основаны на арифметике в остаточных классах. Идея, описывае-
мая в следующем параграфе, была предложена Хеллманом.
В основе идеи Хеллмана лежит функция У* (mod Р). Как и всегда, имеются два
участника процесса, например Алиса и Боб, которые договариваются, какие ве-
личины Р и Y использовать для их операций шифровки. Как мы скоро увидим в
этой главе, а также в главе 5,. формула Хеллмана создала основу для решения
одной из наиболее неподатливых проблем в индустрии безопасности — обмена
ключами между Алисой и Бобом без личной встречи или использования канала
безопасной коммуникации.
Однако я забежал вперед. Сначала мы должны обратиться к подробному описа-
нию определений, данных в начале этой главы. Затем мы вернемся к теме клю-
чей и их обмена.
Хэш-функция
В этой части главы приводится более подробная информация о кодировании и
вычислительных механизмах обеспечения безопасности. Мы начнем с основного
и наиболее важного процесса, называемого хэшем или хэш-функцией. Эта функ-
ция преобразует информацию пользователя (например, пакет) в так называемый
дайджест, также известный как цифровой «отпечаток пальца» или дайджест со-
общения (message digest — MD). Она иногда называется цифровой подписью, по-
тому что может быть использована для обнаружения подделки документа
Действие хэш-функции описано ниже и показано на рис. 3.2. На рис. 3.2, а и 3.2, б
показано, что одни и те же данные на входе функции дают один и тот же резуль-
тат. На рис. 3.2, в показано, что, в свою очередь, разная входная информация дает
разный результат.
Текст сообщения преобразуется в двоичную форму и разбивается на блоки оди-
накового размера. Затем эти блоки вводятся в шифровальный алгоритм, кото-
рый выдает значение, называемое дайджестом или хэшем. Надо иметь в виду,
что дайджест основан на вычислениях, проведенных на основании исходного
текста сообщения.
Для большинства хэш-операций, используемых в настоящее время, дайджест
имеет постоянный размер вне зависимости от длины исходного сообщения. Обыч-
но создается хэш-код длиной 128 бит, часто представляемый как строка из 32
шестнадцатеричных цифр.
Работу хэш-функции можно объяснить на примере функции, используемой в
финансовой индустрии (для наглядности упрощенной) [WRIX92]1. Предполо-
жим, что нечто, представленное числом 4392072, должно быть защищено от из-
менения. На сайте, отправляющем сообщение, все цифры этого числа перемно-
жаются по очереди (кроме 0 и последней цифры). Первая цифра произведения
опускается. Вычисления производятся следующим образом:
' (WR1X92] Wrixon, Fred В. Codes, Ciphers, and Other Cryptic and Clandestine Communication. Black Dog
& Leventhal Publishers, 1992, New York. У Риксона имеется много интересных примеров кодов и шиф-
ров, изобретенных как профессионалами, так и любителями.
46
Глава 3. Основные концепции безопасности
Сообщение пользователя Двоичное преобразование 128-битное число
"Много лет назад я работал i мясорубкой. * Никогда не думал, что так все обернется" I _ L 1010100001 В 1010001000 | F 10000010Ю 1010101000 н I 60а4еЬ51 В c7639f21 Г 7453еаЬс 6dfe491a
* а. Основная операция Сообщение пользователя Двоичное преобразование 128-битное число
"Много лет назад я работал мясорубкой. Всегда знал, что этим все и кончится" . 0010101001 I 5a49231b к 348cfe22 * 6ad48732 8737ed2a
7 1U1UUU1U1U 0110101010
Сообщение пользователя Двоичное преобразование 128-битное число
"Несколько лет
назад я работал
мясорубкой.
Никогда не думал,
что так все
1010111001
0011101000
1000001010
0010111001
458edcb2
a4bae001
49823еЬ4
24edac56
обернется'
б. Разные тексты всегда приводят к различным значениям хэш-кода
Сообщение пользователя Двоичное преобразование 128-битное число
"Много лет назад
я работал ।
мясорубкой. I
Никогда не думал,
что так все
обернется"
1010100001 кююооюоо | Г1000001010 । 1010101000
60а4еЬ51
C7639f21
7453eabc
6dfe491a
в. Одинаковые тексты всегда приводят к одинаковым значениям хэш-кода
Рис. 3.2. Пример хэш-функции
Операция Результат
Умножить 4 на 3 12
Отбросить первую цифру 2
Умножить 2 на следующую цифру (9) 18
Отбросить первую цифру 8
Умножить 8 на 2 16
Отбросить первую цифру 6
Пропустить 0 6
Умножить 6 на 7 ~ 42
Отбросить первую цифру 2
Произвольность ключей
47
Значение хэша (в этом простом примере оно называется контрольной цифрой)
равно 2. При приеме производятся такие же вычисления, и если результат хэш-
функции совпадает с контрольной цифрой, то это означает, что данные не были
изменены.
Конечно, здесь приведен простой пример, чтобы операция была более понятной.
Более сложный пример такой функции, называемой Message Digest 5, приведен
в приложении А.
Использование односторонней
хэш-функции
Алгоритм вычисления хэша организован таким образом, что у двух разных сооб-
щений значения хэша совпасть не могут (по крайней мере, в рамках разумных
статистических границ). Этот факт означает, что невозможно создать сообщение
с таким же хэшем, как у другого (отличного от него) сообщения при любом ра-
зумном количестве вычислений.
Благодаря этой операции дайджест может служить «отпечатком пальца* сооб-
щения [ZIMM98]*. Кроме того, хэш-функция может использоваться для обнару-
жения подделки документа. Следовательно, это инструмент для реализации двух
аспектов безопасности: идентификации отправителя и сохранности документов.
Примеры хэширования и дайджестов сообщений приведены в этой главе ниже.
Произвольность ключей
Один из методов, которыми пользуются дешифровщики для взлома системы
шифрования, — это изучение ключей с целью определения, имеют ли они повто-
ряющиеся атрибуты; то есть являются ли их величины непроизвольными. На-
пример, пятизначный ключ обязательно повторяется, если его применить для
шифровки сообщений. Если дешифровщик сможет определить длину ключа,
зашифрованный текст будет выглядеть, как повтор пяти шифровальных симво-
лов. Проблемы с ключами для шифровки/дешифровки возникают, если ключ
слишком короткий или ключ непроизволен или недостаточно произволен (в этом
случае его называют псевдослучайным).
В идеальном случае нужно, чтобы ключей было достаточно много и они были
достаточно разнообразны, чтобы было из чего выбирать. Простой ключ в нашем
примере на подстановку, приведенном в этой главе, — очень плохой ключ. В сдви-
говом шифре Цезаря имеется от 1 до 25 возможных смещений для создания 25
ключей, и потенциальный противник может легко применить все 25 возможных
ключей к зашифрованному тексту и найти ключ, который расшифрует сообще-
1 [ZIMM98] Zimmerman, Philip R. Cryptography for the Internet, Scientific American, October 1998.
48
Глава 3. Основные концепции безопасности
ние. Однако если буквы алфавита переставлять произвольно, нахождение ключа
• становится невыполнимым с вычислительной точки зрения.
Недостаток произвольности
равен взлому шифра
Вышеупомянутую машину «Энигма» можно привести как пример системы, ко-
торая была успешно взломана, в частности, из-за того, что ее работа была недо-
статочно произвольна. Напомним, что эта немецкая система была последним
словом техники в начале 40-х годов и до какого-то времени никто не мог рас-
шифровать сообщения, зашифрованные с помощью этой машины. Однако ситу-
ация изменилась, когда за эту задачу взялся польский математик и дешифров-
щик Мариан Режевски (Marian Rejewski).
К счастью для союзников, Режевски пробовал расшифровать сообщения «Эниг-
мы» еще в начале 30-х годов, а в те дни немцы не часто меняли порядок распо-
ложения колес «Энигмы», иногда всего раз в три месяца.
Во время войны порядок расположения колес менялся каждый день, но к тому
времени Режевски уже знал о работе «Энигмы» достаточно много. Анализ даже
упростился (относительно) из-за того, что первые шесть букв любого сообще-
ния «Энигмы» задавали положение трех колес «Энигмы», то есть это были на-
стройки для данного сообщения, повторенные дважды. Эта информация позволи-
ла Режевски перепробовать различные комбинации и вывести взаимосвязи в
повторениях и последовательностях кода. В конце концов он построил копию
«Энигмы». Фантастическое достижение! Но возможно, что этой работе также по-
могла вербовка агента, который доставил более 300 документов об этой машине.
Англичане воспользовались этой информацией, а также обнаружили, что во
многих немецких сообщениях попадались части, имеющие один и тот же син-
таксис. Например, многие сообщения начинались с An die Gruppe (Группе такой-
то), а некоторые сообщения из определенных мест содержали только Keine
besondere ereignisse (без перемен). Накопление этой информации привело к поте-
ре произвольности, что является смертью для системы безопасности.
В результате всего этого и, конечно, вследствие замечательного анализа, «Эниг-
ма» потеряла произвольность в выборе ключей и была взломана. Немцы про-
должали думать, что их сообщения защищены. Как только лидеры союзников
убедились в достоверности результатов, полученных дешифровщиками, они ста-
ли активно использовать немецкие сообщения при разработке своих тактических
и стратегических действий и планов. Взлом системы «Энигма» сильно повлиял
на ход войны.
Однако пора закончить эту захватывающую историю и вернуться к теме безо-
пасного обмена ключами. Прекрасное изложение истории «Энигмы» читатель мо-
жет найти в книге Смита [SM1T98].
Ключевая проблема: обмен ключами
49
Ключевая проблема: обмен ключами
Об открытых ключах уже говорилось в этой главе. Такие ключи используются
для дешифровки данных в сетях передачи информации уже достаточно долгое
время. Теория открытого ключа основана на получении двух ключей (в действи-
тельности, наборов ключей) из одной функции. Один ключ называется откры-
тым ключом, а другой ключ называется индивидуальным ключом. Они так на-
званы потому, что открытый ключ может быть известен всем, а индивидуальный
ключ — нет. Этот метод также называется методом асимметричных ключей, что
означает, что для шифровки и дешифровки используются разные ключи.
Идея открытого ключа используется в реализации асимметричного шифра. Да-
вайте рассмотрим некоторые важные аспекты защищенной системы открытого
ключа на примере Алисы и Боба:
О Алиса создает открытый ключ, который она может дать любому (включая
Боба).
О Боб может использовать этот ключ для зашифровки сообщений, посылаемых
Алисе.
О Система генерации ключей Алисы должна быть односторонней функцией, что-
бы никто другой не мог вычислить ключ и расшифровать сообщение, послан-
ное Бобом Алисе.
О Алиса имеет индивидуальный ключ для дешифрования сообщений от Боба,
при помощи которого производится операция, обратная той, которую произ-
вел Боб открытым ключом.
О Оба ключа выведены из одной и той же функции, что, кроме всего прочего,
позволяет Алисе расшифровать сообщение от Боба, используя описанную
ранее функцию Хеллмана, Vх (mod Р), где X — секретный ключ, один для Алисы
и один для Боба.
Это и есть основная идея. Сейчас она кажется достаточно очевидной, но в свое
время она произвела в индустрии безопасности настоящую революцию. Этапы
создания ключей показаны на рис. 3.3, смотрите также [SING99]. На этапе 1 Алиса
и Боб выбирают одни и те же величины для Y и Р. Имеются некоторые правила,
по которым выбираются эти величины, но они будут обсуждены позднее. Для
этого примера важно только отметить, что этими величинами можно обмениваться
открытым способом, даже по телефону. Алиса выбирает величины, и Боб согла-
шается их использовать.
На этапе 2 обе стороны выбирают некоторые величины и хранят их в секрете не
только от других, но и друг от друга. В этом примере это число 3 для Алисы и 6
для Боба. Они обозначены соответственно как А и Б. На следующем этапе 3 Алиса
и Боб используют свои секретные ключи для вычисления соответственно а и б.
На этапе 4 происходит обмен этими величинами. На последнем этапе 5 Алиса и
Боб используют свои секретные ключи и открытие ключи партнера для получе-
ния совместного (секретного) ключа. В этом примере его значение равно 9.
50
Глава 3. Основные концепции безопасности
Эти идеи, схематически показанные на рис. 3.3, оказали большое влияние на
представление о безопасных коммуникациях.
Алиса
Боб
Ф Возьмем У«7 и Р=11 ' .
(2) Выберем величину 3 для А *
ОК®
Выберем величину 6 для Б @
(3) а»7д (mod 11)^2
® Послать а Бобу
® SK>bt (mod 11)=9
Ь=7в (mod 11)=4 ®
Послать б Алисе ®
SK=ae (mod 11)=9 ®
Разделяемый
секретный ключ
Рис. 3.3. Пример использования функции Хеллмана Vх (mod Р) [SING99]
Описанная операция не позволяет создать асимметричный ключ, так как ключ
для обеих сторон один и тот же. Но это первый шаг к асимметричным ключам.
А кроме того, симметричные ключи не так уж и плохи. В частности, их преиму-
щество перед асимметричными ключами состоит в их вычислительной эффек-
тивности (это будет объяснено позднее).
Также отметим, что Алиса и Боб обменялись не своими секретными кодами,
а только результатами mod-функции, что делает достаточно трудным провести
обратную операцию для получения секретного ключа. Таким образом, один из
привлекательных аспектов операций, показанных здесь, заключается в том, что
Алиса и Боб легко могут вычислить а и б, но для хакера достаточно трудно най-
ти соответствующие числа и конечный совместный ключ. В этом и состоит ос-
новная идея, лежащая в основе революционных работ Хеллмана.
Неудобство обмена ключами
Однако, как видно из рис. 3.3, обмен ключами между двумя сторонами достаточ-
но неудобен. Алиса и Боб должны «синхронизироваться» по времени друг с дру-
гом для того, чтобы выбрать ключ. Таким образом, хотя идея Хеллмана и гран-
диозна, она требует доработки. Было бы намного лучше, если бы любая сторона
могла по мере необходимости в любое время найти значения а и б другой сторо-
ны, то есть чтобы они не были должны входить в контакт друг с другом для того,
чтобы обменяться ключами.
Использование асимметричных ключей для дешифровки
51
Асимметричный ключ
Эта проблема была решена Диффи. Соответствующая публикация появилась в
1975 году. Он предложил (так же как и другие, независимо от него) концепцию
асимметричного ключа. Основная идея состоит в том, что две стороны, Алиса и
Боб, независимо друг от друга создают свои пары ключей, один для шифрова-
ния, другой для дешифрования. Эти ключи имеют различные значения, но полу-
чаются они в результате выполнения одной и той же функции.
Из этого следует идея, сейчас уже ставшая общепринятой, что открытые ключи
могут быть доступны любому, возможно в общедоступном списке, например та-
ком, как Х.509. Когда Алиса хочет послать защищенную информацию Бобу, она
просто идет в хранилище информации Х.509, находит там открытый ключ Боба
и использует его для шифрования своего сообщения. Следовательно, стороны
не должны «синхронизироваться» друг с другом, как при использовании алго-
ритма, представленного на рис. 3.3. По сути, они могут послать электронное со-
общение в любое время и для этого им не обязательно входить в контакт друг с
другом. Когда другая сторона соединяется с Интернетом, сохраненное электрон-
ное сообщение может быть расшифровано правильным индивидуальным клю-
чом.
Все это прекрасно, но тем не менее кое-какие проблемы все равно остаются.
Первая проблема: каким образом Алиса и Боб узнают, что их предположительно
правильный открытый ключ действительно правилен? Можно сказать, что это
не имеет значения. Если для шифрования сообщения используется неправиль-
ный открытый ключ, то правильный индивидуальный ключ не сможет его рас-
шифровать. Таким образом, в этом нет особого вреда, но есть определенное не-
удобство. В данном примере это действительно всего лишь неудобство, но эта
ситуация может привести и к серьезным проблемам, которые вскоре будут рас-
смотрены.
Вторая проблема состоит в том, что Диффи высказал основополагающую кон-
цепцию асимметричного ключа, но не было ни примера, ни конкретной реализа-
ции, ни математического доказательства.
Позже в этой главе мы обсудим решения этих проблем. В настоящий момент мы
имеем достаточно информации, чтобы показать, как использовать асимметрич-
ные ключи для обеспечения конфиденциальности информации и идентифика-
ции пользователей.
Использование асимметричных ключей
для дешифровки
Давайте подведем итоги обсуждения концепций,'"представленных выше. Алиса
создает индивидуальный ключ и хранит этот ключ в секрете. Боб делает то же
самое со своим индивидуальным ключом. Идея системы асимметричных клю-
52
Глава 3. Основные концепции безопасности
чей заключается в том, чтобы держать индивидуальный ключ «в кармане жилет- 4
ки» и не раскрывать его содержание никому, кроме создателя и людей, которым
создатель доверяет. Что касается открытого ключа, то он должен соответство-
вать своему названию: быть открытым.
Существуют две операции для асимметричных ключей. При первой операции
общий ключ используется для шифрования, а индивидуальный ключ — для
дешифрования. Но что .произойдет, если обратить процесс? Что, если индивиду-
альный ключ будет использоваться для шифрования, а общий для дешифрова-
ния? Эта операция может служить очень важному назначению: идентификации.
Мы рассмотрим эти операции в следующих двух разделах этой главы, где будет
еще раз продемонстрировано, насколько важны асимметричные ключи.
Асимметричные ключи: шифрование
На рис. 3.4 показано, как асимметричные ключи, используются для шифрования.
Отправитель (например, Алиса) использует открытый ключ получателя (скажем,
Боба) для преобразования открытого текста сообщения в зашифрованный текст.
Получатель проделывает обратную операцию: он (Боб) использует свой инди-
видуальный ключ для преобразования зашифрованного сообщения в открытый
текст. Эта операция обеспечивает конфиденциальность сообщений пользовате-
ля. Хакеру нужно было бы получить доступ к индивидуальному ключу Боба,
чтобы взломать такой секретный код.
Открытый
текст
Открытый
текст
Рис. 3.4. Открытые ключи: шифрование
Асимметричные ключи: идентификация (цифровая подпись)
53
Асимметричные ключи: идентификация
(цифровая подпись)
Кроме поддержания конфиденциальности, открытые ключи широко использу-
ются для процедур идентификации пользователей, как показано на рис. 3.5. Они
также используются для проверки целостности сообщений и подтверждения их
доставки, что обсуждается ниже.
Рис. 3.5. Открытые ключи: идентификация
В приведенном примере отправитель (Алиса) использует свой индивидуальный
ключ для шифрования известной величины в цифровую подпись. Целью цифро-
вой подписи является подтверждение подлинности отправителя. Для этого от-
правитель должен отослать получателю или сделать доступным для него другими
способами свой открытый ключ. Этот ключ применяется (с помощью соответ-
ствующего алгоритма) к пришедшей цифровой подписи. Если операции дешиф-
рования приведут к вычислению известной величины, которая была зашифрова-
на отправителем, то его подлинность может считаться установленной.
Проще говоря, если вычисленная известная величина у получателя совпадает с
ожидаемой величиной, тогда отправитель считается подлинным. Если вычислен-
ная величина отличается от ожидаемой, то отправитель — не тот, за кого он себя
выдает, или во время обработки произошла ошибка. Независимо от причины
сообщение должно быть отвергнуто.
Цифровая подпись во многом похожа на обычную подпись. Для отправителя
сложно ее подделать, а для получателя сложно отказаться ее признать. Однако
идентификация, основанная только на цифровой подписи, порождает ряд про-
блем:
О Действительная цифровая подпись не доказывает, что подписанный документ
тоже действителен. Хакер может перехватить документ и добавить или уда-
54
Глава 3. Основные концепции безопасности
лить часть текста, а получатель будет думать, что человек, который поставил
подпись, подтверждает правильность текста. Эта проблема относится не только
к потоку данных в сети, она также относится к заархивированным докумен-
там, сохраняемым в электронном виде. Понятно, что эта ситуация может со-
здать очень большие проблемы в случае, например, юридических документов,
которые можно изменить в пользу одной из сторон.
О Вычисление хэш-кода для блока данных не обеспечивает подтверждения под-
линности документа 'и подписи, потому что атакующий может изменить до-
кумент и заново вычислить хэш-функцию для измененных данных.
Для того чтобы преодолеть эти трудности, для цифровой подписи используется
односторонняя хэш-функция, преобразующая информацию (например, все со-
общение) в дайджест сообщения. Затем в целях защиты зашифровывается и сам
дайджест сообщения. При таком подходе есть гарантия, что цифровая подпись
соответствует документу, и в этом случае она обеспечивает целостность подпи-
санного документа.
Тем не менее, некоторые проблемы все же остаются. Цифровые подписи и от-
крытые ключи требуют больших вычислений, кроме того, для генерации подпи-
си должен использоваться весь документ. Ниже в этой главе будет показано, как
решаются эти проблемы.
Но сейчас мы опять вернемся к теме асимметричного ключа. Напомним, что
рис. 3.4 и 3.5 иллюстрируют два важных аспекта этого понятия. В следующем
параграфе объясняется, как все это осуществляется на практике.
Следующий шаг: RSA
Чтобы не потерять логическую связь разделов при объяснении концепций безо-
пасности, я уже упоминал некоторые из представлений RSA. В этом параграфе
мы рассмотрим концепции RSA более подробно. RSA — это первые буквы фами-
лий Рона Ривеста (Ron Rivest), Ади Шамира (Adi Shamir) и Лена Адлемана (Len
Adleman), которые возвели идеи Диффи—Хеллмана на следующую ступень: они
создали работоспособную систему асимметричных ключей.
В RSA тоже используется арифметика в остаточных классах, но кроме этого
применяются простые числа (числа, которые делятся без остатка только на себя
и единицу). В алгоритме RSA два простых числа р и q перемножаются и дают N,
которое и играет роль открытого ключа.
Вернемся к Алисе и Бобу. Их вычисленные N могут быть сделаны общедоступ-
ными. Если Алиса хочет послать зашифрованное сообщение Бобу, она использу-
ет N Боба как часть односторонней функции (все математические тонкости вме-
сте с описанием RSA определены В RFC 1321 и объясняются в главе 5 и
приложении А). Результатом является односторонняя функция Боба, которая
используется Алисой для шифрования сообщения Бобу.
Однако такая односторонняя операция не является односторонней для тех, кто
знает р и q. Поэтому Алиса может использовать свои значения р и q для дешиф-
Следующий шаг: RSA
55
ровки сообщений от Боба, так как Боб использует значение N, полученное из р и
q. Прелесть идеи RSA состоит в том, что, если N — очень большое число, то ис-
ключительно трудно, с вычислительной точки зрения, произвести обратную опе-
рацию и найти р и q (при тех средствах, которые существуют на сегодняшний
день, это практически невозможно).
Перемножение pvtq для получения N, в соответствии с концепцией RSA, делает
N односторонней функцией. Чтобы понять, почему это происходит, давайте вкрат-
це рассмотрим умножение простых чисел. Если ответ известен, то очень трудно
найти множители, если они представлены простыми числами. Операция по на-
хождению N состоит в разложении на множители. Чтобы найти р и q, требуется
много времени и усилий. Подход состоит в том, чтобы подбирать простые числа
до тех пор, пока не окажется, что N делится нацело на одно из них. Как только
это произойдет, окажется найденным и другое число (это уже труда не требует).
Чтобы оценить эффективность такого подхода, давайте вернемся к вычислени-
ям Сингха и представим себе, как они будут производиться при использовании
быстрых процессоров. Предположим, что р и q равны простому числу порядка
1065. При умножении они дают 10130. Если использовать процессор с тактовой
частотой 500 МГц, то понадобится около 10 лет, чтобы разложить N на множите-
ли. Конечно, более быстрые процессоры и параллельные вычисления позволят
найти ответ гораздо быстрее.
В 1977 году был объявлен конкурс на взлом 129-знакового кода [GARD77]1.
Ожидалось, что этот код не будет взломан в течение многих лет. В 1994 году
группа специалистов бывшей компании Bellcore, организованная специально для
решения этой задачи, взломала этот код. Команда нашла два простых числа,
которые при умножении давали N. В настоящее время 129-знаковый код не ка-
жется таким уж огромным. Тем не менее, если выбрать достаточно большое зна-
чение N, код RSA неуязвим.
Пары ключей RSA
На практике для асимметричных ключей используются пары ключей. Они рабо-
тают следующим образом. Посмотрите на рис. 3.6. На этапе 1 Алиса выбирает
два больших простых числа р и q и перемножает их, N^p-q. Затем Алиса выби-
рает случайное целое число е. (Число е не должно иметь делителей >1, общих с
р-1 или q-1.) Алиса обнародует пару (N, е) (на этапе 2), но не пару (р, q). Таким
образом, (X е) является открытым ключом, а (р, q) — индивидуальным. Боб мо-
жет сделать то же самое у себя: вычислить свое собственное N.
Давайте предположим, что Бобу известен открытый ключ Алисы (N, е). На этапе 3
Боб шифрует сообщение М в шифр С для того, чтобы отправить его Алисе (этап 4):
С-№ (mod N)
На этапе 5 Алиса дешифрует зашифрованное сообщение С следующим образом:
M-Cd (mod N)
1 [GARD77], Gardner, Martin. Mathematical Games, Scientific American, January, 1977.
56
Глава 3. Основные концепции безопасности
Значение d является секретным показателем степени для дешифрации сообще-
ний Алисой. Значение d вычисляется прямо из е, если известны р и q.
e-d=l (mod (р—l)-(q—1))
Алиса
ф Р и q — известные Алисе
секретные величины
N и е, известные Бобу
и другим (2)
С=М‘ (mod N ®)
(5) М=С (mod N),
гдв d выводится
из р и q)
Рис. 3.6. RSA операции
Таким образом, исходное сообщение Боба М восстановлено.
Итак, одна из задач, то есть создание работоспособной реализации концепции
асимметричного ключа, была решена RSA. Остается еще одна проблема: как убе-
диться в том, что открытый ключ Боба, используемый Алисой, действительно
принадлежит Бобу. Этот вопрос подводит нас к следующим темам этой главы:
генерации и передаче ключей, за которыми следует тема сертификации ключей.
Генерация и передача ключей
Два метода используются при создании открытых ключей: передача и генерация
ключей [MAUG98]1. Примером передачи ключа является использование алго-
ритма RSA для шифрования произвольно созданного сеансового ключа (также
называемого симметричным одноразовым ключом) с помощью открытого ключа
получателя. Зашифрованный сеансовый ключ затем посылается получателю,
который дешифрует его, используя свой индивидуальный ключ. В этот момент
обе стороны имеют один и тот же сеансовый ключ (для шифрования последую-
щих сообщений), однако операция основана на данных только одной стороны.
Достоинство такого метода передачи ключа состоит в том, что он требует значи-
тельно меньше вычислений, чем использование открытого ключа для шифрова-
ния всего потока данных.
' [MAUG98]. Maughn. D., et al. Internet Security Association and Key Managment Protocol (ISAKMP), RFC
2408, November 1998.
Код подтверждения подлинности сообщения и хэширование ключей
57
Алгоритм Диффи—Хеллмана иллюстрирует генерацию ключей с помощью шиф-
рования открытым ключом. Первым шагом в этом алгоритме является обмен
открытой информацией между двумя пользователями. Затем каждый пользова-
тель вычисляет общую секретную величину, используя открытую информацию
второго пользователя и свою секретную информацию. Это секретное значение
может быть использовано как сеансовый ключ или как ключ для шифрования
произвольно созданного сеансового ключа. При этом методе создается сеансо-
вый ключ, в основе которого лежит открытая и секретная информация обоих
пользователей. Достоинством алгоритма Диффи—Хеллмана является то, что ключ,
используемый для шифрования сообщений, основан на информации, которая
имеется у обоих пользователей, и тот факт, что ключи не зависят от передачи их
друг другу, обеспечивает совершенную секретность. Стороны могут согласовать
секретное значение без шифрования, и эта общая величина может быть сразу
использована для шифрования данных и/или удостоверения подлинности.
Более подробное описание этих алгоритмов дано в RFC 2412, а в главе 5 объяс-
няется протокол определения ключей (Key Definition Protocol) OAKLEY, осно-
ванный на алгоритме Диффи—Хеллмана.
Код подтверждения подлинности
сообщения и хэширование ключей
В течение последних нескольких лет было обнаружено, что некоторые методы
аутентификации не обеспечивают должного уровня защиты. Код подтверждения
подлинности сообщения (Message Authentication Code - МАС) предназначен для
того, чтобы создать для сервисов подтверждения подлинности данных более
высокий уровень безопасности. В нем используется один ключ для проверки
подлинности данных, кроме того, в МАС применяется хэш-функция. Вот как это
работает:
О МАС создается хэшированием совместного секретного ключа (симметричный
шифр) и сообщения.
О Этот дайджест прикрепляется к сообщению.
О Получатель проверяет МАС путем хэширования совместного секретного ключа
(симметричный шифр) и сообщения, при этом создается временный дайджест.
О Временный дайджест сравнивается с дайджестом, прикрепленным к сообще-
нию. Если они равны, сообщение и подпись считаются удостоверенными.
Описанная процедура называется хэшированием ключа, и она очень важна, так
как хэширование без ключа уязвимо для атак. Хэширование ключа использует-
ся в IPSec для разделения блока данных на пакеты, при этом МАС вычисляется
для каждого пакета. Более подробные объяснения? касающиеся кода МАС, приво-
дятся в главе 5.
58
Глава 3. Основные концепции безопасности
Совмещение функций безопасности
Из приведенного материала мы узнали, что имеются две основные операции для
передачи и поддержки защищенных данных. Первая операция — это шифрова-
ние (отправителем) посылаемого сообщения и соответствующее дешифрование
этого сообщения получателем. Вторая операция предназначена, в частности, для
того, чтобы убедиться, что сообщение подлинное, а не отправлено каким-нибудь
самозванцем. Иными словами, производится идентификация отправителя сооб-
щения. Имеются и другие важные аспекты безопасности, такие как противодей-
ствие атакам типа «повтор», которые мы не можем игнорировать.
Несколько методов могут быть применены при реализации этих операций. Мы
только что узнали об операциях с асимметричными ключами. Соответствующий
пример представлен на рис. 3.7. Здесь используется шифрование открытым клю-
чом, о котором мы только что говорили, а также хэш-функции, описанные ранее.
На этом рисунке представлена общепринятая схема использования асимметрич-
ных ключей для шифрования, подтверждения подлинности и проверки целостности.
Для того чтобы вам было легче понять рисунок, я объясню шесть операций, поме-
ченных соответствующими цифрами на рисунке. Надписи в прямоугольниках
означают входные и выходные данные для этих операций.
На этапе 1 исходное сообщение (открытый текст) подвергается односторонней
хэш-операции. Результатом этой операции является дайджест сообщения. На
этапе 2 проводится операция шифрования с использованием полученного дайд-
жеста и индивидуального ключа отправителя, в результате чего создается циф-
ровая подпись. Цифровая подпись добавляется к оригинальному сообщению
(открытому тексту), и этот блок данных шифруется на этапе 3 при помощи от-
крытого ключа получателя. Результатом всей этой работы является зашифрован-
ное сообщение.
Получатель выполняет процедуру в обратном порядке. На этапе 4 зашифрован-
ное сообщение дешифруется при помощи индивидуального ключа получателя,
и в результате получаются исходное сообщение (открытый текст) и цифровая
подпись. Этап 4 является важным аспектом криптографии с открытыми ключа-
ми, поскольку расшифровать зашифрованное сообщение может только пользо-
ватель, тот, у которого есть индивидуальный ключ получателя.
На этапе 5 при помощи открытого ключа отправителя извлекается цифровая
подпись. Затем эта подпись и открытый текст (на этапе 6) подвергается одно-
сторонней хэш-операции, аналогичной той, которая была выполнена отправите-
лем. После этого получатель сравнивает результаты операций, проведенных на
этапах 5 и 6, и, если конечные величины совпадают, получатель может быть уве-
рен, что отправитель подлинный. Если результаты отличаются, то это означает, что
что-то произошло: или отправитель — самозванец, или кто-то перехватил сообще-
ние и изменил его. Или, что очень маловероятно, данные были повреждены при
пересылке, и этот сбой не был выявлен функциями обнаружения ошибок.
Во многих реализациях к операциям, о которых только что говорилось, добавля-
ется еще одна. Она известна под несколькими разными названиями. Некоторые
Совмещение функций безопасности
59
называют эту операцию сеансовым ключом, другие — одноразовым ключом, или
одноразовым симметричным ключом.
Открытый
текст
Открытый
текст
Индивидуальный
ключ
отправителя
Операции
хэширования
Дайджест
сообщения
Операции
шифрования
Операции
хэширования
(§)
Операции *
дешифрования
Дайджест
сообщения
Индивидуальный
ключ
отправителя
Цифровая
подпись
Цифровая
подпись
Открытый
ключ
получателя
©▼
Операции
шифрования
©I .
Операции
дешифрования
Индивидуальный
ключ
получателя
Зашифрованное сообщение
Рис. 3.7. Применение открытых ключей для шифрования, аутентификации и проверки
целостности
На рис. 3.8 показано, как эта операция совмещается с только что описанной схе-
мой. Различие в операциях видно на этапах 3 и 6. Одноразовый симметричный
ключ используется для шифрования цифровой подписи и открытого текста на
этапе 3 и для выполнения обратной операции на этапе 6, при приеме сообщения.
Кроме того, одноразовый ключ шифруется отправителем при помощи открыто-
го ключа получателя, и создается зашифрованной одноразовый ключ. При при-
еме сообщения этот защищенный ключ дешифруется при помощи индивйдуаль-
60
Глава 3. Основные концепции безопасности
ного ключа получателя. Полученный в результате этого одноразовый ключ ис-
пользуется для дешифрования зашифрованного сообщения.
Индивидуальный
ключ
отправителя
Одноразовый
симметричный
ключ
Открытый
ключ
получателя
Открытый
текст
Операции
хэширования
Отправитель Я
аяаяадДД
Операции
хэширования
Дайджест
сообщения
Операции
шифрования
Цифровая
подпись
► Операции
шифрования
► Операции
шифрования
I
ОТК
СМ
*?
| Дайджест
| сообщения
Операции
деши рръеания
Цифровая
подпись
- Операции ◄
дешифрования
@1
Операции <
дешифрования
см
отк
Открытый
ключ
отправителя
Одноразовый
симметричный
ключ
Индивидуальный
ключ
получателя
Зашифрованный одноразовый ключ (ОрК)
и Зашифрованное сообщение (ЗС)
Рис. 3.8. Использование одноразового (сеансового) ключа
Этот ключ называется симметричным, так как один и тот же ключ используется
для шифрования и дешифрования данных. Одним из достоинств этого метода
является то, что операции производятся с достаточно большой скоростью. Оче-
видно также, что в этом случае добавляется еще один уровень безопасности для
всего процесса.
Поль Циммерман и PGP (Pretty Good Privacy — достаточно хорошая секретность) 61
Поль Циммерман и PGP (Pretty Good
Privacy — достаточно хорошая
секретность)
Операции, описанные в предыдущем разделе, демонстрируют, как работает про-
токол PGP:
О PGP создает сеансовый ключ.
О Этот сеансовый ключ используется для шифрования сообщения.
О RSA используется для шифрования сеансового ключа (при помощи открыто-
го ключа получателя).
Зашифрованное сообщение и зашифрованный сеансовый ключ отсылаются по-
лучателю, где производится обратная операция.
Отметим еще раз, что важной чертой PGP (и сеансового ключа) является суще-
ственное повышение скорости процесса. Эта новаторская идея была предложена
Полем Циммерманом, автором PGP. В общем и целом операции, показанные на
рис. 3.8, создают эффективный метод обеспечения конфиденциальности и аутен-
тификации.
PGP с использованием сертификатов ключей
Кроме всего прочего, в PGP поддерживается механизм так называемых серти-
фикатов ключей. Каждому открытому ключу соответствует сертификат ключа,
который включает в себя ключ, идентификатор его создателя, дату создания и
перечень цифровых подписей, подтверждающих его достоверность. Сертифика-
ция ключей будет рассмотрена более подробно в этой же главе позже.
PGP (Pretty Good Privacy — достаточно хорошая секретность) полностью соот-
ветствует своему названию — эта система действительно достаточно хороша.
Подробное описание PGP выходит за рамки этой книги. Если вы интересуетесь
этим вопросом, советую прочитать книгу Гарфинкеля [GARF95]1.
Пример открытого ключа PGP
Ниже приведен пример открытого ключа, опубликованного регистрационным
бюро IETF для совещания IETF в Аделаиде (Австралия) 26-31 марта 2000 года.
-BEGIN PGP PUBLIC KEY BLOCK—
Version: 2.6.2
1 [GARF95j. Garfinkel, Simson. PGP: Pretty Good Privacy. O'Reilly & Assosiates. 1995. Sebastapol, CA.
62
Глава 3. Основные концепции безопасности
mQCPAzF+LtIAAAEEA0R6J+TD01nYcfH5R40F4/+tOdZt02vlJK11ymMJqyVpUyWeU4I6t/
rFxkZntupxK0IJgNEC93W41XKSn4q9fUuviAduTzXR9ppBAxalevJPSlnz40Sz!oxC6k+VmtAyAbkEwDvgA9nyXTkK
3weC4T8IMjle01tEfwIhmzn+kqSBABEBAAG0I01FVEYgUmVnaXN0cmFyI0xpZXRmLXJzdnBAaWV0ZiSv
cmc+1QCVAwUQMrAxbvvCP42xMxQ5AQGUcwQA1B0v037y978BBcR0USMuQUvdnX71XsLc+TogBflHsDQP
Na/oYuzjDlqXtbQoyj2rItWpcg4KrD6hJ9x2nYzZT0hjoFa8FI567PdUg7TfNJ4wjspCykA00Egk0F
Xh9rMCRkl4ac4qVdYY69Aii/p/i8thLb+ps8xDioRQAtiGJAHUDBRAyJMfk0HlcePGjdhEBASM
7Av4yaX4eSIcei ZnwpBepL0toiWpywUzm2P+u9PFQ23ws/CrklCvFfSL4MSg+wNj3jVeC52
MZOepOE2m5PgFH590xTqqfRg4AxGnzH5AHTCyjwD14ClXFhX2rYQ6xvElGaReOKGlldGYgcmVnaXNOcmFyIDxpZXRmLXJl
Z21zdHJhckBpZXRmLm9yZ«z6JAJUDBRAzzfcRAiGb0f6SpIEBAXdsBADFu/qsR87zD//tDoDu
ltltDImS6WGecBDGnityqURhtFuowPJrrn+WtBLTHI3hRLW00obgscfRYJxCY+MaSUjvs3iwPIkUXjqUe3sZXFUI
NjcT9ELzp0PX15NIcGrWmQzHRlDrw0m+zjcW7NmsDT0+m0bYiiiXQZGtdlANC5HfCokA10MFEDP0Je0H
G8BZjxsZpQEB3dsEAKHdY4awpqPbbqG81893v0zGnveQSI9AafpYbVkIXypoGvnRnnM70AP9zRaI8rur
YVwOzIk8jxCETgPziVHNEeEkRk9TAC31bB985re5UH9133Gajsjcln6dG25xJ6CPZSLcFLB7VhPFxXu
mUJuIf2/pYIXqvzio0ebMCP01DaY-CbD3
—END PGP PUBLIC KEY BLOCK—
OpenPGP
OpenPGP [CALL99]1 является черновым стандартом Интернета, разрабатываемым
для модификации стандарта RFC 2440 «OpenPGP Message Format» (Формат
сообщения OpenPGP) и замены стандарта RFC 1991 «PGP Message Exchange
Formats» (Форматы обмена сообщениями PGP), OpenPGP обеспечивает
целостность данных, содержащихся в сообщениях и файлах, посредством
следующих средств: цифровые подписи, шифрование, сжатие, управление и
сертификация ключей. Кроме того, могут использоваться и другие средства,
которые описаны в [CALL99],
В OpenPGP используются операции как с симметричными, так и с асимметрич-
ными ключами. При шифровании открытыми ключами объект шифруется при
помощи симметричного алгоритма шифрования. Каждый симметричный ключ
используется только один раз. Для каждого сообщения генерируется случайным
образом новый сеансовый ключ. Так как сеансовый ключ используется только
один раз, он присоединяется к сообщению и передается вместе С ним. В целях
защиты этот ключ шифруется при помощи открытого ключа получателя. При
этом порядок работы будет таким:
О Отправитель создает сообщение.
О OpenPGP у отправителя генерирует случайное число, которое используется
как сеансовый ключ только для этого сообщения.
О Сеансовый ключ шифруется при помощи открытого ключа каждого получа-
теля. Этими «шифрованными сеансовыми ключами» начинается сообщение.
О OpenPGP у отправителя шифрует сообщение при помощи сеансового ключа,
что составляет остальную часть сообщения.
' [CALL99]. Callas, Jon, et al., draft-ietf-<>penpgp-rfc2440bis-00.txt
Совершенная прямая секретность (Perfect Forward Secrecy — PFS)
63
О OpenPGP у получателя дешифрует сеансовый ключ при помощи индивиду-
ального ключа получателя.
О OpenPGP у получателя дешифрует сообщение при помощи полученного се-
ансового ключа.
Если шифрование осуществляется с помощью симметричного ключа, данные
могут быть зашифрованы или с помощью симметричного ключа, полученного из
секретной фразы (или другого общего секретного кода), или с помощью двух-
этапного механизма, подобного методу открытых ключей, описанному ранее, в ко-
тором сам сеансовый ключ шифруется при помощи симметричного алгоритма,
полученного из общего секретного кода.
В одном и том же сообщении можно использовать и цифровую подпись, и шиф-
рование. Сначала создается подпись для сообщения и прикрепляется к нему. Затем
сообщение с подписью шифруется симметричным сеансовым ключом. На конеч-
ном этапе сеансовый ключ шифруется с помощью открытого ключа и прикреп-
ляется перед зашифрованным блоком.
В цифровой подписи используется хэш-код или алгоритм создания дайджеста
сообщения, а также алгоритм подписи открытым ключом. Здесь используется
следующая последовательность:
О Отправитель создает сообщение.
О Отправляющая программа генерирует хэш-код сообщения.
О Отправляющая программа генерирует подпись из хэш-кода с помощью инди-
видуального ключа отправителя.
О Полученная двоичная подпись прикрепляется к сообщению.
О Принимающая программа сохраняет копию подписи сообщения.
О Принимающая программа генерирует новый хэш-код для полученного сооб-
щения и проверяет его при помощи подписи сообщения. Если эта проверка
удалась, то сообщение считается подлинным.
Совершенная прямая секретность
(Perfect Forward Security — PFS)
Давайте здесь прервемся и поясним, что это за термин. Многие процедуры обес-
печения безопасности в Интернете используют термин PFS. В соответствии со
стандартом RFC 2409, PFS ссылается на тот факт, что дискредитация одного клю-
ча даст доступ только к данным, защищенным одним ключом. PFS будет суще-
ствовать только в том случае, если ключ, используемый для защиты передачи
данных, не используется для создания дополнительных ключей. А также в том
случае, если ключ, используемый для защиты данных, выведен из другого набо-
ра данных, но при этом исходный набор данных не используется для создания
других ключей. Более подробно, с примерами, PFS будет обсуждаться далее.
64
Глава 3. Основные концепции безопасности
Атака типа «человек посередине»
До сих пор мы предполагали, что получатель доверяет отправителю и уверен в
том, что открытый ключ отправителя (который он сохранил) подлинный. Одна-
ко это может быть и не так. Шифрование открытым ключом может быть под-
вергнуто атаке, которая называется «человек посередине» (другое название —
«поросенок посередине»). Эту ситуацию иллюстрирует рис. 3.9.
Хакер
Фальшивый открытый
Фальшивый открытый _ 101104 ХакеРа 1 (ФОКХ1)
ключ Хакера 2 (ФОКХ2) ®
Рис. 3.9. Атака «человек посередине»
«Человек посередине», которого зовут Хакер, одурачил Кэрол и Теда, послав им
фальшивые открытые ключи. (А что же случилось с Алисой и Бобом? Они все
еще здесь, но для будущих примеров мы должны ввести новых персонажей в наше
повествование. Боб, Кэрол, Тед и Алиса кажутся мне вполне подходящими име-
нами.) На этапе 1 Тед получает открытый ключ Хакера (ФОКХ1), а на этапе 2
Сертификация
65
Хакер создает другой открытый ключ и посылает его Алисе (ФОКХ2). Фальши-
вые ключи показаны на рисунке темно-серым цветом. В какой-то другой момент
(этап 3) Кэрол и Тед создают подлинные индивидуальные ключи (ИКТ и ИКК),
показанные на рисунке белым цветом. Мы предполагаем, что эти ключи являют-
ся сеансовыми ключами (одноразовыми симметричными ключами) и использу-
ются для шифрования и дешифрования открытых ключей (см. рис. 3.9).
На этапе 4 Кэрол и Тед используют то, что они считают открытыми ключами
друг друга, для шифрования своих индивидуальных сеансовых ключей. В дей-
ствительности же они используют фальшивые открытые ключи Хакера. На эта-
пе 4 рисунка видно, что сеансовые ключи Кэрол и Теда находятся в конвертах,
закодированных открытыми ключами противоположной стороны, которые мо-
гут быть открыты только индивидуальным ключом противоположной стороны.
На этапе 5 зашифрованные сеансовые ключи посылаются Кэрол и Тедом, но
перехватываются Хакером, который (на этапе 6) использует свои два открытых
ключа (ФОКХ1 и ФОКХ2) для дешифрования индивидуальных ключей.
Таким образом, на этапе 7 Хакер украл индивидуальные сеансовые ключи Кэрол
и Теда и может продолжать играть роль «человека посередине» и перехватывать
сообщения.
Сертификация
Для того чтобы противостоять атаке типа «человек посередине», большинство
систем безопасности высокого класса используют идею цифровых сертификатов,
о которой уже говорилось выше. Благодаря этой операции получатель сообще-
ния может быть уверен в том, что открытый ключ отправителя является подлин-
ным. Для реализации этой идеи, отправитель сообщения (Кэрол с рис. 3.10) дол-
жен получить цифровой сертификат из независимого источника, которому он
доверяет. Эта третья сторона называется центром сертификации. На этапе 1 Кэрол
посылает свой открытый ключ в центр сертификации вместе с информацией,
необходимой для идентификации. Центр сертификации использует эту инфор-
мацию для проверки Кэрол и ее открытого ключа, как это показано на этапе 2.
Если Кэрол благополучно проходит проверку, центр сертификации посылает Кэ-
рол цифровой сертификат, который подтверждает подлинность индивидуально-
го ключа Кэрол. При этом центр сертификации берет на себя ответственность за
этот сертификат. На рисунке эта операция показана как этап 3. На этапе 4, когда
Кэрол посылает данные (например, Теду), она делает все то же самое, что и в пре-
дыдущих примерах (то есть создает хэш-функции, цифровую подпись и т. д.), и по-
сылает Теду зашифрованные данные вместе с цифровым сертификатом.
В предыдущих операциях открытый ключ центра сертификации был предостав-
лен другим лицам, в том числе и Теду. Следовательно, на этапе 5 Тед использует
открытый ключ центра сертификации для проверки цифровой подписи центра
сертификации, которая является частью сертификата Кэрол. Если проверка про-
66
(лава 3. Основные концепции безопасности
ходит удовлетворительно, Тед удостоверяется, что открытый ключ Кэрол (так-
же часть сертификата) действительно принадлежит Кэрол. На этапе 6 центр серти-
фикации информирует об этом Теда, и поэтому на этапе 7 Тед может использовать
открытый ключ Кэрол для дешифровки зашифрованного сообщения.
1
Кэрол
Центр сертификации
Тед
Вот мой открытый ключ
(2) Проверка Кэрол
Ты действительно Кэрол, _
получай мой сертификат ®
К
Я Кэрол, вот мой открытый ключ и сертификат
Этот открытый ключ действительно
-------------------------------Сч.
принадлежит Кэрол?
Да, это так
Отлично, тогда я его буду @
использовать
Рис. 3.10. Центр сертификации
Процедура сертификации
Центр сертификации сертифицирует открытый ключ, подписывая сертификат
индивидуальным ключом центра. Любой пользователь, который хочет восполь-
зоваться чьим-нибудь открытым ключом, может убедиться в его подлинности
путем применения открытого ключа центра к сертификату. Если Хакер попы-
тается перехватить и подделать сертификат центра в процессе его передачи пользо-
вателю, это будет обнаружено, потому что цифровая подпись будет неправильной.
Разумеется, здесь можно попасть в ситуацию собаки, ловящей свой хвост; оче-
видно, пользователь, обращающийся в центр сертификации, должен верить, что
центр выпускает только подлинные сертификаты. Если Хакер проникнет в ме-
ханизмы сертификации центра, то мы будем отброшены назад к исходной про-
блеме, увеличенной многократно.
Меры против атак типа «повтор»
67
Меры против атак типа «повтор»
Как уже было сказано в главе 2, повтор является атакой, при которой данные
перехватываются, возможно, модифицируются и посылаются повторно. Одним
из методов защиты пакетов против атаки типа «повтор» является присвоение
передаваемым пакетам порядкового номера. При приеме необходимо: проверить,
не содержит ли полученный накет такого же порядкового номера, как и уже
принятый пакет; убедиться в том, что порядковый номер достаточно велик (что-
бы подлинный пакет не был отбракован из-за цикличности порядковых номе-
ров); использовать схему со скользящим окном для отбраковки «устаревших»
пакетов. Ведь старые пакеты могли стать таковыми из-за того, что они были пе-
рехвачены, модифицированы и посланы повторно.
Эти меры против атак типа «повтор» продемонстрированы на рис. 3.11. Длина
принимающего окна равна 7, окно содержит порядковые номера от 1 до 7. Эта
иллюстрация является упрощенным примером, и такое маленькое окно исполь-
зуется здесь для наглядности, поскольку по стандартам Интернета его величина
должна обеспечивать нумерацию 232 входящих пакетов.
ANAAANAANRN N N
9 10
11
...п
а. Окно на позиции 17,9 получен, но подлинность еще не подтверждена
ANAAANAANAN N N
О 1
2
3 4 5 в 7 8 9
..——К' A'-a-L.....
10
11 ...n
б. Окно перемещается на 39, когда подлинность 9 подтверждена
А Получен, подлинность установлена
N Не получен
R Получен, но подлинность еще не установлена
Рис. 3.11. Защита против атак типа «повтор»
На рис. 3.11, а пакеты 0, 2, 3, 4, 6 и 7 были получены и их подлинность была
установлена. Таким образом, правая сторона окна показывает наибольший по-
рядковый номер пакета, который был получен и проверен на подлинность. Пакет 9
был получен, но еще не был проверен, поэтому окно не может передвинуться на
9, пока его подлинность не будет установлена. Отметим, что пакеты принимают-
ся (в смысле порядка следования), если они попадают в окно или справа от окна,
при этом порядок следования произволен.
68
Глава 3. Основные концепции безопасности
На рисунке 3.11, б пакет 9 аутентифицирован, и в результате окно смещается на
позицию 3.9. Пакет 1 теперь находится слева от окна, и, если он будет получен,
он должен быть отвергнут. Пакеты 5 и 8 еще не прибыли, а когда они прибудут,
они будут подвергнуты обработке, так как они все еще находятся в принимаю-
щем окне.
Безопасность в мобильных сетях
В этой части книги описывается на примере, каким образом Глобальная система
мобильной связи (Global System for Mobile Communication — GSM) использует
ключи для идентификации пользователя и шифрования/дешифрования данных.
Идентификация
Одной из самых важных операций при установке связи в любой мобильной си-
стеме является идентификация пользователя. В системе GSM идентификация
производится путем проверки подлинности SIM-карты (Subscriber Identify Modu-
le — модуль идентификации подписчика) пользователя, расположенной в мобиль-
ном телефоне. Такой метод идентификации и подтверждения подлинности пользо-
вателя основан на алгоритме АЗ, который хранится в SIM-карте и центре контроля
идентификации сети (Authentication Control Center — AUC). В этом методе так-
же используется индивидуальный ключ Ki, который хранится как в SIM-карте,
так и в AUC сети.
AUC отвечает за создание подтвержденного ответа (Signed RESponse — SRES).
Посмотрите на рис. 3.12, а. Значение Ki связано с каждым международным иден-
тификатором пользователя мобильной сети (International Mobile Subscriber
Identity — IMSI). Мобильная станция идентифицируется по международному
идентификатору оборудования мобильной сети (International Mobile Equipment
Identity — IMEI). Для получения SRES в алгоритме АЗ используется Ki и 128-
битное случайное число (RAND).
На рис. 3.12, б AUC загружает несколько наборов RAND- и SRES- пар (которые также
называются парами «оклик — отзыв») на HLR. В свою очередь HLR по мере
надобности делает эти данные доступными для VLR. Когда в VLR заканчивает-
ся один набор (один набор используется каждый раз, когда MS (Mobile Station —
мобильная станция) регистрируется в соте, за которую отвечает VLR), он мо-
жет запросить дополнительные наборы от HLR.
В целях подтверждения подлинности сеть посылает пользователю RAND в сооб-
щении, как показано на рис. 3.12, в. Сообщение является «вызовом» для пользо-
вателя. Мобильная станция использует RAND и идентификационный ключ Ki как
входные величины для вычислений по алгоритму АЗ. Напомним, что величина
Ki хранится только на SIM-карте и в сети. Используя Ki и RAND, алгоритм АЗ создает
SRES (подтвержденный ответ). Это значение'возвращается на VLR и проверяется.
Таким образом, сеть может проверить подлинность пользователя. Естественно,
Безопасность в мобильных сетях
69
если величина SRES не равна заранее вычисленной величине, хранимой в VLR,
права пользователя не подтверждаются.
AUC
SRES
RAND (128 bits)
а. Образование SRES
пары "оклик-отзыв" (п)
RAND, SRES (1)
RAND, SRES (2)
RAND. SRES (3)
И T. Д.
>> HLR
б. Распределение пар "оклик-отзыв”
Сеть Мобильная станция
в. Подтверждение подлинности
RAND Случайное число
SRES Подтвержденный ответ
Рис. 3.12. Аутентификация в GSM
Обычно набор величин RAND и SRES хранится в сети (на HLR и VLR) и управля-
ется AUC. Такой подход позволяет в каждом случае идентификации использо-
вать различные величины. Если у HLR заканчиваются номера, дополнительные
значения могут быть затребованы у AUC. При нормальных условиях АЗ и К1
никогда не посылаются по каналам связи.
Операции секретности
Как видно из рис. 3.13, а, шифровальный ключ (Кс) создается на AUC при помо-
щи пар 1М§1 и Ki. Для создания Кс используется алгоритм А8 и RAND.
70
Глава 3. Основные концепции безопасности
Рисунок 3.13, б показывает, как AUC загружает Кс на HLR. Обратите внимание
на число наборов (обычно пять) RAND, SRES и Кс, которые посылаются от AUC на
HLR, а затем на соответствующий VLR.
В конечном итоге, как изображено на рис. 3.13, в Кс и А5 используются для шиф-
рования и дешифрования потока данных.
RAND (128 бит)
а. Создание шифровального ключа
AUC _________________________________>.HLR
Примечание: обычно посылается
пять триплетов
(RAND, SRES. Кс) с HLR на VLR
б. Загрузке ключа
Кс
КС
Открытый поток данных А5
Зашифрованный поток данных
А5 Открытый поток данных
а. Шифрование и дешифрование
Рис. 3.13. Шифрование потока данных пользователя
Целью этих операций является облегчение создания SRES, если Ki и RAND извест-
ны. И наоборот, очень трудно получить Ki из RAND и SRES, что и является сутью
этого подхода.
Заключение
Для защиты потока данных пользователя в локальной сети и Интернете исполь-
зуется большое количество методов. В большинстве из них используются хэш-
функции, арифметика в остаточных классах, большие простые числа и асиммет-
ричные ключи. Кроме того, в целях обеспечения эффективности часто используются
операции с симметричными (сеансовыми) ключами.
:Д| ГЛАВА' Брандмауэры
В этой главе объясняется, как работают брандмауэры. Особенно подробно об-
суждается вопрос о том, что могут делать брандмауэры, а что нет. Мы рас-
. смотрим как внутренние, так и внешние брандмауэры, известные под названием
брандмауэры прокси и доступа (proxy and access firewalls), соответственно. Кро-
ме того, мы уделим внимание фильтрации и обсудим примеры того, как можно
настроить брандмауэр в соответствии с правилами безопасности, принятыми на
предприятии. Множество фирм предлагают свои услуги в этой области, и мы рас-
смотрим, что именно они могут предложить.
Что такое брандмауэр?
Брандмауэр — это система, которая позволяет применить правила доступа к
информации, принятые в пределах одной или группы организаций. Брандмауэр
не обязательно является отдельным компьютером, он может быть реализован на
нескольких компьютерах, которые и реализуют собой правила доступа.
В самых простых терминах, брандмауэр разрешает или запрещает поток данных
от входа брандмауэра к его выходу. Любой разрешенный поток данных, который
может пройти через брандмауэр из одной сети в другую или от одного компью-
тера к другому, должен быть определен в правилах безопасности, установленных,
в планах управления доступом той или иной организации. Другим важным ат-
рибутом брандмауэра является то, что он сам должен быть безопасным. И, на-
сколько это возможно, быть устойчивым к попыткам несанкционированного
доступа.
Защита от внешних (untrusted) сетей
В самых простых терминах, брандмауэр — это система, которая защищает внутренние
(trusted) сети от внешних (untrusted) сетей. Внутренние и внешние сети — понятия,
введенные в главе 1 и показанные на рис. 4.1. Внутренние сети могут быть
представлены локальными сетями, а внешние — Интернетом. Однако определение
72
Глава 4. Брандмауэры
понятий внутренних и внешних сетей зависит от организации. В некоторых случаях
в пределах одной организации могут быть как внутренняя, так и внешняя сети,
в зависимости от природы данных, используемых в организации. Разумеется, понятие
внутренних брандмауэров (внутренних для компании) и внешних брандмауэров
(расположенных между внешними и внутренними сетями) необходимо принимать
во внимание в процессе построения механизмов безопасности. Более того, понятие
внутренних брандмауэров является достаточно важным, поскольку хорошо известно,
что несанкционированный доступ к данным изнутри компании более распространен,
чем кражи данных, произведенные из внешних сетей.
Рис. 4.1. Защита от внешних сетей при помощи брандмауэра
В общем, мы можем рассматривать брандмауэр как средство в реализации мер
безопасности той или иной организации, как средство, обеспечивающее в числе
прочих ограничение доступа к информации. Поскольку брандмауэр не только
содержит, но и реализует правила безопасности на практике, то, таким образом,
брандмауэр представляет собой совокупность как этих правил, так и решений по
их применению, принятых в данной организации.
Поскольку большинство компаний разрешают своим сотрудникам работать с
Интернетом (внешней Сетью), то брандмауэры должны быть установлены таким
образом, чтобы реализовывать в себе те ограничения, которые организация хоте-
ла бы наложить на доступ к Интернету (или другим внешним сетям). Например,
организация может разрешить доступ к Интернету изнутри и запретить любой
доступ снаружи. В качестве альтернативы могут быть использованы так называ-
емые фильтры для того, чтобы разрешить только определенным системам пре-
одолевать брандмауэр.
Разрешительный и запретительный доступы
Правила доступа, принятые в организации, могут быть реализованы в брандма-
уэре двумя основными способами: а) разрешать любой вид доступа, кроме тех,
которые явно запрещены, и б) запретить любой вид доступа, кроме тех, которые
явно разрешены [NCSA96]*. Первый вариант наиболее уязвим для атак, поэтому
запретительный доступ является базой для большинства реализаций. Проблемой
1 [NCSA96]. National Computer Security Association (NCSA). NSCA Firewall Policy Guide, tersion 1.01.
Исключительно полезный источник информации, публикуемый NCSA. Вы можете связаться с этой
организацией через электронную почту requcstCncsa.com или по телефону в США (717) 258-1816,
доп. 250. Мои комментарии основаны на этом документе.
Что могут делать брандмауэры и что они не могут делать
73
с разрешительным доступом является то, что, например, могут появиться новые
методы доступа, которые никак не определены в фильтрах брандмауэра и не
упоминаются в планах доступа организации и, следовательно, могут быть исполь-
зованы для несанкционированного доступа. Или другая простая иллюстрация.
Запретительный доступ может быть обойден, если использовать нестандартный
порт, который не был явно определен (и запрещен) в правилах.
И последнее замечание в этом начальном обсуждении брандмауэров. Во многих
ситуациях имеет смысл использовать различные виды брандмауэров и осуще-
ствлять анализ и фильтрацию доступа на основании природы данных и их атри-
бутов, таких как адреса, номера портов и т. д. Эта идея ведет нас к понятию
фильтрации пакетов, которое мы коротко обсудим позже.
Что могут делать брандмауэры и что они
не могут делать
Брандмауэр не может решить все стоящие перед организацией проблемы безо-
пасности. Брандмауэр сам по себе уязвим для атак. В этом разделе мы обсудим,
что брандмауэр может делать и, что также важно, что он не может делать. Бранд-
мауэр обладает следующими возможностями:
О Реализация правил безопасности. Конфигурация брандмауэра отражает поли-
тику компании в области безопасности данных. Эта политика устанавливает,
какие виды потоков данных могут направляться из внешней сети во внутрен-
нюю сеть, а также какие виды потоков данных могут направляться из внут-
ренней во внешнюю. ,
О Единственная точка реализации правил безопасности. Одной из проблем,
решаемых экспертами в области безопасности, является обеспечение как можно
меньшего количества точек входа подозрительных данных во внутреннюю сеть.
Брандмауэр позволяет предприятию ограничить доступ к своей сети одной
или ограниченным количеством точек доступа. Этот подход более эффекти-
вен, чем если бы усилия были направлены на обеспечение безопасности мно-
жественных точек доступа. Конечно, администратор сети и менеджер по бе-
зопасности данных должны понимать, что ограничение доступа одним узлом
может привести к узким местам в потоке данных и эта потенциальная про-
блема является аргументом против единственной точки доступа. В больших
сетях может появиться необходимость создания нескольких таких точек, но
нужно всегда контролировать их количество.
О Разделение и изоляция проблем. Мы вскоре увидим, что многие компании ус-
танавливают несколько брандмауэров, которые выполняют различные функ-
ции. Они могут быть установлены друг за другом, и каждый будет иметь свои
настройки. В данном случае администратор может посчитать удобным такую
74
Глава 4. Брандмауэры
конфигурацию с тем, чтобы иметь возможность изолировать и затем решить
проблемы, возникающие с тем или иным брандмауэром.
А вот что брандмауэры не могут делать:
О Если враг внутри. Вне зависимости от того, насколько эффективен брандмау-
эр, он не может защитить предприятие от внутренней угрозы. И, как отмече-
но выше, такая угроза является одной из наиболее опасных для компании.
Важная информация, например, может быть скопирована сотрудником ком-
пании и передана вашим конкурентам или противникам. Это распространен-
ная проблема, для которой нет универсального решения. Правильным подхо-
дом к решению может быть взвешенная оценка работника и ограниченный
доступ к важной информации.
О Непредвиденные попытки взлома. Как было замечено в главе 1, Вирусный центр
IBM (IBM Virus Center) обнаруживает несколько новых вирусов каждый день
и хакеры со всего мира не устают изобретать новые методы атак. Брандмауэр
не ясновидец. Его эффективность напрямую связана с тем, как он сконфигу-
рирован. И если хакер придумает новый способ преодоления программ экра-
нирования (screening programs) брандмауэра (известных как «ленивый» бранд-
мауэр, что на самом деле обозначает, как правило, ленивого администратора),
то несанкционированный доступ будет получен.
О Проверка на вирусы не осуществляется. Говоря о вирусах, стоит заметить, что
брандмауэр доступа (внешний), как правило, не проверяет данные на нали-
чие вирусов. Как мы уже ранее обсуждали, брандмауэр не проверяет содер-
жимое IP-пакетов, а это именно то место, где могут находиться вирусы. Разу-
меется, такая возможность может быть встроена в брандмауэр, и вы можете
даже настроить один из ваших брандмауэров так, чтобы его единственной
задачей было обнаружение вирусов. Для брандмауэра доступа, показанного
на рис. 4.1, проверка данных на вирусы может стать непосильной задачей и,
в результате, существенно снизить производительность. Все чаще и чаще та-
кую задачу возлагают на внутренние (прокси-) брандмауэры.
Фильтрация пакетов
Одной из ключевых задач, выполняемых брандмауэрами, является фильтрация
пакетов. Этот термин обозначает операцию, когда определенные пакеты (также
называемые датаграммами — datagrams) пропускаются брандмауэром, а осталь-
ные — нет. Фильтрация основана на наборе правил, заданных в настройках бранд-
мауэра. Наиболее распространенным видом фильтрации с точки зрения обычно-
го роутера (router) выполняется на IP-датаграммах. Фильтрация может быть
осуществлена на основе: а) IP-адреса отправителя, б) IP-адреса получателя,
в) номера TCP- и UDP-портов отправителя, г) номера TCP- и UDP-портов получателя,
д) номера протокола, который находится в заголовке IP-пакета (IP Protocol ID).
Прокси-брандмауэры или брандмауэры приложений
75
И хотя эти виды фильтрации используются в большинстве дорогих роутеров, не
все .роутеры могут фильтровать на основе номеров порта. Более того, некоторые
роутеры используют исходящие сетевые интерфейсы для того, чтобы принять
решение о том, передавать ли ту или иную датаграмму.
Возможность фильтрации также зависит от того, какую операционную систему
вы используете. Например, некоторые реализации UNIX предоставляют такую
возможность, а некоторые нет.
На рис. 4.2 показан пример фильтрации пакетов, выполненной брандмауэром.
Данные приходят в брандмауэр из внешней сети и в этот момент являются неот-
фильтрованными*. После применения соответствующих правил данные будут
переданы во внутреннюю сеть, то есть будут отфильтрованы2. И, соответствен-
но, данные, которые не прошли фильтры брандмауэра, будут отвергнуты. В этой
ситуации данные, не прошедшие фильтры, стоит занести в журнал, так как впос-
ледствии их можно будет проанализировать — важный аспект при выявлении
возможных проблем.
Брандмауэр
Рис. 4.2. Фильтрация пакетов
Прокси-брандмауэры или брандмауэры
приложений
Применение всех фильтров на одном компьютере может быть слишком сложной
задачей. И даже если ее и можно решить, такая конфигурация может возложить
1 В некоторых источниках неотфильтрованными называют данные, которые не были обработаны
брандмауэром. -
2 Отфильтрованными также могут быть названы данные, которые не прошли фильтры и были
отвергнуты, так что будьте осторожны с этими терминами.
76
Глава 4. Брандмауэры
непосильную ношу на роутер. Другим решением может быть установка более чем
одного брандмауэра, который, как показано на рис. 4.3, выполняет определенно-
го рода фильтрацию и называется прокси-брандмауэр (proxy firewall) или шлюз
приложений (application gateway). Например, в упомянутом документе NCSA
говорится, что роутер мог бы передавать все пакеты TELNET и FTP на соответству-
ющий компьютер, который был бы специально выделен как шлюз приложений
TELNET/FTP. Такой шлюз мог бы выполнить все соответствующие последующие
фильтрации.
Рис. 4.3. Приложение (прокси-брандмауэр)
Пользователь, который хотел бы соединиться с внешней сетью, должен был бы
сначала соединиться со шлюзом приложений, а уж затем с конечным компьюте-
ром. Такой пользователь должен сначала соединиться по TELNET со шлюзом при-
ложений и ввести название компьютера внутренней сети, который желает соеди-
ниться с компьютером извне. Шлюз приложений проверяет IP-адрес отправителя
(в этой точке, пользуясь моментом, пользователь может быть спрошен о паро-
ле). Затем между шлюзом и пользовательским компьютером устанавливается
TELNET-соединение, после чего соединяются пользователь и конечный TELNET-узел.
Кроме того, брандмауэры приложений могут быть сконфигурированы таким
образом, чтобы разрешать или запрещать определенные действия. Первое, что
приходит на ум, — это запрещение некоторым пользователям возможности из-
менения данных на сервере. Например, посредством запрещения команды PUT
протокола FTP.
Документы National Computer Security Association (NCSA)
77
Документы National Computer Security
Association (NCSA)
NCSA опубликовала руководство о том, какие правила применяются к опреде-
ленным номерам портов различных протоколов [NCSA96]. Кроме того, допол-
нительную информацию можно*найти в [СНАР95]' и [GRAF92]1 2.
1. FTP, порт 69, простейший FTP, используемый для загрузки бездисковых рабочих
станций, серверов терминалов и роутеров, при неправильной конфигурации
может быть использован для чтения любого файла в системе.
2. X Windows, Open Windows, порт 6000+ и порт 2000 могут выдавать информацию,
изображенную в окне, включая все нажатия клавиш (хакеры могут даже
перехватить управление сервером через Х-сервер).
3. Remote Procedure Call (RPC), порт ill. Сервисы RPC, включая NIS и NFS, могут
быть использованы для получения системной информации, такой как пароли,
а также для операций чтения-записи.
4. rlogln, rsh и гехес, порты 513, 514 и 512, будучи неправильно настроенными,
могут позволить несанкционированный доступ к учетным записям и командам.
В документе NCSA95 также перечисляются протоколы, которые обычно
фильтруются и чье использование, возможно, должно быть ограничено только
определенными компьютерами.
5. TELNET, порт 23, часто разрешается только на определенных компьютерах.
6. FTP, порты 20 и 21, также как и TELNET, часто разрешается только на определенных
компьютерах.
7. SMTP, порт 25, часто разрешен только на центральном почтовом сервере.
8. RIP (Routing Information Protocol), порт 520, может быть обманут с тем, чтобы
перенаправить поток данных.
9. DNS (Domain Names Service), порт 53, содержит имена и адреса компьютеров,
что может быть использовано хакерами. Кроме того, существует возможность
внесения поддельных данных.
10. UUCP (UNIX-to-UNIX СоРу), порт 540, при неправильной настройке может быть
использован для несанкционированного доступа.
И. NNTP (Network News Transfer Protocol), порт 119, предназначен для обмена
новостями.
12. GOPHER и HTTP, порты 70 и 80, серверы и клиентские программы должны быть
ограничены шлюзами приложений, содержащими прокси-сервисы.
Общепринято, что FTP и TELNET должны быть разрешены только на определен-
ных компьютерах. В большинстве случаев далеко не все пользователи сети нуж-
1 |СНАР95|. Chapman, О. Brent. Building Internet Firewalls, O’Reilly & Assoc. 1995
2 [GRAF92], Garfmlde, Simson and Spafford, Gene. Practical UNIX Security, O’Reilly & Assoc. 1992
78
Глава 4. Брандмауэры
даются в доступе к данным протоколам. Следовательно, разрешение использо-
вания такого рода протоколов только на определенных машинах улучшает безо-
пасность и при этом не влечет за собой каких-либо дополнительных расходов.
И еще раз хочется акцентировать ваше внимание на том факте, что базовым под-
ходом должно быть запрещение любых операций, кроме тех, которые явно раз-
решены.
Управление брандмауэром (Managed
Firewall Service — MFWS)
MFWS — это относительно новое «оружие» в интернет-войнах. Организация,
предоставляющая такую услугу, берет на себя ответственность за настройку и
управление брандмауэрами компании-клиента, включая общее планирование всей
системы безопасности, покупку программ, установку, поддержку и даже управ-
ление ключевыми операциями.
При поиске поставщика услуг MFWS важно тщательно оценить персонал ком-
пании. Может оказаться, что больше всего нареканий вызывает отсутствие дос-
таточно глубокого понимания проблемы у их сотрудников. Хотя надо заметить,
что эта горестная жалоба раздается повсеместно, поскольку достаточно образо-
ванных в этой области людей просто не хватает. Тем не менее, если вам не повез-
ло с тем поставщиком услуг MFWS, который управляет вашим брандмауэром,
то тем самым вы можете получить множество проблем, что по сути означает дыры
в безопасности ваших данных. Позже мы вернемся к этой теме.
Как показано на рис. 4.4, поставщик услуг MFWS предоставляет клиенту два
варианта размещения брандмауэров: 1) у клиента; 2) у себя. Большинство их услуг
предоставляются поставщиком услуг Интернета, так что второй вариант обычно
влечет за собой размещение брандмауэра, например, в точке присутствия Ин-
тернет-провайдера. У каждого из вариантов есть свои плюсы и минусы.
Первый вариант хорош тем, что гораздо проще управлять ситуацией в том слу-
чае, когда брандмауэр расположен в точке доступа. Клиент в таком случае уве-
рен в том, что у него установлен выделенный брандмауэр с нужным набором
правил безопасности. У второго варианта плюсом является то, что клиенту не
нужно размещать оборудование и выделять людей, чтобы следить за брандмау-
эром. Однако второй вариант означает, что клиент разделяет свой брандмауэр с
другими. Но такое разделение не обязательно плохо. Оно может привести к мень-
шим задержкам и уменьшить количество серверов-посредников. При втором
варианте было бы неплохой идеей выяснить, как много клиентов имеет провайдер,
так как вы можете разделять канал передачи данных с другими (как это принято
в США, Европе, Азии и т. д.). Как показано на рис. 4.4, вариант, когда брандма-
уэр расположен у провайдера, имеет на самом деле две разновидности: бив.
Управление брандмауэром (Managed Firewall Service — MFWS)
79
Компания A
Компания В
б. У провайдера, разделяемый
Рис. 4.4. Управление брандмауэром (Managed Firewall Service — MFWS)
Оценка поставщика услуг MFWS
Используется несколько критериев, когда производится оценка провайдера
MFWS [MAKR99]1. Одним из соображений является доступность такой услуги,
что определяется тем, сколько центров сетевых операций (network operations
center — NOC) готовы предоставить такую услугу. Обычно эта цифра колеблет-
1 [MAKR99]. Markis, Joanna. “More Bark than Bite”, Data Communications, March, 1999, или обращайтесь
по адресу jmarkis@data.com
80
Глава 4. Брандмауэры
ся от единицы до шести. Другим важным критерием является поддержка раз-
личных технологий, таких как, например, Frame Relay, Х.25 и ATM.
Провайдер MFWS может осуществлять только фильтрацию доступа или прокси-
фильтрацию (фильтрацию приложений). Как обсуждалось ранее, потенциальный
клиент должен решить, какой вариант ему более подходит: локальный брандма-
уэр; удаленный брандмауэр; и если это удаленный брандмауэр, то должен ли это
быть выделенный или разделяемый брандмауэр.
Что касается стоимости, то предложения колеблются в значительной степени,
а цена может базироваться на количестве брандмауэров или пользователей. Не-
которые поставщики услуг просят дополнительные деньги за управление шиф-
рованием данных, у других стоимость определяется местоположением клиента.
Цена за брандмауэр может варьироваться от $500 за брандмауэр, при условии
небольшого количества пользователе^ до $20 000 при наличии нескольких со-
тен пользователей. Обычно все провайдеры включают в затраты поддержку уже
установленного оборудования.
Еще одно соображение, которое нужно, принять во внимание, — это выбор про-
граммного обеспечения для брандмауэра. Некоторые провайдеры предоставля-
ют свое собственное, другие покупают такие программы у соответствующих ком-
паний. Безусловно, было бы очень полезно проверить, какие возможности
предоставляет та или иная программа. /
Другим аспектом будет количество возможных изменений, которые вы можете
внести в параметры фильтров, и то, каким образом они передаются провайдеру.
Некоторые MFWS разрешают менять настройки фильтров сколько угодно, а дру-
гие могут потребовать дополнительные деньги, если количество изменений пре-
высило определенный уровень. Такие изменения могут быть переданы провай-
деру по электронной почте, по телефону, факсу и т. д., но сама процедура внесения
поправок разная у разных компаний.
Просмотрите договор на обслуживание на предмет гарантий доступности бранд-
мауэра, а также какой штраф полагается MFWS за различные «нарушения».
И убедитесь в компетентности провайдера и глубине знаний его работников!
Брандмауэры с протоколами
безопасности Интернета
(Internet Security Protocols — IPSec)
На рис. 4.5 и 4.6 показана модель, поддерживающая реализацию IPSec на бранд-
мауэре [RFC 2709]. Эти примеры операций в туннельном режиме, то есть в та-
ком, когда брандмауэры поддерживают туннельное соединение между собой.
На рис. 4.5 изображено, какие действия выполняет брандмауэр на исходящих
пакетах данных. Такой пакет проверяется на соответствие правилам безопасно-
SOCKS
81
сти. Как вы наверняка помните, такая проверка может быть произведена на ос-
нове IP-адреса, названия протокола и номера порта. Если пакет не прошел про-
верку, то он будет либо передан как есть, в незашифрованном виде, либо отбро-
шен. Если проверка пройдена, то пакет подвергается действиям, определяемым
правилами безопасности, принятыми для исходящего потока данных (в этом при-
мере — IPSec).
Исходящий
пакет
Рис. 4.5. IPSec и брандмауэр (исходящий пакет)
На рис. 4.6 показаны действия, выполняемые брандмауэром над входящим пакетом
данных. Зашифрованный пакет поступает в брандмауэр, где он расшифровыва-
ется. Затем этот IP-пакет проверяется на соответствие правилам безопасности
входящего потока данных. Если такая проверка пройдена, то пакет подвергается
действиям, определяемым правилами безопасности, принятыми для входящего
потока данных (здесь — IPSec). Если нет, то такой пакет отбрасывается.
Рис. 4.6. IPSec и брандмауэр (входящий пакет) ,
Отправить
пакет
дальше
SOCKS
SOCKS версии 4 — это процедура, обеспечивающая работу с брандмауэром для
приложений типа клиент — сервер, использующих TCP, включая TELNET, FTP, HTTP
и GOPHER. SOCKS версии 5 также включает поддержку UDP. SOCKS добавляет воз-
можность сильной проверки прав доступа и уЛучщает адресацию, включая име-
на доменов и 1Руб-адресацию [VANH99]1.
1 [VANH99]. www.ietf.org, требуется найти документ draft ietf-aft-SOCKS-pro-v5-04.
82 Глава 4. Брандмауэры
Когда TCP-клиент хочет установить соединение с объектом, который находится
позади брандмауэра, такой клиент должен установить TCP-соединение с соответ-
ствующим портом SOCKS на сервере. Такой SOCKS-сервис соответствует порту 1080
TCP. Если соединение установлено, то клиент вступает в переговоры о методе
проверки прав доступа, проверяет такие права и затем посылает запрос на пере-
направление потока данных. Сервер SOCKS рассматривает этот запрос и либо ус-
танавливает запрошенное соединение, либо отвергает его. В спецификации SOCKS
определены несколько методов проверки прав доступа. В этой книге (в главе 7)
описан один из них — CHAP. За дополнительной информацией обращайтесь
к [VANH99].
Заключение
Брандмауэры реализуют собой правила безопасности данных, принятые в ком-
пании. Брандмауэр размещается на компьютере, таком как сервер или роутер,
с тем чтобы анализировать и фильтровать поток данных, приходящий из внешних
сетей.
ГЛАВА
Распространенные
методы защиты
данных в Интернете
В этой главе будут обсуждены широко распространенные методы, используе-
мые в протоколах безопасности Интернета. Многие из этих методов разра-
ботаны помимо IETF1. Они встроены во многие системы защиты данных в Ин-
тернете и, в некоторых случаях, были опубликованы как RFC.
Нашим подходом в этой главе будет более глубокое обсуждение некоторых тем,
поднятых в главе 3. Мы сфокусируемся на том, как используются эти методы
в Интернете.
В предыдущих четырех главах мы постарались познакомить читателя с базовы-
ми понятиями, необходимыми для более'детального рассмотрения протоколов
безопасности Интернета. Как я уже упоминал ранее, эта книга не может являть-
ся учебником, покрывающим все аспекты безопасности сетей. Я не знаю ни од-
ной книги, которая могла бы претендовать на это. Тем не менее, для нас может
быть полезным остановиться ненадолго и посмотреть на то, что было сделано
важного в тех областях, что обсуждаются в этой и последующих главах. Мы нач-
нем с шифрования с открытыми ключами, представленного в главе 3, — метода,
который на многие десятилетия, а может и столетия, будет являться наиболее
революционным событием, произошедшим в системах безопасности. Мы не со-
бираемся повторять материал, пройденный в главе 3, а сразу же перейдем к тем
проблемам, которые имеют отношение к Интернету, ссылаясь в соответствую-
щих местах на уже изученный материал.
Из-за обилия подробностей, связанных с этим изложением, общим подходом в
этой главе будет общее описание проблемы и отсылка к приложению А для тех,
кто желает более подробно ознакомиться с кодом или алгоритмами.
* Internet Engineering Task Force — Проблемная группа проектирования Интернета, организация,
занимающаяся стандартизацией протоколов в Интернете. — Примеч. перев.
84
Глава 5. Распространенные методы защиты данных в Интернете
Диффи—Хеллман
Витфилд Диффи и Мартин Хеллман считаются основателями шифрования с
открытым ключом. Диффи и Хеллман публиковали работы об обмене открыты-
ми ключами в течение многих лет, и, в частности, в 70-х они обдумывали воз-
можность обмена ключами, которая бы исключала необходимость личной встре-
чи. Неэффективность была основной проблемой1.
Вопрос обмена ключами подобен собаке, пытающейся поймать свой собствен-
ный хвост. Пускай Алиса и Боб хотят установить между собой защищенный ка-
нал связи. Однако для того, чтобы создать такой канал, им необходимо обме-
няться секретным ключом, который они собираются использовать для
шифрования данных. Но как им передать ключ друг друху так, чтобы никто дру-
гой не узнал бы его? В старые добрые времена курьер из шпионского фильма
мог бы колесить по Европе, передавая такие ключи из рук в руки. Но как мы
обсуждали в главе 3, Диффи и Хеллман (так же как и Ральф Меркл) упорно на-
стаивалй на том, что существует и другой способ. Их исследования противоре-
чили здравому смыслу, а то, что они Пытались сделать, не было интуитивно по-
нятно, скорее даже наоборот. В 1976 году Хеллман разбил заколдованный круг.
В июне того же года доклад об их открытии был сделан на Национальной ком-
пьютерной конференции.
Оборачиваясь назад, можно сказать, что хотя это и было ошеломляющим дости-
жением, их идея обмена ключами имела некоторые проблемы. Но в этой части
мы сфокусируемся на их достижении, их открытии, а последующие улучшения
мы рассмотрим позже.
. Мы уже упоминали в главе 3, что Диффи разработал концепцию асимметрич-
ных ключей, когда для шифровки и дешифровки используются неодинаковые
ключи. Более того, эти исследователи сосредоточились на односторонней функ-
ции (такой, которая легко дает результат для данного аргумента, но для которой
очень трудно выполнить обратную операцию, то есть для данного результата
вычислить аргумент). Это мы тоже обсуждали в главе 3. Эта идея очень важна,
поскольку она дает нам уверенность в том, что даже если хакер сможет перехва-
тить данные, то он будет не в состоянии собрать достаточно информации для
взлома и получения ключа, используемого для шифровки.
Однако исследователи не нашли доказательного пути реализации односторон-
ней функции асимметричного шифрования. Рональд Ривест, Ади Шамир и Лео-
нард Адлеман считаются создателями такого алгоритма, известного как RSA (по
1 В 60-х годах я служил шифровальщиком в Военно-морском флоте США. И одной из моих задач
была работа курьером. Периодически я перевозил секретные ключи из различных коммуникационных
центров (так называемых «шнфрокают» - «crypto shacks»), расположенных в странах Дальнего Востока,
на мой корабль. По уставу мне полагалось носить личное оружие, когда я находился в пути от моего
корабля до такого центра. Также ядолжен был пристегивать к руке наручникамичемоданс секретными
материалами. Я Иногда думая о том, смогут ли остановить эти наручники кого-либо, кто захотел бы
заполучить мою ношу.-И если бы я знал в те дни о существовании открытых ключей, я бы наверняка
был бы за их использование.
Диффи—Хеллман
85
первым буквам их фамилий: Rivest, Shamir, Adleman). Мы скоро поговорим об
их открытии. Но сейчас давайте вернемся к открытию Диффи—Хеллмана и об-
судим, как оно применяется в протоколах безопасности Интернета.
Диффи—Хеллман и RFC 2631
В стандарте RFC 2631 (ссылающемся на ANSI Х9.42) были изложены идеи Диф-
фи-Хеллмана в приложении й Интернету. Согласно этой спецификации, прове-
дение операций с ключами Диффи—Хеллмана требует как от отправителя, так и
от получателя иметь соответствующие’ пары ключей. Как уже было объяснено в
главе 3, при помощи своего индивидуального ключа и открытого ключа другого
обе стороны могли вычислить разделяемый секретный ключ. Это число может
быть затем конвертировано в так называемый криптографический материал клю-
чей (cryptographic keying material). Этот материал ключей обычно служит клю-
чом для шифровки ключей (key-encryption key — КЕК), применяемым для шиф-
рования ключа шифровки данных (content-encryption key — СЕК), которой, в свою
очередь, и используется для шифрования сообщений. Если вам не совсем ясно,
о чем идет речь, посмотрите на рис. 3.3 и 317 из главы 3.
Согласование ключей. Первой стадией в цроцессе согласования ключей являет-
ся вычисление разделяемого секретного чцсла, называемого ZZ. Когда использу-
ются одни и те же пары чисел индивидуального и открытого числа отправителя
и получателя, то получается одно и то же число. ZZ затем преобразовывается в
разделяемый симметричный ключ. Когда отправитель использует одну и ту же
статическую пару из индивидуального и открытого ключей, то и получаемый ре-
зультат будет один и тот же, поэтому использование открытого случайного чис-
ла будет гарантировать, что получаемый симметричный ключ будет разным для
каждой операции согласования. Обобщение этого материала вы можете найти
во врезке.
ANSI Х9.42 определяет, что разделяемый секретный код 11 генерируется следующим образом:
11- д А (xb * ха) mod р
Стороны выполняют на самом деле следующие вычисления:
11-(yb А ха) mod р - (ya А xb) mod р,
где знак А обозначает возведение в степень, а переменные обозначают следующее:
1. уа — это открытый ключ стороны а; ya - д А ха mod р
2. уЬ — это открытый ключ стороны b; yb д А xb mod р
3. ха — это индивидуальный ключ стороны а2
4. xb — это индивидуальный ключ стороны Ь
5. р — это как можно большое простое число
6. q — это как можно большое простое число
7. д - Н А {(р — 1) / q) mod р; где Н — любое целое число, причем 1 < Н < р-1 так, что Н{(р-1) / q) mod
р > 1 (д имеет степень q mod р, то есть д А q mod р -1 если д !-1)
8. j большое целое число, такое что р - qj +1
86
Глава 5. Распространенные методы защиты данных в Интернете
Генерирование материала ключей. Х9.42 определяет алгоритм получения из ZZ
неограниченного количества материала ключей. На основе этого стандарта со-
здан алгоритм, описанный в RFC 2631, путем явного определения необязатель-
ных значений:
км - H(ZZ 11 Otherlnfo)
Н — это функция получения дайджеста сообщения SHA-1 (см. FIPS-180, кроме
того, она будет обсуждаться позднее). ZZ — разделяемое секретное число. Ведущие
нули должны сохраняться с тем, чтобы ZZ занимало такое же количество бит, что
и р. Например, если длина р равна 1024 битам, то и ZZ должно быть 1024 бита
длиной. Otherlnfo является закодированной структурой следующего вида:
Otherlnfo ::- SEQUENCE {
keyinfo KeySpedficInfo.
partyAInfo [0] OCTET STRING OPTIONAL.
suppPublnfo [2] OCTET STRING
}
KeySpedficInfo ::- SEQUENCE {
algoritm OBJECT IDENTIFIER
counter OCTET STRING SIZE (4..4)
}
Счетчик объектов (counter) — это 32-битное число (сетевой порядок байт). Его
начальное значение равно 1 для любого ZZ, то есть в шестнадцатеричном пред-
ставлении 00 00 00 01, и это число увеличивается каждый раз, когда упомянутая
выше генерирующая функция выполняется для данного КЕК. Объект partyAInfo
является необязательной случайной строкой, полученной от отправителя. Если
она задана, то partyAInfo должна иметь длину 512 бит. Объект suppPublnfo равен
длине в битах сгенерированного КЕК, представленного как 32-битное число с се-
тевым порядком байт.
Для того чтобы сгенерировать КЕК, необходимо создать один или больше КМ бло-
ков (увеличивая соответственно счетчик), до тех пор, пока не будет сгенериро-
вано необходимое количество материала. Эти КМ блоки конкатенируются слева
направо, то есть КМ (счетчик - 1) || КМ (счетчик - 2) и т. д.
Вычисление КЕК. Каждый алгоритм шифрования ключей требует ключи опреде-
ленного размера — п. КЕК генерируется путем отображения в ключ левых п байт
КМ. В 3DES (описанном в главе 6, рисунок 6.9), который требует 192 бита мате-
риала ключей, этот алгоритм выполняется дважды, один раз при счетчике, рав-
ном 1 (для генерации КГ, К2' и первых 32 бит К3')> и второй раз при счетчике,
равном 2 (для генерации последних 32 бит КЗ’). КГ, К2' и КЗ' затем выравнива-
ются по четности и из них генерируются 3 DES ключей KI, К2 и КЗ. В RC2-128,
в котором требуется 128 бит материала ключей, этот алгоритм выполняется один
раз, со счетчиком, равным 1, и левые 128 бит напрямую преобразовываются в
ЕС2-ключ. Таким же образом в RC2-40, в котором требуется 40 бит материала
ключей, этот алгоритм выполняется один раз, со счетчиком, равным 1, и левые
128 бит используются как ключ.
Ривест, Шамир и Адлеман (RSA)
87
Ривест, Шамир и Адлеман (RSA)
Вклад Диффи—Хеллмана—Меркла в теорию обмена ключей неоспорим. Тем не
менее, как мы уже обсуждали в главе 3, хоть их идеи и были работоспособны,
все же они были далеки от совершенства. Недостающее звено цепи было найде-
но в работах Рональда Ривеста, Ади Шамира и Леонарда Адлемана.
Эта группа работала в 70-х годах в MIT* на кафедре компьютерных наук, прово-
дя различные исследования. Они заинтересовались асимметричными шифрами
после того, как Рон Ривест принес как-то работу Диффи и Хеллмана. После года
исследований и поиска доказательств они пришли к своему открытию. Если вы
пропустили главу 3, то вам полезно будет прочитать один из ее разделов под
названием «Следующий шаг: RSA».
RSA в RFC 2437
Нельзя изложить содержание RFC 2437 в конспективной форме. Лучше всего будет
описать то, как р RFC 2437 используются открытые и индивидуальные ключи.
Открытые ключи в RSA. В RSA открытые ключи состоят из двух частей: 1) п,
модуль, неотрицательное целое число и 2) е, степень, неотрицательное целое число.
В правильном открытом ключе RSA модуль п является произведением двух про-
стых чисел р и q, а степень е — это число между 3 и п - 1, удовлетворяющее
gcd(e. \lambda(n)) - 1. где \lambda(n) - len (р - l.q - 1).
Индивидуальные ключи в RSA. В RSA индивидуальные ключи могут иметь одно
из двух представлений. Первое представление состоит из пары (n. d), где компо-
ненты означают следующее: 1) п, модуль, неотрицательное целое число и 2) d,
степень, неотрицательное целое число. Другим представлением является пятер-
ка (р, q, dP. dQ. qlnv), где компоненты имеют следующее значение:
О р — первый фактор, неотрицательное целое число;
О q — второй фактор, неотрицательное целое число;
О dP — степень первого фактора, неотрицательное целое число;
О dQ — степень второго фактора, неотрицательное целое число;
О qlnv — коэффициент CRT, неотрицательное целое число.
В правильном индивидуальном ключе RSA (первое представление) модуль п, так
же как и для открытого ключа, является произведением двух простых чисел р и q,
а степень d — это позитивное целое число, меньше п, удовлетворяющее ed \equiv 1
(mod \1ambda(n)), где е — это соответствующая степень открытого ключа и \1 ambda(n).
В правильном индивидуальном ключе RSA (второе представление) р и q явля-
ются простыми числами, из которых получается п, а степени dP и dQ - позитив-
ные целые числа, меньше р и q, соответственно, и удовлетворяющие следующим
условиям:
1 Massachusetts Institute of Technology (Массачусетский технологический институт). — Примеч. перев.
88
Глава 5. Распространенные методы защиты данных в Интернете
e(dP)\equiv l(mod(p - 1))
e(dQ)\equiv l(mod(q - 1))
Коэффициент CRT qlnv является целым положительным числом, меньше р,
удовлетворяющим следующему условию:
q(qlnv)\equ1v l(mod р)
Если вы хотите узнать больше о ключах RSA, чем можно найти в этом обсуждении,
то в RFC 2437, раздел 11.1.2, вы можете найти синтаксис, используемый в
различных реализациях индивидуальных ключей RSA, включая компоненты обоих
представлений.
MD5
MD5, алгоритм получения дайджеста сообщений (опубликованный в RFC 1321
Ронрм Ривером), являемся щироко применяемой хэш-функцией. В последние
несколько лет его критикуют за неустойчивость к атакам, кроме того, известен
тот факт, что возможно найти два различных текста, которые дадут один и тот
же дайджест. Несмотря на эти проблемы, я хочу обратить ваше внимание на этот
алгоритм по двум причинам. Во-первых, MD5 может быть защищен при помощи
операции, называемой проверка сообщений с хэшированием по ключам (Keyed
Hashing for Message Authentication — HMAC), и MD5-HMAC не подвержен та-
ким атакам. Во-вторых, MD5 используется во многих маршрутизаторах для за-
щиты различных протоколов, таких как RIP, OSPF и BGP. В этой главе мы даем
лишь краткое описание RFC 1321, а в приложении А вы можете найти дополни-
тельную информацию.
Алгоритм MD5 был разработан для 32-битных компьютеров. Он является рас-
ширением MD4, и сделанные улучшения мы вскоре обсудим. Этот алгоритм
принимает на входе сообщение любой длины и на выходе дает 128-битный дай-
джест сообщения. Входные данные обрабатываются блоками по 512 бит (16 32-
битных слов). Эта операция была разработана для цифровых подписей и состо-
ит из 5 действий:
Шаг 1: Добавление дополняющих битов. Как видно на рис. 5.1, сообщение до-
полняется (1с последующими 0, с максимальной длиной в 512 бит) так, что длина
сообщения всегда на 64 бита меньше, чем ближайшее целое число, кратное 512.
Исходное сообщение 100....00 Длина исходного сообщения
Рис. 5.1. Дополнение длины сообщения
Шаг 2: Добавление длины сообщения. На рис. 5.1 также показан результат шага
2, когда добавлена 64-битная длина сообщения (до того, как были добавлены
дополняющие биты). В случае если исходное сообщение больше, чем 264, исполь-
зуются только младшие 64 разряда длины сообщения. Итогом шага 2 является
результирующее сообщение, кратное 512 и, соответственно, кратное 16 32-бит-
MD5 89
ним словам. Пусть M[O?N-1] обозначают слова в результирующем сообщении, где
N - число, кратное 16. Таким образом N=L?16.
Шаг 3: Инициализация MD-буфера. Буфер длиной 128 бит (представляемый как
4 32-битных регистра) используется для хранения результатов хэш-функции MD5.
Эти регистры, называемые А, В, С и D, инициализируются следующими шестнад-
цатеричными значениями (младшие разряды идут первыми):
регистр A: 01 .23 45 67
регистр В: 89 АВ CD EF
регистр С: FE DC BA 98
регистр D: 76 54 32 10
Шаг 4: Обработка сообщения блоками по 512 бит (по 16 32-битных слов). Ос-
новные действия выполняются на этом шаге и состоят из 4 циклов (или прохо-
дов), осуществляемых над каждым 512-битным блоком сообщения. Процесс ис-
пользует различные константы для каждого блока на каждом цикле. 4 прохода
по 16 слов дают 64 32-битные константы. Эти значения хранятся в табличной
форме, называемой таблицей Т (Table Т). Вы можете найти эту таблицу в прило-
жении А. Таблица Т основана на синус-функции, и для любопытствующих при-
веду функцию вычисления этих констант: [KAUF95]1.
Затем вступают в работу четыре вспомогательные функции, каждая из которых
принимает в качестве аргумента 3 32-битных слова и дает в результате одно 32-бит-
ное слово. Проходы используют различную структуру, как показано ниже (и
обозначаются как F, G, Н и I):
F(X.Y.Z) - XY v not(X) Z
G(X.Y.Z) - XZ v Y not(X)
H(X.Y.Z) - X x or Y x or Z , f
I(X.Y.Z) = Y x or (X v not(Z))
В RFC 1321 описываются действия для Каждого прохода, а также приводятся
примеры кода. В приведенном участке кода, также взятом из RFC 1321,
объясняется алгоритм обработки на шаге 4.
/* Process each 16-word block. */
For 1 - 0 to N/16-1 do ।
/* Copy block 1 into X. */
For j - 0 to 15 do
Set X[j] to M[i*16+j].
end /* of loop on j */
/* Save A as AA. В as BB. C as CC. and D as DO. */
AA - A
BB - В
1 [KAUF95]. Kaufman, Charlie, et al., Network Security: Private Communication In a Public World, Prentice
Hall, 1995.
90
Глава 5. Распространенные методы защиты данных в Интернете
сс - С
DD - D
/* Round 1. */
/* Let [abed К s т] denote the operation
a - b + ((a + F(b.c.d) + X[K] + T[i]) «< s). */
/* Do the following 16 operations. */
[ABCD 071] [DABC 1 12 2] [CDAB 2 17 3] [BCDA 3 22 4]
[ABCD 475] [DABC 5 12 6] [CDAB 6 17 7] [BCDA 7 22 B]
[ABCD 879] [DABC 9 12 10] [CDAB 10 17 11] [BCDA 11 22 12]
[ABCD 12 7 13] [DABC 13*12 14] [CDAB 14 17 15] [BCDA 15 22 16]
/* Round 2. */
/* Let [abed К s 1] denote the operation
a - b + ((a + G(b.c.d) + X[K] + T[iJ) «< s). */
/* Do the following 16 operations. */
[ABCD 1 5 17] [DABC 6 9 IB] [CDAB 11 14 19] [BCDA 0 20 20]
[ABCD 5 5 21] [DABC 10 9 22] [CDAB 15 14 23] [BCDA 4 20 24]
[ABCD 9 5 25] [DABC 14 9 26] [CDAB 3 14 27] [BCDA 8 20 2B]
[ABCD 13 5 29] [DABC 2 9 30] [CDAB 7 14 31] [BCDA 12 20 32]
/* Round 3. */
/* Let [abed К s t] denote the operation
a - b + ((a + H(b.c.d) + X[K] + T[1 J) <« s). */
/* Do the following 16 operations. */
[ABCD 5 4 33] [DABC 8 11 34] [CDAB 11 16 35] [BCDA 14 23 36]
[ABCD 1 4 37] [DABC 4 11 3B] [CDAB 7 16 39] [BCDA 10 23 40]
[ABCD 13 4 41] [DABC 0 11 42] [CDAB 3 16 43] [BCDA 6 23 44]
[ABCD 9 4 45] [DABC 12 11 46] [CDAB 15 16 47] [BCDA 2 23 48]
/* Round 4. */
/* Let [abed К s t] denote the operation
a - b + ((a + I(b.c.d) + X[K] + T[iJ) «< s). */
/* Do the following 16 operations. */
[ABCD 0 6 49] [DABC 7 10 50] [CDAB 14 15 51] [BCDA 5 21 52]
[ABCD 12 6 53] [DABC 3 10 54] [CDAB 10 15 55] [BCDA 1 21 56]
[ABCD В 6 57] [DABC 15 10 5B] [CDAB 6 15 59] [BCDA 13 21 60]
[ABCD 4 6 61] [DABC 11 10 62] [CDAB 2 15 63] [BCDA 9 21 64]
/* Then perform the following additions. (That 1s Increment each
of the four registers by the value it had before this block
was started.) */
A - A + AA
В - В + BB
C - c + cc
D - D + DD
end /* of loop on 1 */
Шаг 5: Последний шаг, на котором получается результат обработки всех L
512-битных блоков.
Подвержен ли MD5 атакам?
По словам автора этого алгоритма, Рона Ривеста, MD5 был разработан в следу-
ющих целях: «Предполагается, что это невозможно, с вычислительной точки эре-
RFC 2537: RSA, MD5 и DNS 91
ния, создать два сообщения с одним и тем же дайджестом или создать сообще-
ние, имеющее заданный дайджест».
Разумеется, крайне маловероятно, что два выбранных случайным образом сооб-
щения после применения хэш-функции дадут в результате одинаковый хэш-код.
Однако несколько исследователей нашли слабые места в MD5. И хотя этот алго-
ритм остается наиболее известным в Интернете средством получения дайджеста
сообщения, существуют и другие, более устойчивые к атакам, альтернативы, ко-
торые мы обсудим далее. А тем из вас, кто хотел бы более глубоко покопаться
в «проблемах» MD5, я рекомендую [DOBB96]1.
Однако перед тем, как следовать далее, необходимо акцентировать ваше внима-
ние на том, что именно MD5 скорее всего будет и впредь оставаться предпочти-
тельным алгоритмом получения дайджеста сообщения, поскольку в IPSec опре-
делено его использование с НМАС-проверкой сообщений при помощи
хэширования ключей, описанной в RFC 2104. Мы рассмотрим НМАС в этой главе
позднее.
RFC 2537: RSA, MD5 и DNS
DNS (Domain Name Server — служба имен доменов) — это глобальная база дан-
ных, предназначенная для адресации в Интернете и других функций. DNS была
модифицирована с тем, чтобы включать в себя цифровые подписи и криптогра-
фические ключи, как описано в RFC 2535. Таким образом, DNS теперь может
быть безопасной и использоваться для распространения ключей. В RFC 2537 опи-
сывается, как хранить в DNS RSA-ключи и основанные на RSA/MD5 подписи.
RSA-алгоритмы рекомендованы для реализации в DNS. Вот краткое содержание
RFC 2537.
Открытые ключи RSA и DNS
Открытые ключи RSA хранятся в DNS под названием KEY Resource Records
(RR — ресурсная запись ключа), при этом используется алгоритм 1 из RFC 2535.
Структура зависящей от алгоритма части раздела RD АТА ресурсной записи при-
ведена ниже.
Поле Ример
Длина показателя степени 1 или 3
Показатель степени В зависимости от длины поля
Модуль Оставшееся пространство
В настоящее время, в целях совместимости, показатель степени и модуль огра-
ничены 4096 битами на каждое значение. Показатель степени открытого ключа
является беззнаковым целым переменной длины. Его длина в байтах находится
1 [DOBB96], Dobbertin, Н, et al., The status of MD5 after a recent attack, Crypto-Bytes, Summer, 1996.
92
Глава 5. Распространенные методы защиты данных в Интернете
в байте 1, если она не превышает 255, и байте 0, за которым следует 2 байта,
интерпретируемых как беззнаковое целое, если длина больше 255 байт. Поле
модуля открытого ключа является большим беззнаковым целым. Длина моду-
ля может быть определена при помощи RDLENGTH и предыдущих полей
RDATA, включая показатель степени. В значениях степени и модуля запреще-
ны ведущие 0.
Подписи RSA/MD5 в DNS
Раздел подписи в области SIG RR RD АТА, если он вычисляется при помощи
алгоритма RSA/MD5, показан ниже. Подписанные данные определяются согласно
RFC 2535.
hash » MD5 (data)
signature - ( 00 | 01 | FF* | 00 | prefix | hash) ** е (mod n)
Где MD5 — это алгоритм получения дайджеста сообщения. Как описано в RFC
1321, знак | обозначает конкатенацию, е — это показатель степени индивидуаль-
ного ключа человека, подписавшего документ, и п — это модуль его индивиду-
ального ключа. 01, FF и 00 — это шестнадцатеричные константы, prefix — это
префикс указателя алгоритма ASN.l BER MD5, который равен в шестнадцате-
ричном виде:
3020300c06082a864886f70d020505000410
Размер п, включая все значащие биты (то есть равные 1), должен быть не мень-
ше 512 и не больше 4096 бит. п и е должны быть выбраны таким образом, что
открытый показатель степени является небольшим. В алгоритме подписи RSA/
MD5 разрешены ведущие 0 байты.
Соображения по поводу эффективности
В общем случае скорость создания подписи примерно одинакова для RSA и DSA
[RFC 2536]. С учетом достаточных предварительных вычислений, генерирова-
ние подписи в DSA быстрее, чем в RSA. Создание ключей также быстрее в DSA.
Однако проверка подписи на порядок медленнее в DSA, в случае если открытый
показатель степени RSA выбран небольшим, как это и рекомендовано для KEY
RR, используемых для проверки данных в DNS.
Стандарт защищенного хэширования
(SHA-1) и алгоритм защищенного
хэширования
Алгоритм защищенного хэширования (Secure Hash Algorithm — SHA), чаще все-
го упоминаемый как стандарт защищенного хэширования (SHA-1), был опубли-
I Сравнение MD, SHA-1, RIPEMD-160 и MD5-HMAC 93
I
кован Национальным Институтом стандартов и технологии США (US National
Institute of Standards and Technology — NIST). Он основан на предшественнике
MD5 — алгоритме MD4. Основным различием между SHA-1 и этими MD-алго-
ритмами является то, что SHA-1 генерирует 160-битный дайджест сообщения, в
то время как MD-алгоритмы создают 128-битный. Более длинный дайджест делает
SHA-1 более устойчивым к взлому и подделке. SHA-1 требует больше времени
для создания дайджеста, однако он является одним из наиболее широко рас-
пространенных алгоритмов (вместе с MD5) из-за его надежности. И хотя SHA-1 .
является более сильным алгоритмом, комбинация MD5 и НМАС тоже достаточ-
но надежна и к тому же вычисляется быстрее, чем SHA-1. Скорость вычислений
очень критична, поскольку каждый пакет данных, входящий или выходящий из
системы, требует отдельного выполнения алгоритма. За дополнительной инфор-
мацией о SHA-1 обращайтесь к NIST FIPS PUB 180.
RIPEMD-160
Из-за проблем, связанных с MD4 и MD5, европейская организаций RACE Integrity
Primitives Evaluation (RIPE) разработала стандарт RIPEMD-160. Он также был
разработан на основе MD4, но генерирует дайджест длиной 160 бит. Однако так
же как и SHA-1, этот алгоритм значительно менее эффективен, чём MD5.
Сравнение MD5, SHA-1, RIPEMD-160
и MD5-HMAC
- (•'
В таблице 5.1 вы можете сравнить основные возможности MD5, SHA-1 и
RIPEMD-160 [STAL99], В таблице 5.2 прйведены оценки производительности
некоторых из популярных хэш-алгоритмов [DAI99]1. Алгоритм MD5-HMAC будет
обсуждаться в этой главе чуть позже, а здесь включен только для иллюстрации
того факта, что комбинация НМАС и MD5 делает производительность MD5 хуже,
чем SHA-1 и RIPEMD-160. .... . п
Таблица 5.1. Сравнение защищенных хэш-функций [DAI99]
Шифр Размер в байтах Время (сек.) Байт в секунду
MD5 2147 483 648 37.534 57 214 356
SHA-1 536 870 912 21.12 25 4.20 02,4.. . .
RIPEMD-160 536 870 912 22.232 24148 566
MD5-HMAC 1073 741824 21.491 49 962 396
1 (DAI99]. Dai, Wei. http://www.eskimo.com/~weidai/benchmark.html
94
Глава 5. Распространенные методы защиты данных в Интернете
Таблица 5.2. Сравнение MD5, SHA-1 и RIPEMD-160 [STAL99]
Параметр 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
Порядок байтов Обратный Прямой Обратный
Все эти алгоритмы были запрограммированы на языке C++ или были конверти-
рованы в этот язык; из С-кода, скомпилированы при помощи Microsoft Visual
C++ 6.0 SP2 (оптимизированного по скорости, генерация кода для процессора
Pentium Pro), и выполнены на компьютере Celeron 450 МГц с операционной
системой Windows 2000 beta 3. Ассемблер не использовался.
НМАС
Мы упоминали НМАС в этой книге уже много раз. В этом разделе мы рассмот-
рим этот алгоритм более подробно. Во-первых, НМАС опубликован в RFC 2104,
и его авторами являются Хьюго Кравчик, Михир Беллар и Ран Канетти, кото-
рые предоставили примеры кода НМАС, приведенные, в приложении А. НМАС
является хэш-функцией ключей. IPSec требует, чтобы все проверки сообщений
выполнялись при помощи этого алгоритма. RFC 2104 определяет цели разработ-
ки НМАС следующим образом (я цитирую):
1. Для того чтобы использовать без изменений существующие хэш-функции.
В особенности такие хэш-функции, которые имеют эффективные алгоритмы
и код которых широко доступен и распространяется бесплатно.
2. Для того чтобы сохранить исходную производительность такой хэш-функции
без существенного снижения эффективности.
3. Для того чтобы дать возможность использовать ключи простым образом.
4. Для того чтобы предоставить понятный криптографический анализ прочности
использованного механизма проверки, основанный на осмысленных пред-
положениях об используемой хэш-функции.
5. Для того чтобы позволить простую замену используемой хэш-функции в случае,
если будет найдена или понадобится более быстрая или надежная хэш-функция.
Производительность и надежность НМАС
95
Одной из уникальных особенностей НМАС является использование вложенных
хэиропераций ключей, одна внутри другой. Эта идея основана на использовании
двух дополняющих значений (pad values), одно из которых называется внутренним
(ipad), а другое внешним (opad), которые применяются в хэш-алгоритме Н,
выполняемом над сообщением М, с использованием ключа К.
НМАС (К. М) - Н(К XOR opad. Н(К XOR ipad. М))
где В — число бит в блоке, ipad 7 байт 0x36, повторенный В раз, opad - байт 0x5с,
повторенный В раз. Это интерпретируется следующим образом:
1. Добавить нули в конец К для того, чтобы получить строку длиной В (например,
если К имеет длину 20 байт и В - 64, то к К будет добавлено 44 байта 0x00).
2. Операция «исключающее или» проводится над полученной в первом шаге
строкой и ipad.
3. Добавить входной поток данных к результату операции в шаге 2.
4. Применить Н к потоку данных, полученных в шаге 3.
5. Операция «исключающее или» проводится над полученной в первом шаге
строкой и opad.
6. Добавить результат шага 4 к результату шага 5.
7. Применить Н к потоку данных, полученных в шаге 6, и вывести результат.
Производительность и надежность НМАС
Замечательная оценка производительности и надежности НМАС сделана Стал-
лингсом. Я привожу цитату из его работы [STAL99]1:
Надежность любой МАС-функции, основанной на вложенной хэш-функции, зави-
сит некоторым образом от криптографической прочности этой хэш-функции. При-
тягательность НМАС определяется тем, что разработчики смогли доказать прямую
зависимость между надежностью вложенной хэш-функции и надежностью НМАС.
В большинстве случаев надежность МАС-функций выражается в вероятности
успешной фальсификации за данное время и при данном количестве пар сооб-
щение — МАС, созданных с использованием одного и того же ключа. По сути,
в [BELL96a] доказано, что при данном уровне усилий (время, пары сообщение —
МАС), если действия пользователя были подсмотрены фальсификатором, то ве-
роятность успешной атаки на НМАС равна такой вероятности для одного из сле-
дующих видов атак на вложенную хэш-функцию:
1. Атакующий способен вычислить результат сжимающей функции, даже если IV
является случайным, скрытым или неизвестным атакующему.
1 [STAL99]. Stallings, William. Cryptography and Internet Security. Prentice Hall, Upper Saddle River, NJ
1999. Это еще одна прекрасная книга о безопасности. Как видно из цитат, приведенных в этой книге,
Сталлингс написал наилучший трактат о теории и математическом обосновании данного предмета.
Если же вы хотите увидеть общую картину (и получить более легкое чтение), то книга Сигха
(цитируемая в главе 3) будет самым лучшим выбором.
96
Глава 5. Распространенные методы защиты данных в Интернете
2. Атакующий находит данные, дающие тот же результат хэш-функции, даже если
IV является случайным или скрытым.
В случае атаки первого вида мы можем рассматривать сжимающую функцию как
эквивалент хэш-функции, примененной к сообщению, содержащему один h-битный
блок. При такой атаке IV хэш-функции заменяется на скрытое случайное значе-
ние в п бит. Атака на такую хэш-функцию требует либо решения «в лоб», то есть
перебором, что требует усилий порядка 2П итераций, либо атаку «день рождения»,
которая является особым случаем атаки второго типа, обсуждаемой ниже.
В случае атаки второго вида атакующий ищет два сообщения М и М', которые дают
один и тот же хэш-код: Н(М)-Н(М’). Это так называемая атака «день рождения».
Мы показали, что это требует усилий порядка 2П/2 итераций для хэш-кода длиной
п бит. С учетом этого надежность MD5 находится под вопросом, поскольку при
нынешнем развитии техники вычисления в 2е4 итераций не являются проблемой.
Значит ли это, что 128-битная хэш-функция, такая как MD5, не подходит для
НМАС? Ответ будет — «нет». Причина тому следующая: для того чтобы атаковать
MD5, атакующий может выбрать любой набор сообщений и работать с ними на
автономном компьютере, с тем чтобы найти сообщение, дающее тот же самый хэ-
ш-код. Поскольку атакующий знает хэш-алгоритм и значение по умолчанию для
IV, то он. может сгенерировать хэш-код для каждого созданного им сообщения.
Однако когда атака направлена на НМАС, атакующий не может сгенерировать пары
сообщение/хэш-код, работая в автономном режиме, так как он не знает К. Следо-
вательно, для успешной атаки на данные атакующий должен иметь доступ к по-
следовательности сообщений, созданных при помощи НМАС с использованием
одного и того же ключа. Для хэш-кода длиной 128 бит это требует анализа 2м
блоков, то есть 2” бита, созданных с использованием одного и того же ключа. При
соединении в 1Гбит для получения достаточного количества данных нужно было
бы непрерывно получать данные в течение 2 250 000 лет, при условии неизменно-
го ключа. Таким образом, если скорость критична, то использование MD5 в каче-
стве вложенной хэш-функции НМАС абсолютно приемлемо.
НМАС и IPSec
Согласно стандартам Интернета, НМАС предназначен для работы с двумя
IPSec-протоколами:
1. Идентифицирующий заголовок (Authentication Header — АН);
2. Вложенные защищенные передаваемые данные (Encapsulating Security Pay-
load - ESP).
Эти протоколы описаны в главе 9, в разделе «Применение НМАС в АН и ESP».
Протокол определения ключей OAKLEY
97
Протокол определения ключей OAKLEY
Описание этого протокола, OAKLEY, дано в RFC 2412 [ORMA98]1. Этот протокол
определяет, каким образом две стороны договариваются о материале ключей.
Основой протокола OAKLEY является алгоритм обмена ключами Диффи—Хеллма-
на. Этот протокол поддерживает: а) секретность; б) совместимость с протоколом
БАКМР по управлению ассоциациями безопасности; в) определяемые пользова-
телем абстрактные структуры групп, используемые с алгоритмом Диффи—Хел-
лмана; г) обновление ключей.
У протокола OAKLEY имеется много свойств, а кроме того, он предоставляет сво-
им пользователям неплохую гйбкость в конфигурировании своих действий по
обеспечению безопасности в отношении материала ключей.
Далее мы вкратце обсудим RFC 2412 и то, как он используется с протоколом
ассоциаций безопасности и управления ключами Интернета (Internet Security
Association and Key Management Protocol — ISAKMP) и протоколом обмена клю-
чами в Интернете (Internet Key Exchange Protocol — IKE), которые будут обсуж-
даться в следующих главах. Но сначала несколько слов о двух протоколах, лежа-
щих в основе OAKLEY.
Алгоритм обмена ключами Диффи—Хеллмана позволяет двум сторонам догово-
риться о разделяемом секретном значении без использования шифрования. Это
значение может быть тут же использовано для обработки потока данных с це-
лью их шифровки или для удостоверения их подлинности. Протокол STS рпреде-
ляет, как встроить такой алгоритм в протокол безопасности. STS обеспечивает
сохранность разделяемого секрета и подлинность соединяющихся сторон.
OAKLEY — это протокол обмена ключами общего вида, и генерируемые им ключи
могут быть использованы для шифрования данных, которые должны быть со-
хранны в течение долгого периода (как определено в RFC 2412, в течение 20 и
более лет). У этого протокола есть две возможности увеличения его устойчивости
к атакам со стороны лица, у которого имеется большой набор записанных транз-
акций по обмену ключами (так называемый пассивный атакующий). Эти возмож-
ности полезны при получении ключей, предназначенных для шифрования.
Протокол ISAKMP будет описан в главе 10 и предоставляет поля для определения
параметров ассоциаций безопасности (Security Association — SA), предназначен-
ных для использования в протоколах АН и ESP в IPSec. Эти типы полезной на-
грузки ассоциаций безопасности определены в спецификациях ISAKMP, типы по-
лезной нагрузки могут быть защищены при помощи алгоритмов и материала
ключей OAKLEY.
В процессе изложения особенностей протокола OAKLEY я буду упоминать и про-
токол ISAKMP. Возможные пробелы в их взаимоотношениях будут восполнены
в главе 10.
1 [ORMA98]. Orman, Н. The OAKLEY Key Determination Protocols RFC 2412, November, 1998.
98
Глава 5. Распространенные методы защиты данных в Интернете
За пределами Диффи—Хеллмана и STS
Протокол OAKLEY находится в родстве с STS. Кроме того, он использует сходную
с Диффи—Хеллманом проверку показателей степени и их применения для по-
лучения разделяемого ключа. Сходны они и в достижении подлинной прямой
. секретности разделяемого ключа, но OAKLEY имеет и определенные отличия от
STS, которые в RFC 2412 называются «дополнениями».
Первым дополнением является добавление простого механизма проверки адре-
сов, предназначенного для защиты от отказа в обслуживании. Второе дополне-
ние — возможность сторонам выбирать и согласовывать между собой вспомога-
тельные алгоритмы метода шифрации. Третье дополнение — это то, что проверка
подлинности не зависит от шифрации с помощью показателей степени Диффи-
Хеллмана, вместо этого подлинность устанавливается проверкой соответствия
показателей степени идентификатором сторон.
Четвертое — OAKLEY — обеспечивает дополнительную надежность при получении
ключей, предназначенных для шифрации (не для удостоверения подлинности),
путем введения дополнительного алгоритма. Получение ключей, предназначен-
ных для шифрования, зависит не только от алгоритма Диффи—Хеллмана, но так-
же и от криптографического метода, используемого для удостоверения лично-
стей соединяющихся сторон.
Пятым дополнением является то, что OAKLEY определяет способ, при помощи
которого две стороны могут выбрать математические структуры (группы, состо-
ящие из представления и операции) выполнения алгоритма Диффи—Хеллмана.
Стороны могут как использовать стандартные группы, так и определить свои соб-
ственные. Определенные пользователями группы обеспечивают дополнительный
уровень надежности.
В протоколе OAKLEY имеется несколько вариантов распространения ключей. В до-
полнение к обмену ключами по Диффи—Хеллману, он OAKLEY может быть ис-
пользован для получения нового ключа из уже существующего и для распрост-
ранения полученного другой стороной ключа путем его шифрования. Этот
протокол, кроме того, предоставляет защиту от засорения и подлинную прямую
секретность. В целях предоставления пользователям возможности выбора мето-
дов защиты, OAKLEY разрешает идентифицировать на основе симметричного шиф-
рования или применять алгоритмы, не использующие шифрацию.
Обмен ключей в протоколе OAKLEY
Говоря простым языком, OAKLEY предоставляет двум сторонам средства секрет-
ного обмена информацией о ключах. В этом протоколе эти данные называются
«информацией о состоянии» (state information). Эта информация о состоянии
содержит в себе название ключа, секретный материал ключей, идентификаторы
сторон и три алгоритма, используемые в процессе идентификации:
1) шифрации, для конфиденциальности;
2) хэширования, для проверки целостности сообщений;
3) идентификации, для удостоверения сторон.
Протокол определения ключей OAKLEY
99
Обработка сообщений между сторонами в протоколе OAKLEY включает в себя
процесс согласования, в котором инициирующая сторона посылает сообщение,
в котором указывается, какую информацию она хотела бы получить в первом
сообщении. Вторая сторона отвечает, возвращая запрошенную информацию. Да-
лее стороны могут обменяться дополнительными сообщениями в целях получе-
ния всех данных, необходимых для удовлетворения накладываемых на них тре-
бований безопасности.
То, какое количество информации включается в каждое сообщение, зависит от
того, какой нужен набор функций. Дополнительные возможности могут увели-
чить количество сообщений, необходимых для определения материала ключей.
Наиболее важные поля сообщения обмена ключей
В сообщении обмена ключей протокола OAKLEY имеется 12 полей, использование
которых в ISAKMP мы обсудим в главе 10. Здесь же мы только объясним их пред-
назначение с точки зрения операции обмена ключей. Не все эти поля использу-
ются в каждом отдельном обмене сообщениями, если поле не используется, то
его значение будет нулевым или это поле будет отсутствовать вовсе. Эти поля
предназначены для следующего (информация во врезке на с. 85 поможет вам по-
нять нижеследующее):
О CKY-I: Cookie инициатора. Это 64-битное псевдослучайное число. Оно должно
гарантировать, что его комбинация с IP-адресом получателя является
уникальной в течение некоторого периода времени, например часа.
О CKY-R: Cookie получателя. То же предназначение, что и для CKY-I.
О MSGTYPE: Тип сообщения в заголовке ISAKMP.
О GRP: Полезная нагрузка SA и имя группы Диффи—Хеллмана, используемой
в данном обмене.
О д*х (или д*у): Целое переменной длины, представляющее собой показатель
степени генератора группы.
О ЕНАО (или EHAS): Функции шифрования, хэширования и идентификации,
выбранные в процессе согласования.
О IDP: Индикатор того, будет ли использоваться шифрование джху (подлинная
прямая секретность для идентификаторов).
О IDU): Идентификатор инициатора обмена.
О ID(R): Идентификатор респондента.
О N1: Текущее время инициатора.
О Nr.- Текущее время респондента.
100 (лава 5. Распространенные методы защиты данных в Интернете
Генерирование cookie зависит от реализации. RFC 2412 рекомендует создавать
их при помощи односторонних функций, аргументом которых служат некое сек-
ретное значение (периодически меняемое), IP-адреса сторон и UDP-порт второй
стороны. Таким образом, нет нужды сохранять cookies, а срок их действия будет
периодически истекать. Кроме того, в целях поддержки уже распространенных
ключей RFC 2412 рекомендует, чтобы в реализациях поддерживался некоторый
диапазон cookies, выделенный для постоянных ключей. Выполнение этого усло-
вия зависит от конкретной реализации.
Заключение
Десятки различных процедур обеспечения безопасности доступны администра-
торам сетей, желающим повысить защищенность своих пользователей. Наибо-
лее распространенными являются алгоритмы Диффи—Хеллмана и RSA. MD5
является самым популярным методом создания дайджеста сообщений, а комби-
нация с НМАС делает его еще более надежным.
ГЛАВА
PPP, ECP, TLS, EAP,
DESE-bis и 3DESE
В этой главе мы сфокусируемся на протоколе двухточечного соединения
(Point-to-Point Protocol — PPP) и нескольких его расширениях, таких как
PPP-протокол управления шифрацией (PPP Encryption Control Protocol — ECP),
защита данных на транспортном уровне (Transport Level Security — TLS), рас-
ширяемый PPP-протокол идентификации (PPP Extensible Authentication Proto-
col — EAP), PPP-протокол шифрации DES, версия 2 (PPP DES Encryption Protocol,
Version 2 — DESE-bis) и PPP-протокол тройной DESE-шифрации (PPP Triple-DESE
Encryption Protocol — 3DESE). Протоколу PPP посвящена отдельная работа в се-
рии книг, в которую входит этот труд.
РРР иHDLC
РРР работает поверх протокола управления каналом передачи данных верхнего
уровня (High-Level Data Link Control — HDLC) и состоит из двух главных про-
токолов, как показано на рис. 6.1.
При установлении PPP-соединения сначала используется Протокол управления
соединением (Link Control Protocol — LCP). В этом протоколе определены фун-
кции настройки и тестирования соединения. В качестве одной из составляющих
LCP или как отдельная «фаза» может быть проведена идентификация (AUTH).
Затем, для согласования определенных вариантов настроек и параметров, РРР
применяет протокол управления сетью (Network Control Protocol — NCP), ис-
пользуемый протоколом L_3. Протокол управления IP (IP Control Protocol —
IPCP), являющийся разновидностью NCP, применяется для согласования различ-
ных IP-параметров, таких как IP-адреса, сжатие данных и т. д.
PDU (Protocol Data Unit — блок данных протокола) протокола РРР использует
* фрейм HDLC как описано в ISO 3309-1979 (с исправлениями, внесенными в ISO
3309-1984/PDAD1). Описание протокола HDLC выходит за рамки этой книги, по-
этому мы ограничимся только тем, что покажем формат фрейма HDLC и его вза-
102
Глава 6. PPP, ECP, ILS, EAP, DESE-bis и 3DESE
имосвязь c PPP. На рис. 6.2 показана структура этого фрейма. Флаг является
константной величиной HDLC и равен 01111110 (0x79), биты поля адреса уста-
навливаются в 1 (OxFF), что адресам всех станций. РРР не использует адреса от-
дельных станций, поскольку это протокол для связи двух машин. Поле управле-
ния устанавливается равным идентификатору ненумерованной информации
(unnumbered information) HDLC. Его значение — 00000011 (0x03).
LCP Link Control Protocol LCP (Протокол управления соединением)
NCP Network Control Protocol NCP (Протокол управления сетью)
Рис. 6.1. Составляющие протокола РРР
Поле протокола используется для идентификации PDU, передаваемого в поле
данных фрейма. Значения этого поля назначаются Интернетом, причем значе-
ния, начинающиеся с 0, задают сетевой протокол, находящийся в поле данных.
Значения, начинающиеся с 8, задают протокол управления, используемый для
согласования протоколов, которые будут использоваться. Самые последние дан-
LCP
103
ные о номерах протоколов можно, найти в недавних RFC («Assigned Numbers»)
«Назначенные номера».
Номер протокола LCP равен 0хС021, а остальное место в поле информации пред-
назначено для поля кода. В случае LCP значение поля кода определяет сообще-
ния Запрос-Настройки (Configure-Request), Подтверждение-Настройки (Ack-Request) и т. д.
Поле идентификатора используется для сопоставления и координации сообще-
ний запросов с соответствующими ответами. Поле длины задает длину (в бай-
тах) содержимого поля информации, исключая номер протокола.
И наконец, остаток поля информации предназначен для необязательных данных.
Это поле кодируется двумя или тремя значениями: 1) тип-длина-данные; 2) тип-
длина. Эти необязательные данные используются PPP-узлами для извещения друг
друга о своих возможностях и запроса информации. Позже мы это обсудим бо-
лее подробно.
LCP
Предназначение LCP — обеспечение установления PPP-соединения и согласова-
ния определенных конфигурационных настроек. Также этот протокол обеспечи-
вает поддержку установленного соединения и его завершения.
РРР требует, чтобы протокол LCP был использован для установления соединения
между двумя станциями до того, как состоится любой обмен данными на сете-
вом уровне. Для этого необходимо обменяться серией пакетов, называемых
конфигурационными пакетами. После того как был произведен обмен этими
пакетами и был послан и принят пакет подтверждения конфигурации, соедине-
ние считается установленным и обмен данными может начаться. LCP ограничи-
вается только операциями по обеспечению канала связи. Он не знает, как согла-
совывать реализации протоколов сетевого уровня, да он и не предназначен для
высокоуровневых согласований сетевых протоколов.
Определение качества связи не является обязательной операцией, но она позво-
ляет LCP определить качество соединения и установить, достаточно ли оно для
перехода на сетевой уровень. Хотя фаза определения качества связи и описана в
стандарте, то реализующие ее процедуры не специфицированы. Для этого в LCP
предусмотрен эхо-зацрос и специальный тип пакета, определенный в таблицах
переходов состояний этого протокола.
После того как установлено соединение, конфигурация протокола позволяет двум
станциям договориться/настроить протокол, который будет использоваться на
сетевом уровне. Это осуществляется при помощи соответствующего протокола
управления сетью (Network Control Protocol — NCP). Какой конкретный прото-
кол будет здесь применен, зависит от того, какое из семейств NCP использовано
в данной реализации.
На LCP также лежит ответственность за завершение соединения. Конкретная
процедура завершения соединения оставлена на усмотрение разработчиков. За
исключением того случая, когда внешняя проблема вызвала разрыв связи, со-
104
Глава 6. РРР, ECP, TLS, EAP, DESE-bis и 3DESE
единение обычно завершается, протоколом верхнего уровня или самим пользо-
вателем.
Примеры использования протокола РРР
На рис. 6.3 приведены примеры того, как РРР может быть использован для обес-
печения операций по конфигурированию сети. Маршрутизаторы, узлы и т. д.
обмениваются PPP-фреймами для определения того, какой протокол сетевого
уровня поддерживается обеими станциями. В данном примере два компьютера
договариваются об использовании IP и его OSI-двойника, ISO 8473, CLNP
(Connectionless Network Protocol). Сначала используются методы протокола LCP
для установления и тестирования соединения. Затем вызывается NCP для согла-
сования, какой сетевой протокол (и соответствующие процедуры) будут исполь-
зоваться между двумя машинами. После того, как это согласование завершено,
начинается обмен данными. В любой момент времени любой участник соедине-
ния ™ожет разорвать канал связи.
Пользователь §
Запрос конфигурации
Подтверждение конфигурации
Запрос конфигурации
Подтверждение конфигурации
Запрос протокола IP
Подтверждение конфигурации_____
______Запрос протокола CLNP_______
Подтверждение конфигурации
Обмен данными по протоколу IP и CLNP
Запрос завершения
Подтверждение завершения
Запрос завершения
Подтверждение завершения
Рис. 6.3. Пример взаимодействия по протоколу РРР
Фазовая диаграмма РРР
105
Фазовая диаграмма РРР
В процессе конфигурирования PPP-соединения, его поддержания и завершения
это соединение проходит через несколько стадий, показанных на рис. 6.4. Для
данного объяснения достаточно такой упрощенной фазовой диаграммы. Кроме
того, РРР хорошо описывается при помощи конечного автомата (RFC 1661, раз-
дел 4), который иллюстрирует события между состояниями РРР. Но мы не будем
здесь вдаваться в такие подробности.
Рис. 6.4. Фазовая диаграмма протокола РРР
Нет связи (нет физического соединения)
Соединение начинается и завершается этой фазой. Когда внешнее событие (на-
пример, обнаружение носителя или изменение настроек сети администратором)
инициирует физическое соединение, РРР переходит в фазу установления соеди-
нения. ₽.
В общем случае соединение автоматически переходит в это состояние после от-
ключения модема. В случае же постоянного соединения эта фаза может быть очень
короткой — ровно столько, чтобы обнаружить наличие устройства связи.
Фаза установления связи
Протокол управления соединением (LCP) используется для установления канала
связи посредством обмена конфигурационными пакетами. Эта фаза считается за-
вершенной и связь установленной, когда пакет Подтверждение-Конфигурации был
послан и принят. Получение пакета Запрос-Конфигурации вызывает возврат в фазу
установления связи из фаз протокола сетевого уровня или идентификации.
Фаза идентификации
Идентификация не является обязательной. Если в какой-нибудь реализации
необходимо, чтобы стороны осуществляли проверку при помощи определенного
106
Глава 6. РРР, ECP,TLS, ЕАР, DESE-bis и 3DESE
протокола идентификации, тогда такой протокол должен быть запрошен в фазе
установления соединения. Способ идентификации зависит от реализации. В по-
следующих разделах этой главы эта фаза будет рассмотрена подробнее.
Фаза протокола сетевого уровня
В этой фазе каждый протокол сетевого уровня (такой как IP, IPX или AppleTalk)
настраивается отдельно при помощи соответствующего протокола управления
сетью (NCP).
После того, как NCP перешел в состояние установленного (открытого) соедине-
ния, РРР будет передавать соответствующие пакеты протокола сетевого уровня.
Любые пакеты протокола сетевого уровня, полученные, когда соответствующий
NCP не находится в состоянии открытого соединения, должны быть отвергнуты.
В этой фазе поток данных по каналу связи может состоять из пакетов как LCP,
так и NCP и протокола сетевого уровня.
Фаза завершения соединения
Для окончания связи в LCP используются пакеты завершения связи. Когда со-
единение закрывается, РРР извещает протоколы сетевого уровня с тем, чтобы они
могли предпринять соответствующие действия. Обычно после того, как произо-
шел обмен пакетами завершения связи, физический уровень запрашивается о
разъединении.
Пакеты LCP
В этом разделе описываются пакеты LCP.
О Пакеты настройки соединения используются для установки и настройки соеди-
нения (Запрос-Конфигурации, Подтверждение-Конфигурации, Отказ-Конфигурации и Ошиб-
ка-Конфигурации).
О Пакеты завершения соединения используются для завершения связи (Запрос-
Завершения и Подтверждение-Завершения).
О Пакеты поддержки соединения используются для поддержки и отладки связи
(Отказ-Кода, Отказ-Протокола, Эхо-Запрос, Эхо-Ответ и Отвергнуть-Запрос).
Каждая настройка конфигурации имеет значение по умолчанию. Таким образом
гарантируется, что LCP-пакеты будут распознаны даже в том случае, когда одна
из сторон будет по ошибке считать соединение уже открытым. Только один
LCP-пакет может быть помещен в поле информации РРР, а поле протокола долж-
но быть в этом случае равно 0хС021 (LCP).
Формат пакета протокола управления соединением показан на рис. 6.5. Поля
передаются слева направо.
Поля в LCP-пакете:
Пакеты IIP
107
О Поле кода: Определяет тип LCP-пакета, на текущий момент может иметь сле-
• дующие значения:
1. Запрос-Конфигурации
2. Подтверждение-Конфигурации
3. Отказ-Конфигурации
4. Ошибка-Конфигурации
5. Запрос-Завершения
6. Подтверждение-Завершёния
7. Отказ-Кода
8. Отказ-Протокола
9. Эхо-Запрос
10. Эхо-Ответ
11. Отвергнуть-Запрос
0 1-6 7 8 9-14 15 16-30 31
Код Идентификатор Длина
Данные
Рис. 6.5. Формат LCP-пакета
О Идентификатор: Используется для сопоставления запросов и ответов.
О Длина: Обозначает длину LCP-пакета, включая код, идентификатор, длину и
данные.
О Данные: Формат поля данных определяется значением в поле кода.
В последующих разделах дается краткое описание каждого из возможных LCP-
пакетов.
Запрос-Конфигурации
Если реализация желает открыть соединение, то она должна послать Запрос-Кон-
фигурации. Поле опций заполняется любыми желаемыми изменениями настроек
соединения. После получения этого запроса посылается соответствующий ответ.
Подтверждение-Конфигурации
Если все настройки конфигурации, полученные в Запросе-Конфигурации, распознаны
и переданные значения являются допустимыми,тогда получатель передает Под-
тверждение-Конфигурации.
108
Глава б. РРР, ECP, TLS, EAP, DESE-bis и 3DESE
Отказ-Конфигурации
В случае если все настройки конфигурации распознаны, но некоторые из их зна-
чений не могут быть установлены, то получатель передает сообщение Отказ-Кон-
фигурации. Поле Данные/Опции заполняется настройками, переданными в Запро-
се-Конфигурации, значения которых не могут быть установлены. Значения
настроек, которые могут быть установлены, убираются из сообщения Отказ-Кон-
фигурации.
Каждое из значений настроек .изменяется на такое, которое является приемле-
мым для отправителя сообщения Отказ-Конфигурации. Для этого может быть ис-
пользовано значение по умолчанию, если оно отличается от запрошенного зна-
чения.
Если какая-нибудь из настроек конфигурации может быть установлена в одно
из нескольких значений, то в Отказ-Конфигурации включается список всех значе-
ний, являющихся приемлемыми для отправителя этого сообщения. Сюда входят
приемлемые настройки из сообщения Запрос-Конфигурации.
Ошибка-Конфигурации
Если некоторые из настроек конфигурации, переданных в сообщении Запрос-Кон-
фигурации, не могут быть распознаны или не должны изменяться, то получатель
передает сообщение Ошибка-Конфигурации. Поле Данные/Опции заполняется настрой-
ками из сообщения Запрос-Конфигурации, вызвавщими ошибку.
Запрос-Завершения и Подтверждение-Завершения
В протоколе РРР соединение завершается посылкой сообщения Запрос-Заверше-
ния. Это сообщение передается до тех пор, пока не будет получено Подтверждение-
Завершения, либо физическое соединение не выдаст подтверждение разрыва свя-
зи, либо когда послано достаточное количество сообщений Запрос-Завершения, что
можно быть уверенным в том, что другая сторона отсоединилась. В случае полу-
чения сообщения Запрос-Завершения посылается сообщение Подтверждение-Завершения.
Отказ-Кода
Получение LCP-пакета с неидентифицированным полем кода говорит о том, что
другая сторона использует другую версию. Сообщение об этом и несет пакет Отказ-
Кода.
Отказ-Протокола '
Получение PPP-пакета с неидентифицировадным полем протокола говорит о том,
что другая сторона пытается использовать неизвестный этой стороне протокол.
Обычно это происходит, когда вторая сторона пытается изменить настройки
Протокол обеспечения безопасности на уровне передачи данных 109
нового протокола. После получения сообщения Отказ-Протокола необходимо пре-
кратить посылать пакеты указанного протокола.
Эхо-Запрос и Эхо-Ответ
В LCP включены пакеты Эхо-Запрос и Эхо-Ответ для того, чтобы иметь механизм
обратной связи на уровне канала передачи данных в целях проверки соединения
в обоих направлениях. Это нужно при отладке, проверке качества соединения,
определении производительности и множестве других задач.
Отвергнуть-Запрос
Сообщение Отвергнуть-Запрос включено в LCP для обеспечения механизма отвода
на уровне канала передачи данных с тем, чтобы управлять связью в направле-
нии от локального компьютера к удаленному.
Другие вспомогательные протоколы
обеспечения безопасности в РРР
Вдобавок к протоколам, обсуждаемым в главе 7, за последние несколько лет были
разработаны протоколы, дополняющие средства обеспечения безопасности РРР.
В оставшейся части этой главы мы коротко рассмотрим их базовые возможно-
сти. Чтобы вы могли следить за этим изложением (а если вам нужна более под-
робная информация, то посетите сайт www.ietf.org), вот список обсуждаемых тем:
1. RFC 2276
2. RFC 1968
3. RFC 2287
4. RFC 2419
5. RFC 2420
Transport Lavel Security Protocol (TLS)
PPP Encryption Control Protocol (ECP)
PPP Extensible Authentication Protocol (EAP)
PPP DES Encryption Protocol, Version 2 (DESE-bis)
PPP Triple-DES Encryption Protocol (3DESE)
Протокол обеспечения безопасности
на уровне передачи данных
(Transport Layer Security Protocol — TLS)
Возможно, в этом месте вы можете удивиться, зачем IETF публиковать еще один
протокол безопасности. TLS создан на основе SSL 3.0 компании Netscape. Идея
заключалась в том, чтобы опубликовать этот протокол как формальный ДРС и
110
Глава 6. РРР, ECP, TLS, ЕАР, DESE-bis и 3DESE
придать ему до некоторой степени некоммерческий статус. В этом разделе мы
обсудим общим образом TLS, а если вам нужны детали, то вы можете обратиться
к RFC 2276 и спецификации SSL [FRIE96]1.
Предназначение TLS
Протокол TLS состоит из двух уровней: TLS Record Protocol (протокол записей) и
TLS Handshake Protocol (протокол установления связи). TLS Record Protocol действу-
ет поверх TCP и UDP и выполняет следующие функции:
О Симметричное шифрование используется для шифровки данных. Ключи для
такого шифрования генерируются отдельно для каждого соединения и при
их создании используется секретная информация, полученная при помощи
другого протокола (такого, как TLS Handshake Protocol). TLS Record Protocol мо-
жет быть использован и без шифрования.
О Передача сообщений, сюда входит проверка целостности переданных сообще-
ний при помощи кода идентификации по ключу. Для этого применяется хэ-
ширование (например, SHA, MD5 и др.).
TLS Record Protocol используется в качестве оболочки для протоколов более вы-
сокого уровня. Примером такого протокола может служить TLS Handshake
Protocol, который позволяет серверу и клиенту идентифицировать друг друга,
договориться об алгоритме шифрации и используемых ключах до того, как
начнут передаваться данные. TLS Handshake Protocol защищает соединение, обес-
печивая следующие три функции:
О Идентификация другой стороны проводится при помощи шифрации откры-
тым ключом (например, RSA, DSS и др.). Такая проверка не является обяза-
тельной, но обычно выполняется, по крайней мере, для одной из сторон.
О Разделяемый секрет недоступен для перехвата, и не может быть получен даже
в случае, если атакующая сторона сможет поместить себя между соединяе-
мыми сторонами.
О Атакующий не может изменить данные без того, чтобы не быть обнаружен-
ным участниками соединения.
PPP-протокол управления шифрацией
(РРР Encryption Control Protocol — ECP)
ECP предназначен для настройки и управления алгоритмами шифрации данных
у обоих участников PPP-соединения. Спецификация этого протокола опублико-
вана в RFC 1968. В ЕСР используются в основном те же механизмы, что и в LCP.
* 1 [FRIE96J. Frier A., Karlton Р., and Kocher Р., The SSL 3.0 Protocol, Netscape Communication Corp..
November 18, 1996.
Расширяемый PPP-протокол идентификации 111
Однако ЕСР-пакеты не посылаются до тех пор, пока РРР не достигнет фазы сете-
вого уровня. Между LCP и ЕСР существуют следующие различия:
О Один ЕСР-пакет помещается в поле данных PPP-пакета, а значение поля про-
токола устанавливается равным 0x8053.
О Когда используется отдельный канал передачи данных в случае многоканаль-
ного соединения с одним компьютером, то в поле протокола помещается
0x8055, что обозначает Individual link Encryption Control Protocol (протокол уп-
равления шифрацией для отдельного соединения).
О ЕСР использует значения поля кода от 1 до 7 (Запрос-Конфигурации, Подтвержде-
ние-Конфигурации, Отказ-Конфигурации, Ошибка-Конфигурации, Запрос-Завершения, Под-
тверждение-Завершения, Отказ-Кода), кроме того, могут быть использованы код
14 (Сброс-Запрос) и 15 (Сброс-Подтверждение).
О В реализациях передача данных не должна начинаться раньше, чем согласо-
вания по протоколу ЕСР успешно завершатся. В случае же неудачи соедине-
ние должно быть разорвано.
В одно и то же время может использоваться только один алгоритм шифрования
в каждом направлении. Поле протокола РРР зашифрованной датаграммы будет
указывать, что фрейм зашифрован, но не то, какой алгоритм шифрации был ис-
пользован. В ЕСР используются коды Сброс-Запрос и Сброс-Подтверждение на тот
случай, если будет необходимо показать, что произошел сбой при дешифрации
данных в одном из направлений соединения не затрагивая поток данных в про-
тивоположном направлении.
Значения поля Данные/Опции вы можете найти по адресу www.ietf.org. На теку-
щий момент значения кода могут быть 0 для идентификатора организации-раз-
работчика данной реализации, и 1 для DESE, обсуждаемого дальше. DESE должен
быть встроен во всех реализациях ЕСР.
Расширяемый РРР-протокол
идентификации (РРР Extensible
Authentication Protocol — EAP)
Расширяемый РРР-протокол идентификации — протокол РРР общего типа, под-
держивающий множество механизмов идентификации и опубликованный в RFC
2284. EAP не выбирает какой-либо определенный механизм идентификации в
процессе LCP-операций, а откладывает такой выбор до фазы идентификации. Во
время этой фазы идентифицирующий может запросить дополнительную инфор-
мацию от идентифицируемого, прежде чем выбрать определенный механизм
идентификации. Такой подход позволяет идентифицирующей стороне перена-
править обмен сообщений идентификации на другой сервер, реализующий кон-
кретный алгоритм.
112
Глава 6. РРР, ECP, TLS, ЕАР, DESE-bis и 3DESE
На рис. 6.6 показано, в какой последовательности выполняются действия в ЕАР в
проекции на фазовую диаграмму РРР (верхняя часть картинки) й последователь-
ность обмена по этому протоколу (нижняя часть картинки).
I
LCP завершен
Запрос (MD5 и т. д.)
Ответ (MD5 и т. д.)
ЕАР
Идентификация
Успех или Неудача
Рис. б.б. Протокол ЕАР
Номер протокола ЕАР в РРР равен 0хС227. Значения поля кода обычные: Запрос,
Ответ, Успех и Неудача. Формат поля данных определяется значением поля кода.
Поле типа определяет структуру пакета Запроса или Ответа. До сих пор эти типы
определялись в RFC 2284:
О Идентификатор: Сообщение для вывода, передаваемое в пакете Запроса.
О Извещение: Сообщение для вывода, посылаемое от идентифицирующего к иден-
тифицируемому, используемое для вывода различной информации, такой как
скорое истечение срока действия пароля.
О Отказ: Используется только в пакетах Ответов. Получение такого ответа озна-
чает, что тип идентификации в пакете Запроса не является допустимым.
О Запрос MD5: Сходен с CHAP и содержит сообщение-запрос к идентифицируемой
стороне.
О Одноразовый пароль: Определен в RFC 1938 и предназначен для систем с одно-
разовыми паролями.
О Маркерная карта общего назначения (Generic Token Card): Этот тип Предназна-
чен для получения информации, введенной пользователем.
PPP-протокол шифрования DES, версия 2 113
PPP-протокол шифрования DES, версия 2
(РРР DES Encryption Protocol,
Version 2 — DESE-bis)
Протокол DESE-bis определяе.т то, как пользователь задает необходимые данные
для заданного протокола в контексте ЕСР, и обеспечивает по крайней мере одно
средство защищенного обмена данными, поддерживаемое в большинстве реали-
заций РРР. Как следует из названия RFC, акцент делается на DES.
Хотя алгоритм Стандарта шифрации данных США (US Data Encryption Stan-
dard — DES) может быть использован многими способами, в этой спецификации
определен только один режим для использования1 в PPP-протоколе ЕСР: режим
Сцепления блоков шифра (Cipher Block Chaining — СВС).
В этом режиме инициализационный вектор выводится из текущего времени^в яв-
ном 64-битном представлении, которым обмениваются открытым текстом во
время фазы согласования. Требуемый во всех режимах DES 56-битный ключ оп-
ределен как общее для всех реализаций секретное значение.
В приложении А вы можете найти детали того, как создавать и извлекать зашиф-
рованный текст в DESE, в разделе под названием «Создание и извлечение зашиф-
рованного текста в RFC 1969: PPP-протокол шифрования DES (DESE-bis)».
Настройка конфигурации в ЕСР
Настройка конфигурации DESE в ЕСР означает, что узел, пославший такой пакет,
хочет использовать ЕСР DESE для шифрования данных, передаваемых по каналу
связи. Настройка имеет поля, как показано на рис. 6.7. Эти поля выполняют
следующие функции:
0 1-6 7 8 9-14 15 16-30 31
Тип Длина Начальное значение
Рис. 6.7. Поля настройки конфигурации в ЕСР DESE
О Тип: Устанавливается в 3, что обозначает протокол DESE-bis.
О Длина: Устанавливается равной 10.
О Начальное значение: Текущее время, используемое сторонами для шифрации
первого пакета, пе^даваемого после того, как отправитель достигнет состоя-
ния открытого соединения. Для избежания атак повторением RFC 2419 реко-
мендует использовать новое значение для каждого ЕСР-согласования. В каче-
стве примера может быть использовано количество секунд, прошедших с
наступления по Гринвичу 1 января 1970 года, в старших 32 разрядах, а в млад-
ших — количество наносекунд, прошедших с наступленья последней секунды.
114 Глава 6. РРР, ЕСР, TLS, EAP, DESE-bis и 3DESE
Формат пакета DESE
Формат DESE-пакетов показан на рис. 6.8. Поля пакета выполняют следующие
функции:
О Адрес и Управление: Эти поля представлены, если только настройка сжатия
адреса и управления (Address and Control Field Compression — ACFC) не была
уже согласована.
О Идентификатор протокола: Значение этого поля равно либо 0x53, либо 0x55.
Последнее обозначает, что в зашифрованном тексте содержится заголовок про-
токола многоканального соединения (Multilink Protocol), и требует, чтобы про-
токол управления шифрацией для отдельного соединения (Individual link
Encryption Control Protocol) находился в состоянии открытого соединения. Ве-
дущий ноль может быть опущен, если поле сжатия протокола РРР (РРР Protocol
Field Compression option — PFC) было согласовано.
О Порядковые номера: Эти номера назначаются отправителем по порядку, начи-
ная с 0, который имеет первый пакет, посланный после того, как ЕСР-соедине-
ние перешло в открытое состояние.
. О Зашифрованный текст: Создание данных для этого поля описывается в при-
ложении А. •
0 9-15 15 16 17-22 23 24 25-30 31
Адрес Управление 0000 Идентификатор протокола
Порядковый номер пакета (старший разряд) Порядковый номер пакета (младший разряд) Зашифрованный текст
Рис. 6.8. Формат пакета протокола шифрации DES
РРР-протокол тройной DES-шифрации
(РРР Triple-DES Encryption
Protocol — 3DESE)
DES — это хорошо изученный, понятный и широко распространенный алгоритм
шифрации. Тройная DES-шифрация означает, что этот алгоритм применяется
трижды к шифруемым данным перед тем, как они будут посланы по каналу свя-
зи. Используемый вариант называется DES-EDE3-CBC. Поскольку используется
режим СВС, необходимо использование порядкового номера с тем, чтобы гаран-
тировать правильный порядок переданных пакетов и обнаруживать потерянные
данные.
PPP-протокол тройной DES-шифрации
115
Алгоритм
Алгоритм DES-EDE3-CBC является простым вариантом алгоритма DES-CBC, см. рис.
6.9. В DES-EDE3-CBC к вектору инициализации (Initialization Vector — IV) приме-
няется операция исключающего ИЛИ с первыми 64 битами (8 байтами) блока
текста (Р1). DES-функция с ключом повторяется три раза, сначала шифровка Е,
затем дешифровка D, затем снова шифровка Е, и генерируется зашифрованный
блок текста С1. В каждой итерации используются свои ключи kl, k2 и k3. В после-
дующих блоках к предыдущему зашифрованному блоку применяется операция
исключающего ИЛИ с текущим блоком (8 байт) шифруемого текста Pi. Функ-
ция шифрации DES-EDE3 с ключом применяется к этому блоку, и генерируется
зашифрованный блок С1.
Рис. 6.9. Тройная DES-шифрация
При дешифрации применяется обратный порядок функций: дешифровка при
помощи ключа кЗ, шифровка с ключом к2 и дешифровка с ключом kl; затем при-
меняется операция исключающего ИЛИ с предыдущим зашифрованным блоком.
В случае когда все три ключа kl, k2 и кЗ одинаковые, DES-EDE3-CBC является экви-
валентом DES-CBC.
Ключи
Секретный ключ DES-EDE3, разделяемый соединяющимися сторонами, имеет длину
168 бит. Этот ключ состоит из трех независимых 56-битных величин, использу-
116
Глава 6. РРР, ЕСР, TLS, ЕАР, DESE-bis и 3DESE
емых DES-алгоритмом. Каждый из этих ключей хранится как 64-битное (8-байт-
ное) число, в котором младший бит каждого байта используется для контроля
четности.
Настройка конфигурации 3DESE в ЕСР
Настройка конфигурации 3DESE в ЕСР означает, что данная реализация предлага-
ет использование этой спецификации для шифрования данных, передаваемых по
этому каналу связи, и может-рассматриваться получателем как предложение
шифровать пакеты с применением указанного протокола. Формат настройки
конфигурации ЕСР 3DESE показан на рис. 6,10. Эти поля выполняют следующие
функции:
0 1-6 7 8 9-14 15 16-30 31
Тип Длина Начальное значение
Рис. 6.10. Поля настройки конфигурации в ЕСР 3DESE
О Тип: Устанавливается равным 2, что означает использование протокола 3DESE.
О Длина: Устанавливается равной 10.
О Начальное значение: Создается на основе текущего времени и используется
второй стороной для шифрации первого пакета после того, как отправитель
перейдет в состояние открытого соединения. Для избежания атак повторени-
ем в реализации должно быть предусмотрено использование нового значения
для каждого ЕСР-согласования.
Формат пакета 3DESE
Формат пакета 3DESE, несущего в себе данные, показан на рис. 6.11. Поля пакета
выполняют следующие функции:
О Адрес и Управление: Эти поля представлены, если только настройка сжатия
адреса и управления не была уже согласована.
О Идентификатор протокола: Значение этого поля равно либо 0x53, либо 0x55.
Последнее означает, что в зашифрованном тексте содержится заголовок про-
токола многоканального соединения (Multilink Protocol), и требует, чтобы про-
токол управления шифрацией для отдельного соединения (Individual link
Encryption Control Protocol) находился в состоянии открытого соединения.
Ведущий ноль может быть опущен, если поле сжатия протокола РРР (РРР
Protocol Field Compression option — PFC) было согласовано.
О Порядковые номера: Эти номера назначаются отправителем по порядку, начи-
ная с 0, который имеет первый пакет, посланный после того, как ЕСР-соедине-
ние перешло в открытое состояние.
О Зашифрованный текст: Зашифрованные данные.
Заключение 117
0 9-15 15 16 17-22 23 24 25-30 31
Адрес Управление 0000 Идентификатор протокола
Порядковый номер пакета (старший разряд) Порядковый номер пакета (младший разряд) Зашифрованный текст
Рис. 6.11. Формат пакета протокола шифрации 3DESE
Заключение
Протокол РРР был значительно улучшен путем добавления нескольких протоко-
лов обеспечения безопасности. Эти протоколы, являясь расширением протокола
РРР, используют заданный в спецификации РРР синтаксис сообщения, например
номера протоколов и кодов, используемых в соответствующих полях. Вдобавок
VPN-шлюзы в своих системах безопасности часто используют основанные на DES.
протоколы.
4^ ГЛАВА
Протоколы
коммутируемых
соединений РАР,
CHAP, RADIUS
и DIAMETER
В этой главе мы обсудим несколько протоколов обеспечения безопасности
коммутируемых соединений с Интернетом. Этот обзор начнется с протоко-
ла проверки пароля (Password Authentication Protocol — РАР), затем мы перей-
дем к протоколу идентификации запрос-подтверждение (Challenge-Handshake
Authentication Protocol — CHAP). После этого мы рассмотрим протоколы, осно-
ванные на клиент-серверных операциях, с кратким обзором системы удаленной
авторизации пользователей по коммутируемым линиям (Remote Authentication
Dial-In User Service — RADIUS). Потом мы более подробно обсудим преемника
RADIUS — протокол DIAMETER. В конце главы будут приведены примеры межсете-
вого обмена протоколов обеспечения безопасности в Интернете (расширений
DIAMETER) с телефонными сетями.
РАР и CHAP
В старой спецификации RFC 1334 процедуры идентификации в РРР определены
для двух протоколов авторизации: РАР и CHAP. В настоящее время CHAP опубли-
кован в новой спецификации — RFC 1994 (в этот RFC не входит РАР).
PAP
119
PAP
PAP — это простая процедура, позволяющая другой стороне (обычно узлу или
маршрутизатору) удостоверить себя, используя двухстороннее подтверждение.
Эта операция выполняется после начального этапа установления соединения. Как
только фаза установления соединения завершена, пара имя/пароль многократно
посылается отвечающему за выполнение авторизации узлу, до тех пор пока не
подтверждается идентификация или разрывается соединение.
РАР не разрабатывалась как надежная’ процедура авторизации, поэтому все паро-
ли и имена посылаются открытым текстом. Узлы не имеют никаких средств про-
тив мониторинга или атак. Тогда зачем использовать этот протокол? Наиболее
уместным будет его использование в тех случаях, когда пароль открытым тек-
стом должен быть доступен при имитации входа в удаленную систему.
На рис. 7.1 показан формат пакета РАР в поле данных РРР. Поле протокола РРР
устанавливается равным 0?С023. Поле кода задает один из трех видов пакетов:
Запрос-Идентификации, Подтверждение-Идентификации й Отказ-Идентификации. Поля иден-
тификатора и длины заполняются в соответствии с общими правилами, изложен-
ными в предыдущей главе. Поле данных заполняется именем и паролем в пакете
Запрос-Идентификации и соответствующим сообщением в случае подтверждения или
отказа.
Номер
протокола
Рис. 7.1. Формат пакета RAP в РРР
Ключевые аспекты РАР
Здесь приводится краткое изложение ключевых аспектов РАР. Первое — пакет За-
прос-Идентификации используется для начала РАР-операций. Идентифицируемая
сторона должна использовать пакет Запрос-Идентификации во время фазы автори-
зации. Пакет Запрос-Идентификации посылается множество раз, до тех пор пока не
будет получен правильный ответ или (необязательный вариант) будет послано
заданное количество пакетов.
Идентифицирующая сторона ожидает, что будетитрислан пакет Запрос-Идентифи-
кации. После получения такого пакета ею возвращается один из возможных отве-
тов.
120 Глава 7. Протоколы коммутируемых соединений PAP, CHAP, RADIUS и DIAMETER
Если пара имя/пароль, полученная в пакете Запрос-Идентификации, и распознавае-
ма, и правильна, тогда идентифицирующий посылает пакет Подтверждение-Иден-
тификацию В противном случае он посылает пакет Отказ-Идентификации. Тогда дру-
гая сторона считается неиденфицируемой и обмен пакетами L_3 не может
произойти из-за того, что получатель отказа должен завершить связь.
CHAP
Протокол идентификации запрос-подтверждение (Challenge-Handshake
Authentication Protocol — CHAP), специфицированный в RFC 1994, является на-
дежным протоколом авторизации. Как и РАР, он разработан для работы поверх
РРР на коммутируемых линиях между узлом и, например, маршрутизатором.
В этой части книги мы рассмотрим основные возможности CHAP.
CHAP периодически проверяет подсоединяемый узел посредством трехсторонне-
го подтверждения в процессе начальной установки соединения. Кроме того, поз-
же он может быть вызван в любое время.
После завершения фазы установки канала связи РРР идентифицирующий по-
сылает вызов другой стороне. Эта сторона должна вычислить одностороннюю
хэш-функцию и послать результат обратно. Идентифицирующий проверяет по-
лученную информацию, проведя дополнительные вычисления, и отвечает под-
тверждением, если значения хэш-кодов совпали. В противном случае соедине-
ние разрывается.
| Идентифицирующий ||
СНАР-выэов
СНАР-ответ
вычисление
хэш-кода
Вычисление
хэш-кода
СНАР-подтверждение
или разрыв связи
Рис. 7.2. Пример авторизации по протоколу CHAP
CHAP использует изменяющийся идентификатор и переменное значение вызова.
Использование повторяющихся вызовов позволяет сократить время, в течение
которого система подвержена отдельной атаке. Идентифицирующий определяет
частоту и время вызовов. Метод авторизации зависит от секретного значения,
известного только идентифицирующему и идентифицируемому. Это значение не
посылается по установленному соединению.
Авторизация выполняется в одностороннем режиме, но двухстороннее поведение
РРР позволяет CHAP в действительности действовать в двухстороннем режиме.
CHAP
121
CHAP может быть применен для идентификации в различных системах, так что
поля имени используются как индекс, позволяющий найти соответствующее
секретное значение в таблице. Этот подход, кроме того, позволяет системе иметь
более чем одну пару имя/секрет и изменять используемое секретное значение в
любой момент в течение сеанса связи. На рис. 7.2 показан пример обмена данны-
ми по протоколу CHAP.
Сообщения CHAP
В протоколе CHAP имеется четыре вида сообщений: Вызов, Ответ, Успех и Неудача.
Они посылаются в пакетах двух форматов, показанных на рис. 7.3. Общая струк-
тура PPP-пакета была описана ранее, номер протокола CHAP равен хС223. Для CHAP
идентификатор изменяется каждый раз после посылки любого сообщения Вызов,
и поле идентификатора копируется в соответствующее сообщение Ответ.
Номер
протокола
а
Номер
протокола '
Рис. 7.3. Сообщения CHAP в РРР-пакетах
Поле Размер значения указывает размер поля Значение. Поле Значение в сообщении
Вызов является значением Вызова. Каждое значение Вызова должно быть уникаль-
ным, поскольку повтор значения Вызова вместе с тем же секретным значением
может позволить атакующему подсунуть ответ, перехваченный ранее. Более того,
каждое значение должно быть, насколько это возможно, случайным и непред-
сказуемым и должно изменяться после каждого •вызова.
122 Глава 7. Протоколы коммутируемых соединений РАР, CHAP, RADIUS и DIAMETER
Поле Значение в сообщении Ответ содержит результат хэш-функции. В качестве
• ее аргументов используется поток связанных байтов, составленный из иденти-
фикатора, секретного значения и значения Вызова. Длина значения ответа зави-
сит от используемого алгоритма хэш-функции (например, это 128 бит в случае
MD5, который является наиболее распространенным алгоритмом в авторизации
соединений на коммутируемых линиях). Ожидается, что алгоритм односторон-
ней хэш-функции будет выбираться таким образом, чтобы он был устойчивым к
взлому при условии известных значений вызова и ответа.
Поле Название используется для идентификации системы, пославшей данное СНАР-
сообщение. На то, как хранятся данные в этом поле, не наложено никаких огра-
ничений.
Сообщение Успех посылается идентифицируемому в том случае, если получен-
ное от него значение совпадает с ожидаемым. В противоположном случае посы-
лается сообщение Неудача и соединение должно быть разорвано. Для сообщений
Успех и Неудача использование поля Сообщение зависит от реализации.
RADIUS
В случае большой организации обеспечение безопасности является сложной
задачей. И одна из забот — это возможность подвергнуть организацию опасности
из-за распыления усилий по обеспечению безопасности, что может привести к
фрагментации защиты. Еще более усложняет картину то обстоятельство, что
работники компании, консультанты и ее клиенты нуждаются в доступе к
информации, поэтому они могут подсоединяться к компьютерам организации
практически отовсюду. Для администрирования множества коммутируемых
каналов и модемного пула необходимо прилагать значительные усилия.
Авторизация столь разнотипных пользователей должна выполняться в соответ-
ствии с правилами безопасности, принятыми в организации. Но как это сделать?
Нужно ли устанавливать свою службу информации в каждом отделении компа-
нии? А если так, то как управлять этими серверами, как координировать их дей-
ствия? Или же организация должна установить один центральный сервер, что
позволит избежать усилий по координации?
Для того чтобы помочь организации обеспечить интегрированный подход к управ-
лению системами безопасности, рабочая группа по сети Интернет (Internet Network
Working Group) опубликовала RFC 2138 «Система удаленной авторизации пользо-
вателей по коммутируемым линиям» (Remote Authentication Dial-In User Service
— RADIUS). В этой спецификации определены методы реализации сервера авто-
ризации, включая центральную базу данных, используемую для удостоверения
пользователей, соединяющихся по коммутируемым линиям, и дополнительную
информацию, необходимую при идентификации таких пользователей.
Сервер, использующий систему RADIUS, моЖет обращаться к другим серверам,
необязательно применяющим RADIUS в своей работе. При таком подходе
Настройка RADIUS 123
RADIUS-сервер служит в качестве модуля доступа к другим серверам. Этот RFC,
кроме того, специфицирует то, как могут быть реализованы различные опера-
ции, выполняемые пользователям, такие как РРР, rlogin, TELNET и др.
Настройка RADIUS
На рис. 7.4 показана клиент-серверная конфигурация RADIUS. Пользователь со-
единяется с сервером доступа к сети (Network Access Server — NAS) по комму-
тируемому каналу связи. В свою очередь NAS является клиентом сервера RADIUS.
NAS и RADIUS соединяются друг с другом через сеть или напрямую. Как и упоми-
налось ранее, RADIUS-сервер может соединяться с другими серверами, необяза-
тельно использующими RADIUS. Основной идеей является наличие центрально-
го хранилища информации авторизации, обозначенного на рис. 7.4 значком базы
данных.
Пользователь
Рис. 7.4. Настройка RADIUS
Пользователь должен ввести информацию идентификации, такую как имя и
пароль, серверу NAS (далее называемому клиентом) или послать соответствую-
щий PPP-пакет. Клиент может затем соединиться с RADIUS. В этом случае клиент
создает сообщение с запросом доступа и посылает его RADIUS-серверу (далее —
сервер). Это сообщение содержит информацию о пользователе, называемую ат-
рибутами. Эти атрибуты определяются администратором RADIUS-сервера, поэто-
му они могут отличаться. Примерами атрибутов могут быть имя, пароль, порт,
название клиента и т. д.
124 Глава 7. Протоколы коммутируемых соединений РАР, CHAP, RADIUS и DIAMETER
Если в атрибутах содержится секретная информация, то она должна быть защи-
щена с использованием алгоритма MD5. Целостность всех данных, передавае-
мых между сервером и клиентом, должна быть удостоверена с помощью общего
секретного ключа, а пароли должны быть зашифрованы.
Пример обмена сообщениями в RADIUS
Запрос от клиента к RADIUS-серверу должен использовать общий секретный ключ
так, как показано на рис. 7.5. В противном случае запрос будет отвергнут (раз
ничего не случилось, то нет и дальнейшей обработки). Если начальная проверка
Пройдена, то сервер обращается к базе данных с целью проверки данных пользо-
вателя. Эта база данных содержит информацию, необходимую для авторизации
пользователя.
Секретный ключ
Сервер RADIUS
Вызов доступа
Сообщение
Ответное сообщение
_________Доступ_____________
Разрешить/Запретить
Рис. 7.5. Пример обмена сообщениями в пакете RADIUS
Если пользователь идентифицирован, то сервер посылает запрос пользователю
в виде сообщения о запросе доступа. Клиент может передать это сообщение
пользователю в виде приглашения ввода. Вне зависимости от сценария взаимо-
действия между клиентом и пользователем клиент должен послать сообщение
запроса доступа заново. В данном сообщении имеются несколько дополнитель-
ных полей, наиболее интересным в данном случае является зашифрованный от-
вет на этот запрос. «Вызов» пользователю заключается в посылке ему случайно-
го числа, которое он должен зашифровать и послать обратно результат.
Сервер проверяет этйт результат. Если проверка пройдена, то сервер посылает
клиенту сообщение о разрешении доступа. Надо сказать, что область примене-
Пример обмена сообщениями в RADIUS 125
ния RADIUS гораздо шире, чем просто проверка прав доступа. Сообщение о раз-
решении доступа содержит настройки конфигурации, например РРР, имя пользо-
вателя и т. д. Идея заключается в использовании RADIUS так, чтобы дать пользо-
вателю всю информацию, необходимую для настройки сеанса связи с сетью.
Примером такой информации может быть IP-адрес сеанса связи, используется
ли сжатие, максимальный размер передаваемого блока данных (Maximum
Transmission Unit Size — MTU) и др.
NAS-клиент может поддерживать РАР или CHAP. В таком случае клиент посылает
имя и пароль РАР в сообщении запроса доступа (в полях Имя-Пользователя и Па-
роль-Пользователя). В случае же использования CHAP NAS-клиент генерирует вы-
зов и посылает его пользователю. В соответствии с правилами CHAP, пользователь
должен послать в ответ идентификатор CHAP и имя пользователя CHAP. После этого
клиент NAS посылает серверу RADIUS сообщение запроса доступа, содержащее имя
пользователя CHAP в поле Имя-Пользователя и идентификатор CHAP.
Польза UDP t к
RADIUS работает поверх UDP по следующим причинам: если запрос к главному
серверу авторизации не удался, то тогда нужно обратиться к вспомогательному
серверу. Протокол TCP не предназначен для решения такого рода проблем. Таким
образом, таймеры и повторная передача обеспечиваются RADIUS, а применение
UDP обосновано следующими причинами (RADIUS использует порт 1812):
О Требования по времени отличаются от тех, которые обеспечиваются в TCP.
Обнаружение потери данных, повторная их посылка на основе времени дос-
тавки данных туда и обратно (Round Trip Time — RTT) — все это не нужно.
В конце концов, пользователь может и не захотеть ждать авторизации слиш-
ком долго, и более производительным для него может быть использование
другого сервера (а не ожидание, пока TCP разрешит проблему). ,
О RADIUS не меняет своего состояния, и эта его особенность упрощает исполь-
зование UDP. Клиенты и серверы могут подключаться, отключаться, перегру-
жаться и т. д., в результате чего соединениями TCP стало бы трудно управлять.
О Использование UDP упрощает поддержку многопоточности (когда запрос
пользователя разбивается на несколько процессов для сокращения времени
идентификации).
Формат сообщения RADIUS
На рис. 7.6 показан формат, пакета RADIUS. UDP-пакет содержит в себе один пакет
RADIUS, состоящий из следующих полей:
О Код: Задает тип пакета RADIUS в соответствии с перечисленным чиже'
1 - Запрос-Доступа
2 - Разрешение-Доступа
3 - Отказ-Доступа
126 Глава 7. Протоколы коммутируемых соединений PAP, CHAP, RADIUS и DIAMETER
4 - Запрос-УчетнойЗаписи
5 - Ответ-УчетнойЗаписи
11 - Вызов-Доступа
12 - Статус-Сервера (экспериментальный тип)
13 - Статус-Клиента (экспериментальный тип)
255 - Зарезервировано .
О Идентификатор: Для сопоставления запросов и ответов,
О Длина: Длина пакета, включая все поля.
0 2-7 8 8 10-14 15 16 18-3 0 31
Код Идентификатор Длина
Идентифицирующее число
Атрибуты
Рис. 7.6. Пакет RADIUS
О Идентифицирующее число: Используется для идентификации ответа с
RADIUS-сервера. В пакете Запрос-Доступа это значение является 16-байтным
случайным числом, называемым запрос-идентификатором. Это значение и зна-
чение совместного секретного ключа обрабатывается по алгоритму MD5, в ре-
зультате чего получается 16-битный дайджест, чье значение и введенный
пользователем пароль подвергаются операции исключающее ИЛИ. Получен-
ный результат помещается в атрибут Пароль-Пользователя пакета Запрос-Досту-
па. В пакетах Запрос-Доступа, Отказ-Доступа и Вызов-Доступа это значение назы-
вается ответ-идентификатором и является результатом MDS-функции,
выполненной на значениях полей кода, идентификатора, длины и идентифи-
цирующего числа пакета Запрос-Доступа.
О Атрибуты: Их описание вы найдете в следующем разделе этой главы.
Атрибуты RADIUS
В атрибутах узлы RADIUS передают друг другу информацию, необходимую для
идентификации, авторизации и конфигурации. RFC 2138 дает определение не-
которым из этих атрибутов, а идентификаторы атрибутов можно найти в разде-
ле «Выделенные номера», RFC 17001. В этом разделе рассматриваются некото-
рые из наиболее важных атрибутов. Другие, такие как адрес, имя, номер порта
1 RFC 1700 больше не содержит все выделенные номера Интернета. За дополнительной информацией
обратитесь по адресу www.ietf.org и перейдите по ссылке IANA.
Пример обмена сообщениями в RADIUS 127
и т. д., не будут обсуждаться, поскольку их предназначение или очевидно, или
ясно из названия (так назначение атрибута Пароль-Пользователя — хранить пароль
пользователя).
Атрибут Тип-Сервиса. Этот атрибут задает тип запрошенного пользователем серви-
са. Существуют следующие виды сервисов:
О Начало сеанса: Пользователь должен бьггь соединен с узлом.
О Фреймовый: Фреймовый протокол должен быть использован для работы с
пользователем, например асинхронные фреймы РРР.
О Начало сеанса с обратным вызовом: Сервер должен отсоединиться от пользова-
теля и позвонить самому, а затем соединить пользователя с узлом.
О Фреймовый, с обратным вызовом: Сервер должен отсоединиться от пользовате-
ля и позвонить самому, а затем использовать фреймовый протокол.
О Исходящий доступ: Пользователь должен получить доступ к выходным устрой-
ствам.
О Административный: Пользователь должен получить доступ к интерфейсу адми-
нистратора NAS, при помощи которого могут быть выполнены привилегиро-
ванные команды.
О Приглашение NAS: Пользователь должен получить доступ к командной строке
NAS, с которой могут быть выполнены непривилегированные команды.
О Только идентификация: Запрашивается только идентификация, а информация
авторизации не посылается в Разрешение-Доступа (обычно используется про-
кси-серверами, а не самим NAS).
О Приглашение NAS с обратным вызовом: Сервер должен отсоединиться от пользо-
вателя и позвонить самому, а затем пользователь должен получить доступ к
командной строке NAS, с которой могут быть выполнены непривилегирован-
ные команды.
Фреймовый-MTU. Определяет максимальный размер передаваемого блока (MTU),
используемого с данным пользователем. Может быть опущен, если для настрой-
ки MTU применяется РРР.
IP-Адрес-Узла-Доступа. Используется для передачи адреса предпочтительного узла
доступа. Сервер не обязан его использовать.
Способ-Доступа. Определяет, каким способом пользователь соединяется с серве-
ром. Примерами могут быть TELNET, rlogin и LAT.
Номер-Обратного-Вызова. Задает номер обратного вызова. Служит подсказкой сер-
веру, но сервер не обязан совершать этот обратный вызов.
Фреймовый-Маршрут. Содержит информацию о маршруте пользователя NAS. Дол-
жен состоять из адресов назначения и шлюза.
Простой-Сеанса. Устанавливает максимальное количество секунд обслуживания
перед тем, как этот сеанс будет прекращен или приглашение будет послано.
128 Глава 7. Протоколы коммутируемых соединений РАР, CHAP, RADIUS и DIAMETER
Задержка. Устанавливает максимальное количество последовательных секунд про-
стоя соединения перед тем, как сеанс связи будет прекращен или приглашение
будет послано.
Действие-При-Рассоединении. Указывает, какое действие должен предпринять NAS
при завершении обслуживания.
Идентификатор-Звонящей-Стороны. Содержит номер звонящей стороны.
Состояние-Прокси-Сервера? Посылается прокси-сервером другому серверу, когда
прокси-сервер пересылает сообщение Запрос-Доступа.
Тип-Порта-NAS. Задает тип физического порта у NAS, идентифицирующего пользо-
вателя. Например, асинхронный, синхронный ISDN, асинхронный ISDN V.120 и
асинхронный ISDN V.110.
Пример обмена данными с RADIUS
В этой части главы будут приведены примеры обмена данными между NAS (кли-
ент RADIUS) и RADIUS-сервером. В первом примере, показанном на рис. 7.7, NAS с
адресом 192.168.1.16 посылает пакет Запрос-Доступа серверу RADIUS для пользо-
вателя «улисс», соединяющегося с портом 3. Идентификатор запроса (Request
Authenticator — RA) устанавливается равным 16-байтному случайному числу
(Random Number — RN). Поле Пароль-Пользователя заполняется результатом опе-
рации исключающее ИЛИ с паролем пользователя (дополненным нулями, если
нужно) и результатом функции MD5 (общий секретный код ИЛИ идентифици-
рующее число запроса). RADIUS-сервер проверяет это сообщение и посылает NAS
пакет Разрешение-Доступа с тем, чтобы он перенаправил по TELNET пользователя
«улисс» к узлу 192.168.1.3. РЧА в данном пакете является контрольной суммой
кода, идентификатора, длины, идентифицирующего числа из пакета Запрос-Дос-
тупа, атрибутов ответа и общего секретного кода (Shared Secret - SS).
Второй пример, показанный на рис. 7.8, приведен для иллюстрации случая, ког-
да пользователь использует фреймовый протокол (РРР), а для идентификации
использует CHAP (на рис. 7.5 показан обмен данных на стороне пользователя).
NAS с адресом 192.168.1.16 посылает UDP-пакет Запрос-Доступа серверу RADIUS о
том, что пользователь «улисс» соединяется с портом 20 по протоколу РРР и иден-
тификацией по протоколу CHAP. NAS извещает сервер RADIUS при помощи атрибу-
тов Тип-Сервера и Фреймовый-Протокол, что пользователь использует РРР. RADIUS
проверяет «улисс» и посылает пакет Разрешение-Доступа NAS-клиенту с тем, чтобы
он начал обмен данными по протоколу РРР и назначил IP-адрес пользователю.
Обратите внимание на тот факт, что сервер также возвращает дополнительные
атрибуты касательно фреймового протокола.
Пример обмена сообщениями в RADIUS 129
Рис. 7.7. Пользователь соединяется по TELNET с заданным узлом [RFC2138]
Клиент Сервер
RADIUS RADIUS
Рис. 7.8. Поддержка РРР и CHAP
130 Глава 7. Протоколы коммутируемых соединений РАР, CHAP, RADIUS и DIAMETER
Проблемы RADIUS
Возможности RADIUS в некоторой степени ограниченны из-за его структуры ко-
манд и атрибутов, что в результате и привело к созданию новой системы. RADIUS
работает поверх протокола UDP, который не имеет таймеров и механизмов пере-
сылки потерянных данных. Поэтому производители программ разрабатывали свои
собственные реализации таких функций. Кроме того, в RADIUS предполагается,
что сервер не посылает клиенту сообщений по своей инициативе, что еще более
ограничивает его гибкость. Преемник RADIUS — DIAMETER — разрешил все эти
проблемы.
DIAMETER
DIAMETER — это сравнительно новое добавление в реестр средств безопасности
Интернета. Появилось оно из-за увеличивающегося количества предлагаемых
в Интернете услуг, поэтому маршрутизаторы и серверы доступа к сети (NAS) дол-
жны были претерпеть изменения, чтобы обеспечить их работу. Кроме того, про-
изводители и рабочие группы разрабатывают свои собственные протоколы, об-
служивающие предоставление этих услуг.
DIAMETER предоставляет стандарт для определения заголовков, расширений ме-
ханизмов безопасности, команд, пар Атрибут-Значение (Attribute Value Pair —
AVP). Основной идеей было использовать в новых сервисах DIAMETER вместо
множества разнообразных процедур, разработанных ранее. DIAMETER считается
преемником RADIUS, и его предназначение — предоставить возможность иденти-
фикации, учета и авторизации. Архитектура DIAMETER определена в [CALH98]1,
а нижеследующие разделы являются кратким изложением этого рабочего доку-
мента.
Формат сообщения DIAMETER
В этом разделе описываются форматы сообщения DIAMETER, включая заголовок
hAVP.
Заголовок сообщения
На рис. 7.9 показан формат заголовка сообщения DIAMETER. Поля выполняют
следующие функции: .
О Код совместимости пакета (КСП) RADIUS: Используется для обратной совмести-
мости с RADIUS. Его значение равно 254, что обозначает пакет DIAMETER, и таким
образом сервер может поддерживать работу с обоими протоколами.
О Флаги: Применяется для обозначения опций DIAMETER.
* [CALH98], Calhoun, Pat R., draft-calhoun-diameter-07.txt November 1998.
Формат сообщения DIAMETER 131
О Опция W-бита: Этот бит устанавливают тогда, когда поля Следующее Посыла-
. емое и Следующее Принятое присутствуют в заголовке. Этот бит устанавли-
вается в том случае, если TCP не обеспечивает подтверждение доставки дан-
ных.
О Версия: Это поле устанавливается равным 1.
О Длина пакета: Указывает длину пакета, включая заголовок.
О Идентификатор: Используется для сопоставления запросов и ответов.
О Следующее Посылаемое: Номер посылаемого сообщения.
О Следующее Полученное: Номер полученного сообщения, используется для под-
тверждения получения ранее посланных сообщений.
О AVP: Пары Атрибут-Значение, описываются ниже.
0 2-7 8 9-11 12 14-15 16 17 18-30 31
КСП RADIUS Флаги W Версия Длина пакета
Идентификатор
Следующее Посылаемое Следующее Полученное
AVP...
Рис. 7.9. Заголовок AVP
Тело сообщения (AVP)
Атрибуты сообщения DIAMETER предназначены для передачи информации иден-
тификации, учета и авторизации. Кроме того, в них содержится информация о
настройках данного сеанса связи. Формат тела сообщения показан на рис. 7.10.
Его поля выполняют следующие функции:
О Код AVP: Содержит код AVP. Первые 256 значений зарезервированы с целью
совместимости с RADIUS. Их значения вы можете найти по адресу www.ietf.org
(нужно перейти по ссылке IANA). Все значения больше 256 зарезервированы
за DIAMETER и выделяются IANA.
О Длина AVP: Задает длину атрибута.
О Зарезервировано: Для будущего использования.
О Флаги AVP: Эти шесть флагов информируют DIAMETER-сервер о том, как нужно
обрабатывать каждый атрибут. Бит О (обязательный) говорит о том, необхо-
дима ли поддержка данного AVP. Если получатель не поддерживает данный
атрибут, то запрос отвергается. Бит П обозначает, что данные шифруются в
режиме пересылка-за-пересылкой, тогда как К обозначает из-конца-в-конец.
132 Глава 7. Протоколы коммутируемых соединений PAP, CHAP, RADIUS и DIAMETER
Бит Р (рааработчик) говорит о том, имеется ли поле идентификатора разра-
ботчика в заголовке AVP. Бит Т (тег) используется тогда, когда нужно сгруп-
пировать наборы AVP, если для выражения условия нужно несколько AVP. Бит
3 (защищенный) говорит о том, применяется ли для AVP цифровая подпись.
О Идентификатор разработчика: Используется разработчиками расширения набора
атрибутов DIAMETER.
О Тег: Используется группой атрибутов в одном и том же пакете, ссылающихся
на один и тот же туннель.
О Данные: Содержит относящуюся к атрибуту информацию.
0 2-30 31
Код AVP
Длина AVP Зарезервировано 0 П К Р Е 3
Идентификатор разработчика (необязательно)
Тег(необязательно)
Данные
Рис. 7.10. Тело сообщения AVP
AVP DIAMETER-команда
Эта AVP идет сразу за заголовком, и ее формат показан на рис. 7.11. Эта AVP
задает команду, ассоциированную с данным сообщением. Поля в теле сообще-
ния выполняют следующие функции:
О Код AVP: Равен 256, что обозначает DIAMETER-команду
О. Длина AVP: Длина атрибута.
О Флаги AVP: Предназначение этих битов было объяснено ранее. Для этой AVP
бит О устанавливается. Биты П и К устанавливаются в зависимости от ис-
пользуемой модели безопасности. P-бит может быть установлен, если код
команды не везде реализован. Биты Т и 3 не должны быть установлены.
О Код команды: Содержит номер команды, причем следующие команды должны
быть обязательными:
Отказ-Сообщения-Инд’256
Перегрузка-Устройства-Инд=257
Сторож-Устройства-Инд=258
Формат сообщения DIAMETER 133
0 2-30 31
Код AVP
Длина AVP Зарезервировано О П К Р Т 3
Код команды
Рис. 7.11. AVP DIAMETER-команда
Команда Отказ-Сообщения-Инд
Эта команда используется для предоставления диагностирующей информации
(и индикации ошибок) о полученных сообщениях. Ее формат показан на рис. 7.12.
Это сообщение содержит ту же самую идентификацию и номер сеанса связи, что
и сообщение, которое ее вызвало. Поля этого сообщения выполняют следующие
функции:
О Код AVP: Устанавливается равным 256.
О Длина AVP: Длина атрибута.
О Флаги AVP: Бит О устанавливается. Биты П и К устанавливаются в зависимо-
сти от используемой модели безопасности. Биты Р, К и Р не должны быть
установлены.
О Код команды: Устанавливается равным 256.
0 2-30 31
Код AVP
Длина AVP Зарезервировано О п к р т 3
Код команды
Рис. 7.12. AVP-команда Отказ-Сообщения-Инд
Как устроены остальные сообщения
Остальные DIAMETER-сообщенйя устроены по тому же принципу, что и те, кото-
рые мы уже рассмотрели. Для краткости далее будет даваться только предназна-
чение этих сообщений без повторения рисунков, иллюстрирующих их формат.
134 Глава 7. Протоколы коммутируемых соединений PAR CHAP, RADIUS и DIAMETER
Перезагрузка-Устройства-Инд. Устройство DIAMETER посылает это сообщение всем
сторонам с тем, чтобы известить, что или перезагрузка скоро произойдет, или
только что произошла. Это сообщение также используется для обмена версией
вспомогательного протокола, а также всеми поддерживаемыми расширениями.
Сторож-Устройства-Инд. Это сообщение используется для извещения сторон, что
устройство работает.
IP-Адрес-Узла и Иня-Узла. Эти атрибуты предназначены для IP-адреса и названия
отправителя. Их предназначение — поставить получателя в известность о том,
кто отправил сообщение.
Состояние. Когда сервер посылает сообщение, которое порождает множество со-
общений, посылаемых в обе стороны, то применяется эта ДУР для сохранения
информации о состоянии сервера. DIAMETER использует надежный транспортный
механизм (таймеры) для обеспечения этой операции.
Класс. Эта AVP задается конкретной реализацией и используется в процессе иден-
тификации. Здесь может содержаться информация об учетной записи, необхо-
димая для работы учетного сервера.
Тайнаут-Сеанса. Этот атрибут задает максимальное число секунд от начала сеанса
до того, как он будет либо прерван, либо дано приглашение. Этот атрибут пере-
дается с сервера.
Идентификатор расширения. Эта AVP используется для идентификации конкретно-
го расширения DIAMETER. Она может применяться в командах Перезагрузка-Уст-
ройства-Инд и Ответ-Возможности-Устройства с тем, чтобы поставить другую сторо-
ну в известность о поддерживаемых расширениях.
Вектор-Проверки-Целостности (ВПЦ). AVP Вектор-Проверки-Целостности использу-
ется при идентификации и проверке целостности данных в случае пересылка-за-
пересылкой и не рекомендуется к использованию в случае внешних (untrusted)
прокси-серверов. Заголовок DIAMETER, также как и все AVP (включая дополнен-
ные данные) вплоть до данной AVP, защищены Вектором-Проверки-Целостности. АУР
Отнетка-Вренени используется для защиты ответов, а AVP Вектор-Инициализации при-
меняются для повышения случайности этого пакета.
Применение AVP ВПЦ требует предварительно заданного общего секретного
ключа. И хотя этот механизм не масштабируется также хорошо, как цифровая
подпись, может оказаться желательным использовать этот механизм, когда ис-
пользование асимметричных ключей или не требуется или невозможно.
Функция НМАС выполняется следующим образом:
hmac_md5(DIAMETERmessage. Messagelength. Secret. SecretLength, Output)
Идентификатор-Преобразования. Поле Идентификатор-Преобразования содержит значе-
ние, которое указывает на то, какое преобразование было использовано при вы-
числении ВПЦ. Алгоритм MD5-HMAC-96 выделен специально для DIAMETER.
Вектор-Инициализации. АУР Вектор-Инициализации должна быть помещена в сообще-
ние до АУР ВПЦ и используется для гарантирования случайности в сообщении.
Содержимым этой АУР должно быть значение длиной, как минимум 128 бит.
Формат сообщения DIAMETER 135
Отметка-Времени. Эта AVP используется для увеличения надежности защиты про-
токола DIAMETER от повторения. AVP Отметка-Времени должна появиться до ВПЦ
или любой другой AVP проверки целостности, определенной в расширениях. Ее
значением являются старшие 4 байта, полученные с помощью протокола време-
ни сети (Network Time Protocol — NTP), что обозначает количество секунд, прошед-
ших с наступления 1 января 1970 года.
Идентификатор-Сеанса. Эта АУР применяется для идентификации отдельных сеан-
сов связи. Обратите внимание, что в некоторых приложениях нет понятия сеан-
са, например, нет потока данных, и это поле может быть использовано для иден-
тификации объектов, отличных от сеанса. AVP Идентификатор-Сеанса создается
устройством DIAMETER, инициировавшим сеанс, что в большинстве случаев дела-
ется клиентом. Идентификатор-Сеанса может использоваться больше чем одним
расширением.
Имя-Разработчика. Атрибут Имя-Разработчика используется для извещения другой
стороны о том, кто разработал устройство DIAMETER. Это может быть полезным
для того, чтобы узнать, какие атрибуты могут быть посланы другой стороне.
Версия-Программы. Эта AVP используется для оповещения другой стороны о номе-
ре версии программного обеспечения устройства, посылающего сообщение.
Код-Результата. AVP Код-Результата говорит о том, выполнилась та или иная ко-
манда успешно или случилась ошибка. Эта AVP должна присутствовать во всех
сообщениях DIAMETER, имеющих тип Запрос или Ответ. 32-битное значение поля
содержит код результата выполнения соответствующей DIAMETER-команды. Вот
эти коды:
О DIAMETER_SUCCESS-O: Запрос был успешно выполнен.
О DIAMETER_FAILURE-1: Запрос не был успешно выполнен, и в сообщении, со-
держащем этот код, должна находиться AVP, послужившая причиной Отказа.
О DIAMETER_POOR_REQUEST-2: Запрос был неправильно составлен и в сообщении,
содержащем этот код, должна находиться AVP, послужившая причиной от-
каза.
О DIAMETER_INVALID_MAC-3: Запрос не содержит правильный Вектор-Проверки-Цело-
стности или цифровую подпись.
О DIAMETERJJNKN0WN_SESSI0NJD-4: Запрос содержит неизвестный идентификатор
сеанса.
О DIAMETER_SEE_ERR0R_C0DE-5: Здесь содержится конкретная информация о возник-
шей проблеме и AVP, послужившей причиной отказа.
О DIAMETER_C0MMAND_UNSUPP0RTED-6: DIAMETER-сообщение запроса содержит код
команды, которая неизвестна или не поддерживается.
О DIAMETER_ATTRIBUTE_USUPP0RTED=8: DIAMETER-сообщение запроса содержит AVP,
которая не поддерживается.
136 Глава 7. Протоколы коммутируемых соединений RAP, CHAP, RADIUS и DIAMETER
Код-Ошибки. Эта AVP содержит код ошибки (если она случилась) соответствую-
. щего сообщения. Код-Ошибки нужно передавать только в том случае, если AVP Код-
Результата содержит код DIAMETER_SEE_ERROR_CODE.
Нераспознанный-Код-Команды. Эта AVP содержит код команды, приведший к посыл-
ке сообщения Отказ-Сообщения-Инд.
Тип-Перезагрузки. Если произошла перезагрузка узла DIAMETER, в этой AVP пере-
дается тип выполненной перезагрузки, такой как устройство было перезагруже-
но и теперь готово к работе, или устройство в процессе перезагрузки и т. д.
Время-Переза грузки. Эта AVP задает количество секунд до того момента, когда
отправитель этого сообщения ожидает, что он будет снова готов принимать со-
общения. Это значение является оценочным и не должно восприниматься как
обязательное.
Код-Отказа-AVP. Эта AVP содержит отладочную информацию в случаях, когда зап-
рос был отклонен или был не полностью обработан по причине ошибочных дан-
ных в отдельных AVP.
Имя-Пользователя. В этом атрибуте содержится имя пользователя в формате, соот-
ветствующем спецификации NAI.
Базовые операции
Шифрация AVP методом общего секретного кода является самой простой в ис-
пользовании и должна поддерживаться во всех реализациях DIAMETER. В этом
разделе будет дан краткий обзор функционирования DIAMETER, сделанный по
черновым документам IETE
П-бит должен быть установлен только в случае, когда общий секретный код из-
вестен обеим сторонам. Если этот бит установлен в каком-либо AVP, то Вектор
Инициализации AVP должен быть передан до того, как будет послана первая зашиф-
рованная AVP.
В поле Открытый-Текст содержатся данные, предназначенные для шифрации.
Хэш-функция MD5 в качестве аргумента получает конкатенацию следующих
значений:
О Два байта AVP Код-Команды.
О Общий идентификационный секретный код.
О Вектор случайных чисел произвольной длины.
Значения этого вектора, используемые при вычислении хэш-кода, передаются в
поле данных AVP Вектор-Инициализации. Этот Вектор-Инициализации должен появиться
в сообщении до первого зашифрованного AVP. Один и тот же Вектор-Инициализа-
ции может использоваться в нескольких зашифрованных AVP одного сообщения.
Если другое значение AVP Вектор-Инициализации используется для шифрации по-
следующих AVP, то тогда это новое значение AVP Вектор-Инициализации должно
быть расположено перед первым AVP, к которому оно применяется.
Использование DIAMETER для соединения с SS7 по коммутируемым линиям
137
Затем выполняется операция исключающее ИЛИ с результатом MDS-функции
и первыми 16 байт или младшим сегментом AVP Субформат и результат помеща-
ется в поле данных этого AVP. Если АУР Субформат содержит значение короче,
чем 16 байт, то тогда Субформат преобразуется перед этой операцией исключаю-
щее ИЛИ таким образом, как будто поле Значение дополняется до 16 байт, но
модифицируются только имеющиеся в Субформат байты, а длина этой AVP не из-
меняется. Если длина AVP Субформат больше, чем 16 байт, тогда вторая MDS-фун-
кция выполняется над поток'ом байт, состоящим из общего секретного кода, за
которым следует результат первой операции исключающее ИЛИ. Полученный
хэш-код и вторая часть Субформат (16 или менее байт) подвергаются операций
исключающее ИЛИ и помещаются в соответствующие байты поля Данные. Если
нужно, то этот алгоритм повторяется и результат хэшируется вместе с общим
секретным кодом, после чего выполняется операция исключающее ИЛИ над по-
лученным хэш-кодом и следующим сегментом данных. Таким образом получает-
ся зашифрованное значение AVP, а его длина по-прежнему известна.
По получении используется последний Вектор-Инициализации, найденный в дан-
ном сообщении перед дешифруемым AVP. Для получения исходных данных опи-
санный выше процесс выполняется в обратном направлении. За более подроб-
ной информацией об этом методе шифрации обратитесь к RFC 2138.
Обратите внимание на то, что в случае, когда DIAMETER-сообщение должно быть
обработано чужим промежуточным DIAMETER-сервером (называемым также про-
кси-сервером, DIA2 на рис. 7.13), AVP должна быть дешифрована общим секрет-
ным кодом 1 и зашифрована обратно с общим секретным кодом 2.
Рис. 7.13. Чужой DIAMETER-сервер
Использование DIAMETER для соединения
с SS7 по коммутируемым линиям
Одной из наибольших проблем, стоящих перед Интернет-телефонией, является
взаимодействие с существующими телефонными сетями. Существует множество
точек зрения на то, как это осуществить. Одни полагают, что такое взаимодей-
ствие должно свестись к нулю, и использования телефонных сетей нужно по воз-
можности избегать. Другие говорят, что интернет-услуги должны разрабатываться
так, чтобы взаимодействовать с телефонными сетями с тем, чтобы воспользоваться
многочисленными услугами и интеллектуальными возможностями, предостав-
ляемыми телефонной системой SS7.
138 Глава 7. Протоколы коммутируемых соединений PAP, CHAP, RADIUS и DIAMETER
Вне зависимости от чьей-либо точки зрения по этому вопросу, в этом разделе
объясняется работа шлюза, находящегося между телефонной сетью и сервером
доступа в сеть (NAS), и вкратце излагаются основные понятия [GREE98]1.
В этом документе описывается архитектурная основа для стандартизации взаи-
. модействия Интернета с телефонной сетью. Это взаимодействие имеет дело как
с сигнальными (signaling), так и с несущими соединениями (например, разно-
форматный поток данных, такой как VoIP), которые могут быть либо совмест-
ными (например, внутриполостные, BRI, PRI), либо раздельными (например, SS7).
Когда сигнальные соединейия совмещены с несущими, они приходят прямо в
NAS. Когда же сигнализация разделена, то она проходит через Сигнальный шлюз
и/или NAS-контроллер (Signaling Gateway/NAS Controller — SGNC), прежде чем
дойдет до NAS. В [GREE98] описываются расширения DIAMETER, которые позво-
ляют установить сеанс связи от NAS через Сигнальный шлюз/НА5-контроллер и
от Сигнального шлюза/ИА5-контроллера к NAS. В этой части главы кратко изла-
гаются основные понятия документа [GREE98].
Обмен сообщениями при установке сеанса
Сигнальный шлюз/МА$-контроллер (SGNC)
Запрос-Установки-Сеанса. Это сообщение посылается от NAS к SGNC и от SGNC к
NAS. Эта команда может быть послана от NAS к SGNC, когда сигнализация звон-
ка находится на NAS. Такое происходит в случае сигнализации PRI. Если нужна
идентификация пользователя, то тогда должна быть использована процедура,
описанная в [CALH98a]2.
Эта команда посылается от SGNC к NAS, когда сигнализация звонка находится
на SGNC. Это и имеет место в случае с сигнализацией в SS7. В случае если для
входящих звонков требуется идентификация пользователя, смотрите [CALH98a].
В этом случае обмен сообщениями Запрос/Ответ идентификации производится
от NAS к SGNC, кроме того, он будет производиться внутри обмена сообщения-
ми Запрос-Установки-Сеанса и соответствующего ответа, инициированного SGNC.
Заметьте, что идентификатор сеанса, используемый в этих обменах, будет один
и тот же.
Для входящей части звонка VoIP сообщение Запрос-Установки-Сеанса идет или от
SGNC к NAS или шлюзу VoIP, или наоборот, в зависимости от сигнализации око-
нечного устройства. Для исходящей части сообщение всегда посылается от SGNC
к шлюзу VoIP. В случае когда имеет место PRI-сигнализация, сообщение Ответ-
Установки-Сеанса отправляется по завершении звонка. В случае 557-сигнализации
сообщение Запрос-Установки-Сеанса посылается после того, как исходящая часть
была задана посредством сигнализации SS7.
1 [GREE98]. www.ietf.org, greene-diameter-ss7-session-00.txt, July 1998.
2 [CALH98a]. Calhoun, Р. R., Billy, W., DIAMETER User Authentication Extensions, draft-calhoun-
diameter-authen-03.txt, April 1998.
Использование DIAMETER для соединения с SS7 по коммутируемым линиям 139
AVP Маркер-Ресурсов содержит все ресурсы, выделенные пользователю данно-
го сеанса на данный момент. Например, здесь может содержаться информация о
канале связи, которому был назначен данный SS7-3bohok. Ресурсы, используе-
мые при различной сигнализации и шлюзах VoIP, описываются как AVP в дру-
гом расширении DIAMETER.
Идентификатор-Расширения обозначает номер расширения DIAMETER, к которому
принадлежит сообщение (и переданные в нем AVP). Если сообщение принадле-
жит к более чем одному расширению, тогда должны быть приведены несколько
полей Идентификатор-Расширения.
Ответ-Установки-Сеанса. Это сообщение содержит тот же самый Идентификатор-Се-
анса, что и Запрос-Установки-Сеанса. Должен присутствовать Код-Результата, кото-
рый будет использован для определения того, был ли сеанс успешно установлен
или нет.
Запрос-Добавить-Ресурс. Это сообщение посылается от SGNC к NAS или от NAS к
SGNC. Когда оно отправлено от SGNC к NAS, то предполагается, что авториза-
ция на запрашиваемый ресурс уже дана. Если Запрос-Добавить-Ресурс содержит
Идентификатор-Сеанса, который уже в процессе установки, то запрашиваемый ре-
сурс добавляется к этому сеансу. Если этот ресурс уже выделен данному сеансу,
то сообщение Запрос-Добавить-Ресурс интерпретируется как запрос на изменение
параметров. Например, в случае канала связи приложение может попросить из-
менить параметры канала так, чтобы шифровались все последующие данные,
посылаемые по этому каналу. Возможна также ситуация, когда ресурс принадле-
жит больше чем одному сеансу. Например, тот же канал связи может быть одно-
временно использован несколькими сеансами.
Сообщение Запрос-Добавить-Ресурс может иметь Идентификатор-Сеанса, принадле-
жащий вспомогательному сеансу. Запросы ресурсов, посланные вспомогательным
сеансом, относятся к ресурсам вне сеансов или к разделяемым ресурсам.
Ответ-Добавить-Ресурс. Это сообщение посылается в ответ на Запрос-Добавить-Ре-
сурс. AVP Маркер-Ресурсов включается в это сообщение только в случае, если сеанс
содержит ресурсы, нуждающиеся в управлении.
Пример обмена сообщениями
В этом разделе приведены несколько примеров обмена сообщениями между PSTN,
SGNC и NAS. Первые два примера показывают обмен сообщениями при установ-
ке сеанса SS7. На рис. 7.14 приведен пример сеанса SS7, порождаемого SGNC, а на
рис. 7.15 — порождаемого NAS.
На рис. 7.16 показана установка сеанса от SGNC к NAS, с успешной проверкой
целостности канала. Из рисунка ясно то, как сообщения установки сеанса и за-
проса ресурса могут быть использованы при тестировании целостности канала
связи перед тем, как установить соединение.
140 Глава 7. Протоколы коммутируемых соединений РАР, CHAP, RADIUS и DIAMETER
Рисунок 7.14. Установка сеанса SS7, порождаемого SGNC
Ответ-Установки-Сеанса
Рис. 7.15. Установка сеанса SS7, порождаемого NAS
Запрос-Установки-Сеанса
Запрос-Добавить-Ресурс
ест целостности канала X)
Ответ-Добавить-Ресурс
IAM (установлен бит
проверки целостности канала)
________СОТ (проверка
целостности канала пройдена)
Ответ-Установки-Сеанса
АСМ
ANM
Рис. 7.16. Установка сеанса с тестом целостности канала
Сообщение Запрос-Добавить-Ресурс, отправленное от SGNC к NAS, используется
для запуска проверки целостности канала. Если тест пройден успешно, то SGNC
посылает сообщение Запрос-Установки-Сеанса.
На рис. 7.17 приведена установка сеанса SS7 рт SGNC к NAS, в которой тест цело-
стности канала не удался. Если другая сторона индицирует сбой, то SGNC посы-
Использование DIAMETER для соединения с SS7 по коммутируемым линиям 141
лает NAS сообщение Запрос-Добавить-Ресурс с запросом перевести данный канал в
режим ремонта. Установка сеанса была инициирована SGNC.
_______СОТ (проверка________
целостности канала не удалась)
RLC или BLO
СОТ (проверка целостности
канала не удалась)
CCR
LPA
1АМ (установлен бит____
проверки целостности канала)
Ответ-Добавить-Ресурс
Запрос-Добавить-Ресурс
(перевести канал X
в режим ремонта)
Рис. 7.17. Установка сеанса с неуспешной проверкой целостности канала.
Запрос-Добавить-Ресурс
(перевести канал X а режим ремонта)
Ответ-Добавить-Ресурс
Запрос-Добавить-Ресурс
(тест целостности канала X)
Ответ-Добавить-Ресурс
На рис. 7.18 показана установка сеанса SS7 от NAS к SGNC с успешно выполнен-
ным тестом целостности канала и то, как сообщения установки сеанса и запроса
ресурса могут быть использованы при тестировании целостности канала связи
перед тем, как установить соединение. Установка сеанса была инициирована NAS.
СОТ (проверка целостности
канала пройдена)
ANM________________
IAM (установлен бит
проверки целостности канала)
Звпрос-Установки-Сеанса
Ответ-Установки-Сеанса
Запрос-Добавить-Ресурс w
(тест целостности канала X) “
,Ответ-Добавить-Ресурс
NAS
Рис. 7.18. Установка сеанса SS7 от NAS к SGNC с успешно выполненным тестом
целостности канала
142 Глава 7. Протоколы коммутируемых соединений PAP, CHAP, RADIUS и DIAMETER
На рис. 7.19 показана установка сеанса SS7 от NAS к SGNC с неуспешно пройден-
ным тестом целостности канала. Если NAS выдаст ошибку, SGNC пошлет ему
сообщение Запрос-Добавить-Ресурс с запросом перевести проблемный канал в ре-
жим ремонта.
SGNC
NAS
IAM (установлен бит
проверки целостности канала)
СОТ
(тест канала не удался)
CCR
LPA
СОТ
(тест канала не удался)
RLC или ВЮ
Запрос-Устиноекм-Саанса
Запрос-Добалмть-Ресурс
(тест целостности канала X)
Ответ-Добавитъ Ресурс
(тест канала не удался)
Запрос-Добавить-Ресурс
(тест целостности канала X)
Ответ-Добавить-Ресурс
(тест канала не удался)
Ответ-Устансаки-Сеанса
(установка связей не удалась) “
Запрос-Добавить-Ресурс w
(перевести канал X “
в режим ремонта)
- Ответ-Добаеить-Рвсурс
Рис. 7.19. Установка сеанса SS7 от NAS к SGNC с неудавшимся тестом целостности канала
Заключение
РАР и CHAP были базовыми протоколами в коммутируемых соединениях с Интер-
нетом. РАР не используется (или не должен использоваться) при внешних соеди-
нениях в силу слабости протокола идентификации. CHAP при идентификации
обычно использует MD5. RADIUS и DIAMETER являются значительным шагом впе-
ред в протоколах коммутируемых соединений и обеспечивают использование
серверов доступа к сети (NAS).
д ГЛАВА Архитектура IPSec
В этой главе описывается архитектура IPSec, базового интернет-протокола
защищенной передачи данных через внешние (untrusted) каналы связи и сети.
Будут обсуждены две базы данных IPSec: база данных правил безопасности
(Security Policy Database — SPD) и база данных ассоциаций безопасности (Security
Association Database — SAD), являющиеся реализациями ассоциации безопасно-
сти (Security Association — SA), понятия, введенного в главе 1. Объясняются транс-
портные и туннельные режимы IPSec, а также обсуждаются правила IPSec в от-
ношении туннелей и SA.
^ПРИМЕЧАНИЕ
Термины Идентификатор IP-протокола, Протокол, Следующий протокол соответствуют
полю в заголовке IPv4 или IPv6. Значения этого поля определяет тип информации,
находящейся в разделе данных датаграммы IP, такой как TCP, UDP, OSPF или ICMP.
ОсновыIPSec
IPSec был разработан Проблемной группой проектирования Internet (Internet
Engineering Task Force — IETF), в группе по разработке IPSec. На момент напи-
сания этой книги полная спецификация IPSec была близка к окончанию, а ос-
новные RFC уже завершены. Вы получите самую последнюю информацию об
этих спецификациях, которая будет дополнена ссылками и дополнительной биб-
лиографией. Кроме того, в это описание IPSec будет включен пример конкрет-
ной реализации этих новых RFC компанией IBM. Пример реализации IPSec, а так-
же дополнительные спецификации вы можете найти в [CHEN98]1.
' [CHEN98], Cheng, Р. С., Garay, J. A., Herzberg, A., Krawczyk, Н., A Security Architecture for the Internet
Protocol, IBM System Journal, Vol. 37, No. 1, 1998.
144 Глава 8. Архитектура IPSec
Возможности IPSec
IPSec был разработан с целью обеспечения обмена данными по протоколу IP (IPv4
и IPv6) следующими возможностями (описанными в главе 1): а) контроль доступа;
б) обеспечение сохранности данных, независимой от соединения (connectionless
integrity); в) идентификация происхождения; г) защита от повторения, куда
входит и частичное обеспечение целостности последовательности; д) секретность/
конфиденциальность (шифрование данных).
Разумеется, мера, в которой используются эти возможности, зависит от админи-
стратора по безопасности. IPSec — это средство, причем мощное, но его эффек-
тивность зависит от того, как его используют.
IPSec не накладывает никаких ограничений на то, где он может применяться. Тем
не менее, его возможности должны использоваться на пользовательском узле или
шлюзе безопасности. Такой шлюз безопасности является компьютером, незави-
симым от пользовательского узла, например, это может быть маршрутизатор или
сервер.
I
IPSec-протоколы защиты передачи данных
Эти возможности IPSec обеспечиваются двумя протоколами защиты передачи
данных, заголовок идентификации (Authentication Header — АН) и вложенные
защищенные передаваемые данные (Encapsulated Security Payload — ESP). Кро-
ме этих, применяются и другие протоколы, не определенные в спецификациях
IPSec. АН и ESP являются частью IPSec. Мы ознакомимся с ними в этой главе и
обсудим более подробно в главе 9.
Базы данных ассоциаций безопасности (SA)
IPSec нуждается в изрядном количестве информации для обеспечения безопас-
ности пользователей. Проще говоря, он должен знать об ассоциации безопасно-
сти пользователя. Как вы, наверно, помните, SA определяет, какие услуги по обес-
печению безопасности предоставляются пользователю.
Эти требования к безопасности хранятся в двух базах данных. Их собирательно
называют базами данных ассоциаций безопасности. Они являются хранилища-
ми информации для IPSec, и их содержимое (то, как оно сконфигурировано ад-
министратором безопасности) управляет «поведением» IPSec. Я только знаком-
лю вас с ними в нашем начальном обсуждении IPSec. В дальнейшем мы более
подробно поговорим об этих базах данных.
ТуннельIPSec
Для того чтобы перейти к дальнейшему обсуждению IPSec, мы сначала должны
ввести понятие защищенного туннеля IP в том контексте, в котором он исполь-
Ассоциация безопасности (SA) 145
зуется в IPSec. Смотрите рис. 8.1. Вообще говоря, понятие туннеля передает идею
безопасной передачи данных между двумя системами через внешнюю (небезо-
пасную) сеть. Интернет является типичным примером небезопасной сети, и так
же небезопасны коммутируемые соединения.
Пользователь А Пользователь Б
Защищенные данные |
Рис. 8.1. Туннель безопасности IP
Процесс передачи данных предполагает задействование правил безопасности,
принятых в системах, между которыми эти данные передаются. Эти правила
безопасности (также называемые мета-характеристиками) включают в себя ад-
реса соединяющихся сторон, метод форматирования (при помощи которого ин-
формация будет помещаться в блоки данных другого протокола), шифроваль-
ные алгоритмы, параметры этих алгоритмов (сюда входйт размер ключа и время
его действия).
Защищенный туннель IP относится ко всем процедурам (включая протоколы,
методы шифрации и т. д.), которые обеспечивают защищенную передачу данных
между двумя системами. И снова подчеркиваю, этот набор возможностей и на-
зывается ассоциацией безопасности (SA). Но вы должны понимать, что SA и тун-
нель не одно и то же. Правильней сказать, что туннель создается на основе SA.
Ассоциация безопасности (SA)
Мы узнали, что ассоциация безопасности задает набор элементов (и процедур),
разделяемых между двумя соединяющимися системами. Ее предназначение —
защитить процесс обмена информацией между этими двумя сторонами. SA в IPSec
определяет следующие данные как часть ассоциации безопасности. Смотрите
рис. 8.2 с графическим представлением этих понятий.
Пользователь Б
Пользователь А
1. IP-адрес получателя
2. Протокол безопасности
^3. Секретные ключи
4. Метод форматирования
5. (SPI)
Рис. 8.2. Ассоциация безопасности (SA) и туннель безопасности IP
146 Глава 8. Архитектура IPSec
О IP-адрес получателя.
О Протокол безопасности, используемый при передаче данных.
О Секретные ключи, применяемые при шифрации.
О Метод форматирования, определяющий, каким образом создаются заголовки и
то, какая часть этих заголовков и данных пользователя будет защищена
в процессе передачи .данных.
О Индекс параметров защиты (Security Parameter Index — SPI) - один из
идентификаторов SA. Он определяет то, как принимающая сторона будет
обрабатывать поступающий поток данных.
В общем и целом, операции, выполняемые над данными пользователя, будут
определяться протоколом безопасности, методами шифрации и форматирования.
SA должна задаваться при помощи: a) SPI; б) IP-адреса получателя; в) идентифи-
катора протокола безопасности (АН или ESP). Обычно SA является однонаправ-
ленной, что означает, что она определяет выполняемые действия при передаче
данных в одну сторону. Тем не менее, туннель безопасности может быть двунап-
равленным. Это означает, что в случае передачи данных в обе стороны должны
использоваться две SA. Основной идеей двусторонней передачи данных являет-
ся использование двух SA с одинаковыми метахарактеристиками, но различны-
ми ключами. Эта идея известна под названием двунаправленных SA.
SA могут быть сгруппированы вместе (пакет SA) для обеспечения необходимых
свойств защиты данных. Например, одна SA может быть использована для шиф-
рации данных, другая — для обеспечения их целостности. Правилом для таких
пакетов SA является одинаковый IP-адрес получателя во всех SA пакета.
Случаи ассоциаций безопасности: обзор
Рабочая группа Но разработкам для сетей из IETF приводит несколько ассоциа-
ций безопасности, типичных для Интернета. Эти ассоциации называют «случа-
ями», и те четыре из них, что приводятся в этой части главы, необходимы для
работы IPSec-совместимых узлов и шлюзов безопасности. Эти случаи будут даны
в сжатом виде. Позже мы вернемся к ним и обсудим соглашения, принятые при
создании различных комбинаций туннелей безопасности.
На рис. с 8.3 по 8.6 приведены эти четыре случая. Я немного изменил использо-
ванную ранее терминологию. Мой обзор документа [KENT98]1 будет использо-
вать термины, принятые в этом документе. Термин «хост» в дальнейшем будет
означать IPSec-совместимый компьютер пользователя, а термин «шлюз безопас-
ности» будет означать IPSec-совместимый маршрутизатор или компьютер, обслу-
живающий хост (это может быть терминальный сервер и т. п.).
1 [KENT98], Kent, Stephen. Security Architecture for Internet Protocol, draft-letf-ipKc-MC-07-txt; этот
документ содержит обновления RFC 1829, July 1998.
Случаи ассоциаций безопасности: обзор 147
Случай 1: На рис. 8.3 показана ассоциация безопасности и соответствующий ей
туннель, соединяющий два хоста, обеспечивая таким образом сквозную защиту
передаваемых данных. При данном варианте Интернет (или Интранет) не имеет
понятия об этой ассоциации безопасности и не участвует в ней.
И
а
з
Рис. 8.3. Случай 1 .
Случай 2: На рис. 8.4 показано, что ассоциация безопасности и соответствующий
ей туннель располагаются между двумя шлюзами безопасности. Хосты осво-
бождены от забот относительно применения ассоциации безопасности, и пред-
полагается, что их связь со шлюзами осуществляется по безопасным соединениям.
В этом случае может использоваться одна SA для всего обмена данными внутри,
скажем, группы смежных подсетей.
Шлюз Шлюз
Рис. 8.4. Случай 2
Случай 3: Этот случай показан на рис. 8.5 и является комбинацией случаев 1 и 2.
В нем используется туннель, как между шлюзами безопасности, так и для прямой
связи между хостами.
Хост 1
Шлюз Шлюз
Рисунок 8.5. Случай 3
148 Глава 8. Архитектура IPSec
Случай 4: На рис. 8.6 показана частая ситуация, когда удаленный хост (Хост 1)
соединяется с организацией через Интернет или когда сервер находится позади
шлюза безопасности. Соединение происходит через Интернет. Примером такого
случая могут быть пользователи сотовых телефонов, находящиеся в команди-
ровках люди и т. д.
Рис. 8.6. Случай 4
Эта ситуация требует более сложных процедур (по сравнению с процедурами,
описанными в случаях с первого по третий). Например, как хост определяет
местоположение шлюза безопасности? Каким образом хост знает, что он соединя-
ется с правильным шлюзом и наоборот? IPSec предоставляет информацию, по-
зволяющую разрешить такого рода проблемы.
На этих рисунках не показаны различные компоненты Интернета, участвующие
в соединении, например поставщики услуг Интернета. Они не являются важны-
ми для нашего обсуждения, поскольку ассоциация безопасности и соответству-
ющий ей туннель устанавливаются, между хостом и шлюзом безопасности орга-
низации (например, брандмауэром, описанным в главе 4).
Типы SA: транспортный режим и туннельный режим
В IPSec определены два режима SA. В разделе 4.1 IPSec даются описания этих
режимов, а я рекомендую [KENT98c]‘. Кроме того, смотрите табл. 8.1 для обще-
го описания туннельного и транспортного режимов. На рис. 8.7, а показана струк-
тура исходного IP-пакета, на рис. 8.7, б показан пакет транспортного режима, а на
рис. 8.7, в — туннельного. Нужно заметить, что в случае использования ESP в э-
тих пакетах появятся два дополнительных поля: ES-концевик и значение МАС. Оба
эти поля помещаются после поля L 7, которое представляет обмен данными
Интернета уровня 7, такой как FTP, HTTP, rlogin и т. д.
* [KENT98c]. Kent, Stephen. Security Architecture for Internet Protocol, draft-ietf-ipsec-sec-O7-txt; этот
документ содержит обновления RFC 1825, July 1998.
Случаи ассоциаций безопасности: обзор 149
IP TCP или UDP L_7
а. IP-пакет
IP IPSec TCP или UDP L_7
б. Транспортный режим
IP IPSec IP TCP или UDP L_7
в. Туннельный режим
= обозначает возможные поля
ESP-концевик и значение МАС
Рис. 8.7. Режимы IPSec
Таблица 8.1. Режимы ассоциаций безопасности
Транспортный режим
• Между хостами
• Использует один IP-заголовок
• Защищает протоколы верхнего уровня
• j и, может быть, части IP-заголовка
Туннельный режим
• Между хостами и шлюзами
• Использует два IP-заголовка
• Защищает протоколы верхнего уровня и внутренний IP-заголовок
• j и, может быть, части внешнего IP-заголовка
Хост должен поддерживать как транспортный, так и туннельный режимы
Шлюзы безопасности должны поддерживать туннельный режим
Что защищается? Транспортный режим SA — это ассоциация безопасности меж-
ду двумя хостами1. В случае ESP SA в транспортном режиме защищает только про-
токолы верхнего уровня (уровень 4 и выше), а не IP-заголовок или заголовки
1 В IPv4 заголовок протокола безопасности транспортного режима появляется сразу после IP-заголовка
и опций и перед любым протоколом верхнего уровня (например, TCP или UDP). В IPv6 заголовок
протокола безопасности появляется после базового IP-заголовка и расширений, ио может появиться
также перед или после настроек получателя и перед протоколами верхнего уровня.
150 Глава 8. Архитектура IPSec
расширений, идущие перед ESP-заголовком. В случае АН защита распространяет-
ся на некоторые части IP-заголовка, заголовков расширений и некоторых настроек,
содержащихся в заголовке IPv4, заголовках расширений IPv6: Нор-Ву-Нор и
Destination.
SA в туннельном режиме — это SA в применении к IP-туннелю. Она должна ис-
пользоваться всегда, когда один из соединяемых компьютеров является шлюзом
безопасности. SA между двумя шлюзами безопасности должна находиться в тун-
нельном режиме, так же как и SA между хостом и шлюзом безопасности. Два хоста
могут использовать туннельный, режим SA для соединения друг с другом.
Термин «некоторые части» относится к тем полям в заголовке, что не изменяют-
ся в процессе пересылки этого заголовка через систему.
Туннельный режим SA определяет «внешний» IP-заголовок как тот, который за-
дает местоположение IPSec-обработки, а «внутренний» — как тот, что задает ко-
нечный пункт пакета. Заголовок протокола безопасности появляется после внеш-
него IP-заголовка, но перед внутренним IP-заголовком. Если АН используется в
туннельном режиме, то защищаются части внешнего IP-пакета, так же как и тун-
нелируемый IP-пакет (то есть весь внутренний IP-заголовок и протокол верхне-
го уровня). Если же используется ESP, то защищается только туннелируемый IP-
пакет, но не внешний заголовок.
Комбинирование ассоциаций
безопасности: более подробно
Датаграммы IP не защищаются обоими АН и ESP. Отдельные SA защищаются одним
или другим, но не обоими сразу. Однако возможно использование нескольких SA
для выполнения правил безопасности, и в IPSec определены два способа объеди-
нения SA в пакеты, называемые пакетами SA.
Первый способ называется транспортным объединением (transport adjacency). При
таком способе к одной IP-датаграмме применяется более чем один протокол
безопасности, без использования туннелирования. При этом комбинируются толь-
ко АН и ESP, то есть осуществляется один уровень вложения. Это возможно пото-
му, что в обоих АН и ESP используются мощные алгоритмы и использование
дополнительных средств не даст никаких преимуществ. При этом обработка у по-
лучателя производится только один раз — в конечном пункте.
Второй метод называется множественным туннелированием (iterated tunneling)
и означает использование нескольких протоколов безопасности в 1Р-туннелях.
Этот метод позволяет большой уровень вложенности. Каждый туннель может
начаться или закончиться в любом IPSec-сервере на пути от отправителя к полу-
чателю.
Существует также одна разновидность транспортного объединения и три — мно-
жественного туннелирования, показанные на рис. 8.8. На рис. 8.8, а показан ва-
риант с транспортным объединением с одним уровнем комбинирования SA.
Комбинирование ассоциаций безопасности: более подробно 151
Шлюз
Шлюз
а. Транспортное объединение
Шлюз
б. Множественное туннелирование, оба конца обеих SA совпадают
Шлюз Шлюз
е. Множественное туннелирование, один из концов обеих SA совпадает
г. Множественное туннелирование, ни один из концов обеих SA не совпадает
Рис. 8.8. Комбинирование ассоциаций безопасности
152 Глава 8. Архитектура IPSec
На рис. 8.8, б показан первый вариант множественного туннелирования, когда
оба конца используемых SA совпадают. Внутренний и внешний туннели могут
быть как АН, так и ESP, а также туннели могут совпадать (что маловероятно). На
рис. 8.8, в приведен другой вариант множественного туннелирования, в котором
один конец соединения совпадает для обоих туннелей. Внешний и внутренний
туннели могут быть или АН, или ESP. На рис. 8.8, г показан последний вариант
множественного туннелирования, когда ни один из концов SA не совпадает. Вне-
шний и внутренний туннели могут быть или АН, или ESP.
Местоположение IPSec
Как вы могли ожидать, конкретное местоположение IPSec в аппаратных средствах
или программном обеспечении не определено в требованиях спецификаций
Интернета, а только в рекомендациях. Имеется три наиболее вероятных сцена-
рия, показанных на рис. 8.9. Первым сценарием будет помещение кода IPSec прямо
в исходный код IP, написанный для хоста или шлюза безопасности. Этот подход
называется запихнуть-в-код (bump-in-the-code — BITC).
Второй сценарий — IPSec помещается в стек протоколов под IP, а это означает, что
он будет действовать поверх драйвера линии. Этот подход мог бы подойти хостам,
когда IPSec выполняется поверх управления доступа к носителю (media access
control — МАС). Этот подход называется запихнуть-в-стек (bump-ih-the-stack — BITS).
Рис. 8.9. Возможные местоположения IPSec: а — запихнуть-в-код (BITC),
б — запихнуть-в-стек (BITS), в — запихнуть-в-железо (BITW)
Селекторы и базы данных 5AD/SPD 153
Третьим сценарием является использование отдельного оборудования, которое
подсоединяется к хосту или шлюзу. Например, такое устройство могло бы быть
специальным процессором шифрации (например, таким, какой используется во-
енными), Этот подход называется запихнуть-в-железо (bump-in-the-wire — BITW).
К такого рода устройствам обычно обращаются по IP-адресу, и, если оно подсо-
единено к хосту, то для него оно выглядит как BITS. Если же оно используется
с маршрутизатором или брандмауэром, то оно будет выглядеть как шлюз без-
опасности и должно быть сконфигурировано как дополнение защитных функ-
ций брандмауэра.
Базы данных IPSec
В IPSec определено использование двух баз данных: базы данных правил безо-
пасности (Security Policy Database — SPD) и базы данных ассоциаций безопас-
ности (Security Association Database — SAD). Кроме того, там определено свя-
занное с базами данных понятие — селектор. Функции этих средств IPSec
перечисляются ниже:
О База данных правил безопасности: В этой базе данных хранятся правила IPSec,
которые задают то, какой поток данных обрабатывается (то есть, сопоставление
потока данных), и то, как этот поток данных обрабатывается (отвергнуть,
обойти IPSec, применить IPSec). Здесь задается то, как обрабатывать входящий
и исходящий потоки, и, таким образом, к этой базе данных обращаются для
каждого входящего и исходящего пакета. Определены три способа обработки
данных: 1) данные отвергаются, что означает, что данные никуда не идут и
это применяется как к входящим, так и исходящим данным; 2) обойти IPSec
— это означает что исходящие и входящие данные не защищаются при помощи
IPSec; 3) применить IPSec — значит, что входящие и исходящие данные должны
быть защищены IPSec.
О База данных ассоциаций безопасности: В SAD хранится информация о каждой
активной ассоциации безопасности. Поскольку SA являются однонаправлен-
ными, в SAD хранятся пары SA, по одной для каждого направления.
О Селектор: Набор полей IP и ULP, используемых SPD для отображения потоков
данных на правила безопасности (SA). Селекторами являются: IP-адрес от-
правителя; IP-адрес получателя; имя DNS или Х.500; идентификатор IP-про-
токола; номер порта отправителя; номер порта получателя.
Селекторы и базы данных SAD/SPD
Весь поток данных между двумя хостами может передаваться посредством од-
ного SA и обеспечивается одним набором служб безопасности. Кроме того, поток
данных между парой хостов мог бы быть разделен на множество SA, в зависимо-
154 Глава 8. Архитектура IPSec
сти от применяемого приложения (как определено в полях Следующий прото-
кол и Порт), когда разные SA обеспечивают различные службы безопасности.
Следующие параметры селектора должны поддерживаться в реализациях IPSec.
Заметьте, что и адреса отправителя и получателя могут быть в форматах IPv4 и
IPv6.
IP-адрес Получателя
Этот адрес может являться одним IP-адресом: однонаправленным, многонаправ-
ленным, широковещательным (только в IPv4) или групповым; может быть диа-
пазоном адресов (когда указываются значения наименьшего и наибольшего ад-
ресов включительно); адресом плюс маска или шаблоном адреса. Последние три
типа адреса предназначены для использования в случае нескольких получате-
лей, разделяющих одну и ту же SA (например, если все эти получатели находят-
ся за одним шлюзов безопасности).
Этот селектор принципиально отличается от поля IP-адрес Получателя в квали-
фикаторе <1Р-адрес Получателя, протокол IPSec, SPI>, используемом для однознач-
ной идентификации SA.
Когда передаваемый по туннелю пакет прибывает в конечный пункт, его значе-
ния полей SPI, Адрес Получателя и Протокол используются для поиска в SAD
соответствующего этому пакету SA. Адрес Получателя извлекается из вложенно-
го IP-заголовка.
После того как пакет был обработан в соответствии с SA его туннеля и оказался
вне этого туннеля, его селекторы ищутся во Входящей SPD. Во Входящей SPD
имеется селектор под названием Адрес Получателя. Это тот самый IP-адрес из
внутреннего (вложенного) ГР-заголовка.
IP-адрес Отправителя
Этот адрес может являться одним IP-адресом: однонаправленным, многонаправ-
ленным, широковещательным (только в IPv4) или групповым; может быть диа-
пазоном адресов (значения наименьшего и наибольшего адресов включительно);
адресом плюс маска или шаблоном адреса. Последние три типа адреса предназ-
начены для использования в случае нескольких отправителей, разделяющих одну
и ту же SА (например, если эти отправители находятся за одним шлюзом безо-
пасности или являются многоканальным узлом).
Имя
Это имя может принять форму полностью квалифицированного DNS-имени,
полного имени Х.500 или общего имени Х500.
Селекторы и базы данных SAD/SPD 155
Протокол транспортного уровня
Этот идентификатор извлекается из поля Протокол IPv4 или Следующий Заго-
ловок IPv6. Это значение может быть одиночным номером протокола.
Порты Отправителя и Получателя
Эти значения могут быть одиночными номерами порта TCP или UDP, а также шаб-
лонами.
Селекторы и записи в SAD/SPD
Конкретная реализация IPSec определяет то, как используются селекторы. На-
пример, реализация для хоста, с помещением IPSec в стек, может использовать
интерфейс сокета. Когда устанавливается новое соединение, то на основании
данных из SPD SA (или пакет SA) может быть связана с сокетом. Ткким образом,
данные, посланные через этот сокет, не будут нуждаться в дополнительных об-
ращениях к SAD/SPD.
В табл. 8.2 перечислены некоторые типы записей в SPD и SAD. Здесь показано,
как они связаны с полями в передаваемых данных, защищаемых при помощи IPSec.
(Заметьте, что термин «шаблон» для полей Адрес Отправителя и Адрес Получа-
теля включает в себя маску, диапазон и т. д.)
Таблица 8.2. Типичные записи в SAD и SPD
Поле Значение данных Запись a SAD Запись a SPD
Адрес Отправителя Одиночный IP-адрес Одиночный, диапазон, шаблон Одиночный, диапазон, шаблон
Адрес Получателя Одиночный IP-адрес Одиночный, диапазон, шаблон Одиночный, диапазон, шаблон
Протокол* Протокол Одиночный, шаблон Одиночный, шаблон
Порт Отправителя* Одиночный порт Отправителя Одиночный, шаблон Одиночный, шаблон
Порт Получателя* Одиночный порт Получателя Одиночный, шаблон Одиночный, шаблон
Идентификатор пользователя* Одиночный идентификатор пользователя Одиночный, шаблон Одиночный, шаблон
Метки безопасности Одиночное значение Одиночный, шаблон Одиночный, шаблон
*Для этих полей записи в SAD и SPD могут быть недоступны нэ-за того, что передаваемые данные
зашифрованы.
156 Глава 8. Архитектура IPSec
Поиск SA в SAD
Следующие поля пакета используются при поиске SA в SAD:
О IP-адрес Получателя из внешнего заголовка.
О Протокол IPSec: АН или ESP.
О Значение SPI используется в случае, когда различные SA заканчиваются в од-
ной точке и имеют один и тот же IPSec-протокол.
Для каждого из селекторов запись SA в SAD должна содержать одно или несколь-
ко значений, которые были согласованы в момент создания SA. Для отправителя
эти значения используются для того, чтобы определить — подходит ли данная
SA для использования с исходящим пакетом. Для получателя — чтобы проверить,
что значения селектора во входящем пакете соответствуют значениям в SA, и,
таким образом, неявно определить соответствие правилам безопасности.
Следующие поля SAD используются при обработке в IPSec:
О Номер счетчика последовательности: 32-битное значение, используемое для ге-
нерации значения поля с номером последовательности в заголовках АН и ESP.
О Переполнение счетчика последовательности: флаг, обозначающий, нужно ли при
переполнении счетчика последовательности генерировать ошибку и
предотвращать посылку последующих пакетов по данной SA.
О Окно защиты от повторов: 32-битный счетчик и битовая маска (или эквивалент),
используемые для определения того, что входящий пакет АН или ESP является
повторным.
О Алгоритм идентификации АН, ключи и т. д.
О Алгоритм шифрации ESP, ключи, вид вектора идентификации, сам вектор и т. д.
О Алгоритм идентификации ESP, ключи и т. д. Если идентификация не исполь-
зуется, то значение этого поля будет нулевым.
О Срок действия ассоциации безопасности: интервал времени, после которого
SA должна быть удалена или заменена новой SA (и новым SPI), плюс обозначе-
ние того, какое из этих действий (удаление или замена) должно иметь место.
О Режим протокола IPSec: туннель, транспорт или шаблон. Обозначает, какой из
режимов АН или ESP используется при передаче данных в данной SA. Заметьте,
что если это поле задано шаблоном у отправляющей стороны SA, то тогда
приложение должно задать этот режим реализации IPSec. Такое использование
шаблона позволяет применять (например, различными сокетами) к пакетам
одну и ту же SA как в транспортном, так и в туннельном режиме. Получателю
не нужно знать режим протокола для того, чтобы правильно обработать IP-
Sec-заголовки пакетов.
О MTU маршрута: MTU маршрута и устаревающие переменные.
Примеры посылки и получения данных в IPSec 157
Примеры посылки и получения
данных в IPSec
В этом разделе описываются процедуры, выполняемые при посылке и получе-
нии данных в IPSec. Точный набор операций варьируется в зависимости от реа-
лизации. Мы будем использовать модель IBM, с которой вы ознакомились ранее
[CHEN98],
На рис. 8.10 показаны основные действия, выполняемые при посылке данных в
IPSec. Данные извлекаются из буфера (обычно это TCP/UDP, OSPF, ICMP и т. п.) и
обрабатываются в соответствии с обычными правилами IP. Создается заголовок
IP, выполняется маршрутизация. Данные о маршрутизаций используются при при-
нятии решения о применении IPSec в данной датаграмме, основываясь на внеш-
нем канале связи или следующем узле, принимающем эти данные. Если прило-
жение пользователя не задало адрес блоку данных протокола, то таковой
назначается.
Отправка данных в IPSec
Отправляется:
РРР-фрейм,
элемент ATM,
фрейм Frame Relay
.Рис. 8.10. Обработка IPSec при отправке данных
158 Глава 8. Архитектура IPSec
Фильтрация исходящих данных не обязательна. Это зависит от реализации. В не-
. которых компаниях фильтрация исходящих данных применяется для защиты от
неумеренного использования ресурсов-и, разумеется, как материализация пра-
вил безопасности. Такая фильтрация приводит либо к отбрасыванию пакета, либо
к передаче датаграммы в модуль IPSec для соответствующих обработок.
Для уже готового блока данных протокола подсчитывается контрольная сумма,
после чего он помещается в выходную очередь для отправки. После этого берет- *
ся за дело уровень 2, помещает блок данных IPSec во фрейм L_2 и посылает его
по физическому каналу связи. После обработки IPSec, готовый пакет может под-
вергнуться разбиению на части, но обсуждение этого выходит за рамки данного
примера.
IPSec определяет обработку при отсылке следующим образом. В случае шлюза
безопасности или внешнего устройства (а также во многих реализациях с поме-
щением IPSec в стек) каждый отправляемый пакет сопоставляется с записями в
SPD для того, чтобы определить набор операций, применяемых к данному пакету.
Если этот пакет отвергается, то тогда возникает ошибка. Если данным разреша- ,
ется пройти обработку IPSec, то они проходят все необходимые операции. Если
необходима обработка IPSec, то пакету либо назначается существующая SA (или
пакет SA), либо создается новая SA (или пакет). Так как селекторы пакета могут
соответствовать множеству правил безопасности или множеству имеющихся SA
и поскольку SPD определен, a SAD — нет, то IPSec должен:
1. Искать в правилах безопасности для исходящих данных в SPD запись, со-
ответствующую полям селектора пакета'. Взять первый подходящий набор
правил, который будет указывать на ноль и больше пакетов SA в SAD.
2. Искать среди найденных в пункте 1 пакетов SA первый пакет SA, соответст-
вующий полям селектора пакета. .Если таковой не находится, то создать со-
ответствующий пакет SA и связать запись в SPD с записью в SAD. Если не найдено
ни одной записи управления ключами, то отвергнуть этот пакет.
3. Использовать пакет SA, найденный/созданный в пункте 2, для обработки IPSec,
например зашифровать или подписать данные.
В случае реализации IPSec, основанной на сокетах, SPD будет использоваться
каждый раз, когда будет создаваться новый сокет для того, чтобы определить то,
какая обработка IPSec будет применяться (если вообще будет) к данным, переда-
ваемым через этот сокет.
На рис. 8.11 показаны основные действия, выполняемые IPSec при получении
пакетов. Входящий пакет проверяется на соответствие контрольной сумме (ис-
пользуется значение из внешнего IP-заголовка) и форматируется в соответствии
с правилами протокола' Если эти проверки пройдены, пакет проходит входную
фильтрацию, которая является частью всей обработки IPSec и определяется пра-
вилами безопасности.
Если фильтр пропускает пакет к брандмауэру, то дальше он обрабатывается в
соответствии с обычными правилами IP (на рисунке это «Обработка 1Р>). До того
как выполняются процедуры АН или ESP, все части IP-пакета собираются вместе.
Примеры посылки и получения данных в IPSec 159
После чего проверяется значение поля Номер Протокола IP и определяется, ка-
кой режим преобразования пакета (АН или ESP) будет использоваться, после чего
такое преобразование выполняется. Кроме того, в процессе выполнения этих
действий выявляется идентификатор использованного туннеля безопасности, что
позволяет определить, каким образом был защищен данный пакет. Пакет снова
проходит проверку контрольной суммы, входную фильтрацию и т. д., но уже с
использованием дополнительной информации. В результате этих действий па-
кет может быть отвергнут. Во время выполнения этих повторных проверок иден-
тификатор туннеля уже известен и указывает способ, при помощи которого этот
пакет был защищен.
фрейм фрейм
Frame Relay Frame Relay
Рис. 8.11. Обработка IPSec при получении данных
160 Глава 8. Архитектура IPSec
Выбор и использование SA или пакета SA
В только что описанном процессе обработки входящих данных операция уста-
новления соответствия между IP-пакетом и SA была упрощена в силу наличия
SPI в заголовках АН или ESP. Обратите внимание на то, что проверки селектора
выполняются над внутренними заголовками, а не над внешними (туннельными).
В IPSec определены следующие шаги:
1. Использовать адрес получателя пакета (внешний IP-заголовок), протокол IPSec
и SPI для поиска SA в SAD. Если подходящая SA не найдена, то отвергнуть пакет
и зарегистрировать ошибку.
2. Использовать SA, найденную на шаге 1, для выполнения операций IPSec,
например проверки или дешифрации. На этом шаге выполняется сопоставление
селекторов пакета (из внутреннего заголовка при передаче по туннелю) с
селекторами SA. Локальные правила определяют специфику этих селекторов
SA (отдельное значение, список, диапазон, шаблон). В общем случае адрес
отправителя пакета должен соответствовать значению селектора SA. Однако
если пакет ICMP принимается в туннельном режиме SA, то он может иметь
адрес отправителя, отличный от того, что указан как соответствующий данной
SA, и таким образом должен быть пропущен в качестве исключения. В случае
пакета ICMP селекторы вложенного проблемного пакета (адреса отправителя
и получателя, а также порты должны быть переставлены местами) должны быть
проверены на соответствие селекторам SA. Заметьте, что некоторые или все из
этих селекторов могут быть недоступны из-за ограничений на количество бит,
разрешенных для передачи в этом проблемном пакете ICMP.
Шаги 1 и 2 повторяются для каждого заголовка IPSec до тех пор, пока не встре-
тится заголовок транспортного протокола или IP-заголовок, не принадлежащий
этой системе. Использование SA отслеживается, и порядок их применения запо-
минается.
3. Найти в SPD соответствующие пакету правила безопасности для входящих
данных. Это может быть осуществлено, например, при помощи обратных
указателей от SA на SPD или поиском в записях SPD правил безопасности,
соответствующих селекторам пакета (из внутреннего заголовка при передаче
по туннелю).
4. Проверить, были ли выполнены необходимые действия IPSec, то есть проверить,
что SA, найденные на шаге 1 и 2, соответствуют SA, требуемым правилами
безопасности, найденными на шаге 3. После выполнения этого процесса снова
(разные решения принимаются по отношению к разным заголовкам) вся
информация IPSec удаляется. Блок данных протокола больше не является
защищаемым пакетом, исходный заголовок IP говорит, что эта датаграмма имеет
пунктом назначения этот узел, поэтому данные помещаются в буфер для
дальнейшей обработки программой пользователя.
Заключение
161
включение
IPSec является основным протоколом Интернета для защищенной передачи дан-
ных через внешние сети или по незащищенным каналам. Работа ассоциаций бе-
зопасности осуществляется при помощи двух баз данных IPSec, базы данных
правил безопасности (Security Policy Database — SPD) и базы данных ассоциа-
ций безопасности (Security Association Database — SAD). Транспортный и тун-
нельный режимы IPSec могут быть установлены несколькими способами, обес-
печивая транспортное объединение (transport adjacency) и множественное
туннелирование (iterated tunneling).
ГЛАВА
IPSec: протоколы АН
и ESP
С протоколами IPSec АН и ESP вы познакомились в главе 8. В этой главе мы
продолжим это знакомство и обсудим эти протоколы более подробно. Офи-
циальной спецификацией протокола АН является RFC 2402, а протокола ESP —
RFC 2406. Далее вы найдете учебное пособие на основе этих RFC, а также ком-
ментарии автора.
Предназначение протоколов IPSec
Как мы узнали из главы 8, в IPSec определены два протокола обеспечения безо-
пасности, в табл. 9.1 приведен список их основных функций. Протокол Иденти-
фицирующий заголовок IP (Authentication Header — АН) обеспечивает: сохран-
ность (называемую в спецификации сохранностью, не зависящей от соединения,
— connectionless integrity), удостоверение происхождения данных, защиту от по-
вторений. Последнее не является обязательным и обеспечивается получателем в
том случае, когда определена ассоциация безопасности. АН может быть исполь-
зован как отдельно, так и совместно с ESP.
Протокол Вложенные защищенные передаваемые данные IP (IP Encapsulating
Security Payload — ESP) предоставляет: конфиденциальность (шифрацию), огра-
ниченную конфиденциальность потока данных, сохранность данных, не завися-
щую от соединения, удостоверение происхождения данных, защиту от повторе-
ний. В случае ESP по крайней мере одна из этих функций должна быть реализована.
Полный набор выполняемых действий определяется настройками ассоциации
безопасности. ESP может выполнять шифрацию отдельно от других операций, но
такое отделение от операций по обеспечению-сохранности данных и их иденти-
фикации может привести к атакам на передаваемые данные, что может дискре-
дитировать зашифрованную информацию.
Значение проверки сохранности (Integrity Check Value — ICV) 163
Таблица 9.1. Протоколы IPSec: АН и ESP
Два протокола определяют следующие типы:
• Обеспечение безопасности
• Методы форматирования
Идентифицирующий заголовок IP обеспечивает:
• Сохранность
• Идентификацию .
• Защиту от повтора
Вложенные защищенные передаваемые данные 1Р-обеспечивают:
• Конфиденциальность/секретность
• Сохранность
• Идентификацию
• Защиту от повтора
Не задают способы получения ключей, но предполагается, что ключи доступны
В ESP удостоверение происхождения данных и сохранность, независимая от со-
единения, являются связанными операциями и называются идентификацией. Они
предлагаются как необязательное дополнение к операциям шифрации. Защита
от повторения доступна только в случае, когда используется удостоверение про-
исхождения данных, и ее применение является прерогативой получателя. Кон-
фиденциальность потока данных обеспечивается только при использовании тун-
нельного режима.
Оба протокола являются средствами контроля доступа и могут применяться как
раздельно, так и вместе. Эти протоколы поддерживают IPv4 и IPv6.
В IPSec не устанавливается, как реализованы механизмы получения ключей (раз-
деляемых секретных значений), а вместо этого IPSec полагается на другой набор
спецификаций, которые и определяют операции с открытым ключом и автомати-
ческое управление ключами. Эти операции будут обсуждаться в главах 10 и 11.
Значение проверки сохранности
(Integrity Check Value — ICV)
Этот термин в IPSec используется для кода идентификации сообщения (Message
Authentication Code — MAC). IPSec требует реализации следующих процедур:
О MD5-HMAC-96
О HMAC-SHA-1-96
164 Глава 9. IPSec: протоколы АН и ESP
Взаимоотношения между протоколами АН и ESP
и транспортным и туннельным режимами
В табл. 9.2 показаны взаимоотношения транспортного и туннельного режимов
IPSec с операциями АН и ESP и заголовками. Структура таблицы очевидна, но
можно сделать пару замечаний о АН и ESP. Причина, по которой ESP имеет неко-
торые необязательные возможности, которые можно найти и в АН, проста — дать
администратору сети больше возможностей. Кроме того, применение обоих про-
токолов дает администратору больший выбор при поддержке ассоциаций безо-
пасности. Более подробно об этом вы прочитаете позже в этой главе.
Таблица 9.2. Взаимоотношения между режимами и протоколами IPSec
Транспортный Туннельный
АН Идентифицирует передаваемые данные и отдельные части IP-заголовка Идентифицирует весь внутренний IP-заголовок и передаваемые данные, а также отдельные части IP-заголовка
ESP Шифрует и идентифицирует данные, но не IP-заголовок (необязательно) Шифрует и идентифицирует (необязательно) передаваемые внутренний IP-заголовок и передаваемые данные
Управление изменяемыми полями
Если значение поля может быть изменено в процессе передачи, то при вычисле-
нии ICV это значение приравнивается к нулю. Есди поле меняется, но его значе-
ние у получателя может быть предсказано, тогда это значение присваивается с
тем, чтобы можно было посчитать ICV. Поле идентификации данных также уста-
навливается в ноль перед этими вычислениями.
Основные поля заголовка IPv4 классифицируются следующим образом:
О Постоянные
О Версия
О Длина заголовка Интернета
О Общая длина
О Идентификация
О Протокол (это значение для АН)
О Адрес отправителя
О Адрес получателя (без свободной или строгой маршрутизации отправителя)
О Изменяемые, но предсказуемые
О Адрес получателя (без свободной или строгой маршрутизации отправителя)
О Изменяемые (обнуляются перед вычислением ICV)
Значение проверки сохранности (Integrity Check Value — ICV) 165
О Тип сервиса (Type Of Service — TOS)
О Флаги
О Смещение фрагмента
О Время жизни (Time То Live — TTL)
О Контрольная сумма заголовка
О TOS: это поле исключается потому, что некоторые маршрутизаторы могут из-
менить значение этого поля, хотя по спецификации IP это поле и не считает-
ся изменяемым
О Флаги: это поле исключается потому, что промежуточный маршрутизатор мо-
жет установить бит DF, даже если отправитель этого не делал .
О Смещение фрагмента: так как АН может быть использован только в случае не-
фрагментированных пакетов, значение поля Смещение должно быть всегда
равно нулю и таким образом исключается, хотя это значение и предсказуемо
О TTL: это поле модифицируется по пути от отправителя к получателю как
результат нормальной рабрты маршрутизаторов и, таким образом, не может
быть предсказано отправителем
О Контрольная сумма заголовка: значение этого поля должно меняться, если ме-
няется значение хоть одного из полей заголовка, и, таким образом, эта конт-
рольная сумма не может быть предсказана отправителем
О Настройки: с этим полем связано множество правил, и все зависит от конк-
ретной настройки. За подробностями я рекомендую обратиться к приложе-
нию А в RFC 2402
Основные поля заголовка IPv6 классифицируются следующим образом:
О Постоянные
О Версия
О Длина передаваемых данных
О Следующий заголовок (это значение для АН)
О Адрес отправителя ;
О Адрес получателя (без маршрутизации заголовка расширения)
О Изменяемые, но предсказуемые
О Адрес получателя (с маршрутизацией заголовка расширения)
О Изменяемые (обнуляются перед вычислением ICV)
О Класс
О Метка потока
О Ограничение пересылок
166 Глава 9. IPSec: протоколы АН и ESP
Что защищается в пакетах АН и ESP
На рис. с 9.1 по 9.6 показана защищаемая информация в пакетах АН и ESP. Эти
рисунки будут использоваться далее в этой главе с тем, чтобы помочь в понима-
нии операций АН и ESP. Заметьте, что во всех этих рисунках стрелки указывают
на места, в которых осуществляется шифрация и идентификация (по отноше-
нию ко всем полям, за исключением изменяемых).
Защита АН
На рис. 9.1 показана защита пакета АН в транспортном режиме при использова-
нии IPv4. В этом режиме АН вставляется после IP-заголовка и перед протоколом
верхнего уровня (Upper-Llevel Protocol — ULP), например TCP, UDP, ICMP и т. д.,
или перед любым другим уже вставленным заголовком IPSec. В контексте IPv4
это означает, что АН помещается после заголовка IP (и любых содержащихся в
нем настроек), но перед протоколом верхнего уровня. Термин «транспортный ре-
жим» не должен быть истолкован так, что он ограничен использованием TCP или
UDP. Например, сообщения ICMP, OSPF, IGMP и др. могут быть посланы как в транс-
портном, так и туннельном режиме. Кроме того, термин «протокол верхнего уров-
ня» означает любой протокол, использующий IP-датаграмму. Такими протокола-
ми могут быть TCP, UDP, OSPF, ICMP и т. д.
Перед применением АН
IPv4
Исходный IP-заголовок (любые настройки) ULP Данные
После применения АН
Исходный IP-заголовок (любые настройки) АН ULP Данные
_______Идентифицирован________
за исключением изменяемых полей
Рис. 9.1. Защита АН в случае IPv4 в транспортном режиме
В случае использования IPv6 АН рассматривается как передаваемые данные и,
таким образом, должен появиться после заголовков пересылки, маршрутизации
и расширения фрагментации. Заголовок (заголовки) расширения с настройками
получателя могут появиться либо перед, либо после заголовка АН, в зависимости
от того, что нужно. На рис. 9.2 показан типичный пакет IPv6 с АН в транспортном
режиме.
На рис. 9.3 показана защита АН в случае IPv4 и IPv6 в туннельном режиме. Тун-
нельный режим АН может быть использован как хостами, так и шлюзами безо-
пасности (или в так называемых реализациях запихнуть-в-стек или запихнуть-
в-железо). Когда АН применяется в шлюзе безопасности (с целью защиты
транзитных данных), то должен использоваться туннельный режим. В этом ре-
Что и как делает АН
167
жиме «внутренний» IP-заголовок содержит адреса конечного отправителя и по-
лучателя, тогда как «внешний» IP-заголовок может содержать другие адреса,
например шлюзов безопасности. В туннельном режиме защищается весь внут-
ренний IP-пакет, включая весь внутренний IP-заголовок. Размещение АН в тун-
нельном режиме относительно внешнего IP-заголовка такое же, как и в случае
АН в транспортном режиме.
Перед применением АН
Исходный IP-заголовок (любые настройки) Дополнительные заголовки (если есть) ULP Данные
После применения АН
Исходный IP-заголовок Пересылка, маршрутизация к получателю, фрагмент * АН Нстройки получателя* ULP Данные
_______Идентифицирован
за исключением изменяемых полей
* Если присутствуют, то могут находиться как перед АН, так и после, или и там и там
Рис. 9.2. Защита АН в случае IPv6 в транспортном режиме
Новый IP-заголовок (любые настройки)* АН Исходный IP-заголовок (любые настройки)* ULP Данные
_________________Идентифицирован___________________
4 за исключением изменяемых полей в новом 1Р-заголовке
Новый IP-заголовоК* Дополнительные заголовки (если есть) АН Исходный IP-за головок* Дополнительные заголовки (если есть) ULP Данные
________________Идентифицирован________________
за исключением изменяемых полей в новом IP-заголовке
* создание внешнего заголовка/расширения IP и модифицирсаание
внутреннего загалоека/расимрения IP описывается в тексте
Рис. 9.3. Защита АН в случае IPv4 и IPv6 в туннельном режиме
Что и как делает АН
АН был опубликован в двух «вариантах». Первый определен в RFC 1826, и в этой
части главы мы коротко обсудим эту раннюю спецификацию; поскольку до сих
пор существуют реализации, на ней основанные?
168 Глава 9. IPSec: протоколы АН и ESP
RFC 1826
На рис. 9.4 показан формат заголовка АН. Поле Следующий Заголовок указыва-
ет на следующие передаваемые данные, идущие после данных идентификации.
Длина этих передаваемых данных — это длина поля данных идентификации в
32-битных словах. Поле Резервное предназначено для будущих реализаций.
0 1-6 7 8 .16 17 18-30 31
Следующий Заголовок Длина Резервное
Индекс параметров защиты
Данные идентификации (переменной длины)
Заметьте: цифры в верху рисунка обозначают битовые позиции полей
Рис. 9.4. Формат идентифицирующего заголовка (АН) в RFC 1826
Поле Индекс параметров защиты (Security Parameters Index — SPI) задает ассо-
циации безопасности данной датаграммы. Если значение поля равно нулю, то
это означает, что ассоциации безопасности не существует. Значения SPI от 1 до
255 зарезервированы Агентством пр выделению имен и уникальных параметров
протоколов Internet (Internet Assigned Numbers Authority — IANA).
Поле данных идентификации определяется ассоциацией безопасности данной
датаграммы. Адрес получателя и SPI могут быть использованы при поиске SA
этого пакета. Значения этого поля вычисляются при помощи алгоритма получе-
ния дайджеста сообщения, который должен быть надежной односторонней фун-
кцией.
RFC 2402
RFC 2402 является самой последней спецификацией АН, и в этой главе мы скон-
центрируемся именно на этой версии АН. На рис. 9.5 показан формат этого вари-
анта протокола. АН задается при помощи значения поля Идентификатор Прото-
кола, которое устанавливается равным 51. Все поля его заголовка включаются в
значение проверки сохранности (объясняется чуть позже). Эти поля предназна-
чены для выполнения следующих функций:
О Следующий Заголовок: задает тип передаваемых данных, следующих после
данных идентификации. Значение берется из списка протоколов IP, который
можно найти по адресу www.ietf.org (перейти по ссылке IANA).
О Длина передаваемых данных: задает длину АН.
О Резервное: зарезервировано для будущего использования.
Значение проверки сохранности (Integrity Check Value — ICV) для исходящих пакетов 169
О Индекс параметров защиты (SPI): значение этого поля, в комбинации с IP-адресом
получателя и протоколом безопасности (АН), однозначно задает ассоциации
безопасности для данной датаграммы. SPI обычно выбирается получающим
узлом в процессе определения SA.
О Последовательный Номер: это поле всегда присутствует, даже если получатель
не собирается воспользоваться защитой от повторения в конкретном SA. Если
же такая защита применяется (по умолчанию это так), передаваемый по-
следовательный номер не'может повторяться. Следовательно, счетчики полу-
чателя и отправителя сбрасываются (путем установления новой SA и, таким
образом, нового ключа) до того, как будет передано 232 пакета с применением
данной SA.
О Данные идентификации: содержит значение проверки сохранности (ICV), которое
описывается в следующем разделе.
0 1-6 7 6 о 16 17 18-30 31
Следующий Заголовок Длина передаваемых данных Резервное
Индекс параметров защиты
Поле последовательного номера
Данные идентификации (переменной длины)
Рис. 9.5. Формат идентифицирующего заголовка (АН) в RFC 2402
Значение проверки сохранности (Integrity
Check Value — ICV) для исходящих пакетов
ICV в АН вычисляются на основе:
О полей IP-заголовка, которые либо неизменны, либо их значения можно предска-
зать по получении;
О заголовка АН (а также возможных заполняющих битов);
О всех заголовков и данных верхнего уровня.
Если применяется фрагментация, то соответствующие значения вычисляются
после AH-обработки. Таким образом, транспортный режим АН применяется толь-
ко в случае целых датаграмм, а не их фрагментов. IP-пакет, к которому был при-
менен АН, может быть фрагментирован маршрутизаторами на пути от отправи-
теля к получателю, но такие фрагменты должны быть собраны в целое до
обработки АН у получателя. В туннельном режиме АН применяется к IP-пакету,
блоком данных которого может быть фрагмент другого IP-пакета. Например,
шлюзы безопасности (а также IPSec в варианта^ запихнуть-в-стек и запихнуть-
в-железо) могут использовать туннельный режим АН для таких фрагментов.
170 Глава 9. IPSec: протоколы АН и ESP
Значение проверки сохранности (Integrity
Check Value — ICV) для входящих пакетов
Если пакет фрагментируется, то сборка такого пакета должна иметь место до
обработки АН. Соответствующая SA определяется при помощи IP-адреса получа-
теля, номера протокола (АН) и SPI. Если подходящая SA не найдена, то такой пакет
должен быть отвергнут. Поле Номер Последовательности применяется в защите
от повторений пакетов, что требуется в АН. Однако если получатель не осуще-
ствляет такую защиту, то тогда значение поля Последовательный Номер игно-
рируется.
Получающий узел вычисляет ICV на основе соответствующих полей пакета и
сравнивает результат со значением, переданным в поле Данные Идентификации.
Если они совпадают, датаграмма пропускается. Алгоритм этой операции может
варьироваться, но, как вы наверняка припоминаете, любая реализация АН долж-
на поддерживать либо НМАС с MD5, либо НМАС с SHA-1.
Что и как делает ESP
Уже знакомый вам протокол «Вложенные защищенные передаваемые данные 1Р»
(IP Encapsulating Security Payload — ESP) является механизмом обеспечения со-
хранности и конфиденциальности датаграмм IP. Кроме того, ESP может быть ис-
пользован для удостоверения происхождения данных, в зависимости от исполь-
зуемых алгоритмов. Безотказность работы и защита анализом данных не
предусмотрены в ESP. Так же как и в АН, удостоверение происхождения данных и
их сохранности совмещены и называются идентификацией. Конфиденциальность
потока данных требует выбора туннельного режима.
Передаваемые данные ESP появляются после IP-заголовка, но перед протоколом
транспортного уровня. Протоколу ESP IANA назначила номер 50. ESP состоит из
незашифрованного заголовка, за которым следуют зашифрованные данные. Эти
данные состоят из защищенных полей заголовка ESP и данных пользователя,
которыми могут быть вся датаграмма IP, включая заголовки верхнего уровня и
собственно данные пользователя.
Защита ESP
Так же как и АН, ESP может быть использован в двух режимах: транспортном и
туннельном. В первом случае ESP подходит только хостам и обеспечивает защи-
ту протоколов верхнего уровня, но не IP-заголовка. (В этом режиме, в случае
вариантов запихнуть-в-стек и запихнуть-в-железо, входящие и исходящие IP-фраг-
менты могут потребовать такую реализацию IPSec, которая выполняла бы допол-
нительную сборку/фрагментацию для того, чтобы соответствовать этой специ-
фикации и обеспечить прозрачную поддержку IPSec.) На рис. 9.6 показано, что
защищает ESP в транспортном режиме. ESP помещается после IP-заголовка и пе-
Что и как делает ESP
171
ред протоколами верхнего уровня, такими как TCP, UDP, ICMP и др., или перед любым
другим уже вставленным заголовком IPSec. В контексте IPv4 это означает поме-
щение ESP после IP-заголовка (и любых содержащихся в нем настроек), но перед
протоколом верхнего уровня. «Концевик ESP» содержит все заполняющие биты,
их длину и поля следующего заголовка.
Перед применением ESP
Исходный 1Р-заголоедк (любые настройки) ULP Данные
IPv4
После применения ESP
Ipv4 Исходный IP-заголовок (любые настройки) Заголовок ESP ULP Данные Концевик ESP Идентификация ESP
г Зашифровано
Идентифицировано
Рис. 9.6. Защита ESP в случае IPv4 в транспортном режиме
На рис. 9.7 показана защита ESP в транспортном режиме в случае IPv6. ESP рас-
сматривается как полезная нагрузка, доставляемая из конца в конец, и, таким
образом, должна появиться после данных о пересылках, маршрутизации и заго-
ловков расширения фрагментации. Заголовок (заголовки) расширения настроек
получателя могут появиться как до, так и после заголовка ESP, в зависимости от
необходимости. Однако в силу того, что ESP защищает только поля после заго-
ловка ESP, то в общем случае это может быть желательным — поместить заголов-
ки настроек получателя после заголовка ESP.
Перед применением ESP
Исходный IP-заголовок (любые настройки) Дополнительные заголовки (если есть) ULP Данные
После применения ESP
Исходный IP-заголовок (любые настройки) Пересылка, маршрутизация к получателю, фрагмент* ESP Настройки получателя ULP Данные Концевик ESP Иденти- фикация ESP
Зашифровано
Идентифицировано
• Если присутствуют, то могут находиться как перед ESP, так и после, или и там и там
Рис. 9.7. Защита АН в случае IPv6 в транспортном режиме
Защищаемые данные в случае туннельного режима ESP показаны на рис. 9.8.
Туннельный режим может быть использован как хостами, так и шлюзами безо-
пасности. Когда ESP применяется в реализации для шлюза безопасности (с це-
лью защиты транзитного трафика пользователя), то должен использоваться тун-
172 Глава 9. IPSec: протоколы АН и ESP
нельный режим. В туннельном режиме «внутренний» IP-заголовок содержит
адреса конечного получателя и отправителя, тогда как «внешний» IP-заголовок
может содержать другие IP-адреса, например адреса шлюзов безопасности.
В туннельном режиме ESP защищает весь внутренний IP-пакет, включая весь внут-
ренний IP-заголовок. Позиция ESP в туннельном режиме относительно внешнего
IP-заголовка такая же, как и в случае ESP в транспортном режиме.
IPv4
Новый IP-заголовок (любые настройки)* ESP Исходный IP-заголовок (любые настройки)* ULP Данные Концевик ESP Идентификация ESP
Зашифровано
Идентифицировано
IP-заголовок (любые настройки)* Новые дополни- тельные заголовки ESP Исходный IP-заголовок* Исходные дополни- тельные заголовки ULP Данные Концевик ESP Иденти- фикация ESP
Зашифровано
Идентифицировано
* если присутствуют, то создание внешнего заголовка/расширения IP и модифицирование
внутреннего заголовка/расширения IP описывается в тексте
Рис. 9.8. Защита ESP в случае IPv4 и IPv6 в туннельном режиме
ESP был опубликован в двух «версиях». Первая была описана в RFC 1827, и в
этой части главы мы обсудим эту раннюю спецификацию.
RFC 1827
На рис. 9.9 приведен формат заголовка ESP в соответствии с RFC 1827. Он состо-
ит из поля SPI и непрозрачных данных. Поле SPI определяет соответствующую
датаграмме ассоциацию безопасности, а если установлена в ноль, то это означа-
ет, что ассоциация безопасности не использовалась.
0 1-30 31
Индекс параметров защиты
Непрозрачные данные (переменной длины)
Заметьте: цифры в верху рисунка обозначают битовые позиции полей
Рис. 9.9. Формат идентифицирующего заголовка (АН) в RFC 1827
Что и как делает ESP
173
Поле Непрозрачные Данные и конкретные алгоритмы шифрации и идентифика-
ции называются «преобразованиями». ESP не определяет эти преобразования —
они задаются в других спецификациях. Читателю можно рекомендовать одну из
таких — [KARN95J*.
RFC 2406
RFC 2406 — это самая последняя спецификация ESP, и в этой главе мы сконцен-
трируем свое внимание именно на этой версии. На рис. 9.10 показан формат за-
головка ESP. Номер протокола ESP — 50. Все поля заголовка должны присутство-
вать и включаются в значение проверки сохранности (описываемом чуть ниже).
Эти поля выполняют следующие функции:
О Индекс параметров безопасности: значение этого поля, в комбинации с IP-адресом
получателя и номером протокола (ESP), однозначно определяют ассоциацию
безопасности данной датаграммы. SPI обычно выбирается получающим узлом
в процессе определения SA. < , • > .
О Последовательный Номер: это поле всегда присутствует, даже если получатель
не собирается воспользоваться защитой от повторения в конкретном SA. Если
же такая защита применяется (по умолчанию это так), передаваемый по-
следовательный номер не может повторяться. Следовательно, счетчики полу-
чателя и отправителя сбрасываются (Путем установления новой SA и, таким
образом, нового ключа) до того, как будет передано 232 пакетов с применением
данной SA.
О Передаваемые данные: содержит зашифрованные данные.
О Заполнение: служит для обеспечения требования о длине открытого текста.
Количество заполняющих байтов зависит от реализации.
О Длина заполнения: задает количество дополняющих байтов
о _______________________________________1-30__________________________________|31
____________________________________Индекс параметров безопасности____
_____________________________________________________________________Последовательный Номер_
Передаваемые данные (переменной длины)
__________________________________________Дополнение (0-255 байт)_________________
Дополнение (продолжение)
Дополнение (продолжение) Длина дополнения | Следующий заголовок
Данные идентификации (переменной длины)
Рис. 9.10. Заголовок ESP в соответствии с RFC 2406
1 [KARN95], Karn, Р., Metzger, Р., Simpson, W. The ESP DES-CBC Transform, RFC 1829.
174 Глава 9. IPSec: протоколы АН и ESP
О Следующий заголовок: определяет тип данных, находящихся в поле
Передаваемые данные.
О Данные идентификации: содержит значение проверки сохранности (ICV) для
данного пакета ESP. IPSec требует использования DES в режиме СВС.
Обработка исходящих пакетов
Отправитель при шифрации пакетов производит следующие действия:
О Помещает в поле Передаваемые данные ESP исходную информацию протоко-
ла верхнего уровня, если находится в транспортном режиме, или всю исход-
ную датаграмму IP, если находится в туннельном режиме.
О Дополняет до нужной длины, если необходимо.
О Шифрует результат (данные, дополняющие биты, длину дополнения и сле-
дующий заголовок) с использованием ключа, алгоритма шифрации и режима
алгоритма, заданного в SA.
Если выбрана идентификация, то сначала выполняется шифрация, которая не
выполняется над полем с данными идентификации.
Если идентификация задана в SA, то отправитель подсчитывает ICV для всего
пакета ESP, минус данные идентификации. Таким образом, SPI, последовательный
номер, передаваемые данные, дополняющие биты (если есть), длина дополнения
и следующий заголовок — все они учитываются при вычислении ICV. Последние
четыре пользователя будут в зашифрованном виде, поскольку шифрация выпол-
няется перед идентификацией.
Обработка входящих пакетов
Если необходимо, то повторная сборка выполняется перед обработкой ESP. Если
пакет, пришедший на обработку ESP, является фрагментом, то есть поле смеще-
ния фрагмента не равно нулю или установлен флаг, указывающий, что должны
прийти еще фрагменты, то тогда получатель должен отвергнуть такой пакет и
сообщить об ошибке. Запись об этом должна содержать значение SPI, дату и вре-
мя получения, адрес отправителя, адрес получателя, последовательный номер и
(в случае IPv6) идентификатор потока.
Поиск ассоциации безопасности. По получении (собранного) пакета, содержа-
щего заголовок ESP, получатель определяет соответствующую (двунаправленную)
SA, основываясь на адресе получателя, номере протокола безопасности (ESP) и
SPI. В SA указывается, должно ли быть проверено поле с последовательным но-
мером, должно ли присутствовать поле идентификации и какой алгоритм и клю-
чи используются при дешифрации и вычислении ICV (если такая обработка за-
дана).
Проверка последовательного номера. Все реализации ESP должны обеспечивать
защиту от повторений, даже хотя такая защита может, в зависимости от настро-
ек в SA, и не использоваться получателем.
АН и ESP и «случаи» 175
{ Проверка значения проверки сохранности (ICV). Если в SA требуется использо-
вание идентификации, то получатель вычисляет ICV для пакета ESP (за исключе-
нием поля с данными идентификации) с применением указанного алгоритма
идентификации и удостоверяется, что полученное значение совпадает с тем, что
находится в поле идентификации данного пакета. Описание выполняемых вы-
числений приводится далее.
Если вновь вычисленное и переданное ICV совпадают, то проверка для данной
датаграммы считается пройденной. Если же они не совпадают, то тогда получа-
тель должен отвергнуть этот IP-пакет и сообщить об ошибке.
Дешифровка пакета. Получающий узел IPSec выполняет следующие действия:
О Дешифрует поля с блоком данных, дополняющими битами, длиной дополне-
ния и следующим заголовком с использованием ключа, алгоритма дешифра-
ции, режима алгоритма и данными криптографической синхронизации (если
есть), заданными в SA.
О Обрабатывает все дополняющие биты, как указано в спецификации алгорит-
ма дешифрации.
О Восстанавливает исходную датаграмму IP:
• Транспортный режим. Из исходного IP-заголовка и информации исходного
протокола верхнего уровня, находящегося в поле передаваемых данных ESP.
• Туннельный режим. Из IP-заголовка и всей датаграммы IP, находящейся в поле
передаваемых данных ESP.
АН и ESP и «случаи»
В главе 8 обсуждались четыре случая IPSec. Сейчас мы вернемся к этим случаям
и расширим это обсуждение путем добавления описания типов форматирования,
используемых в каждом из этих случаев. Как вы наверняка помните, четыре
комбинации ассоциаций безопасности и соответствующих им туннелей и фор-
матов должны поддерживаться в IPSec-совместимой реализации.
На рис. с 9.11 по 9.14 значок туннеля обозначает одну или более ассоциаций без-
опасности, а пунктирная линия — узлы IPSec, участвующие в передаче, а также
логический поток данных IPSec. Сплошная линия представляет физический по-
ток данных. Для простоты концевик ESP и поле МАС (за ULP) не приводятся в
этих примерах.
Случай 1 показан на рис. 9.11. Он разрешает использование между хостами как
транспортного, так и туннельного режимов. Могут быть применены пять вари-
антов форматирования, как показано в рамке внизу рисунка. Заметьте, что при
версии 3 оба АН и ESP могут быть применены к данным. Если это имеет место, то
ESP должен быть первым, а АН — вторым.
176 Глава 9. IPSec: протоколы АН и ESP
Хост 2
Случай 1;
Хост 1
Туннель
АН | IP1
Форматирование:
IP2
IP2 ESP
ULP
IP1 ULP
Рис. 9.11. Случай 1 и варианты форматирования
Случай 2, приведенный на рис. 9.12, используется только в туннельном режиме,
а методы форматирования показаны в рамке, внизу рисунка. В IPSec этот вари-
ант предназначен для обеспечения поддержки виртуальных частных сетей. За-
метьте, что в случае 2 может использоваться только туннельный режим.
Случай,2:
Шлюз
Шлюз
Форматирование
Туннель________
4. IP2 I АН I IP1 I ULP
IP2 ESP IP1 ULP
Рис. 9.12. Случай 2 и варианты форматирования
Случай 3, показанный на рис. 9.13, является комбинацией случаев 1 и 2. Здесь
добавляется сквозная защита данных, от отправителя к получателю. В этом ва-
рианте не возникает никаких дополнительных требований к хостам или шлюзам
безопасности, так что мы не будем уделять ему особое внимание.
Как уже обсуждалось ранее, случай 4 относится к ситуации, когда удаленный
хост соединяется через коммутируемые линии и Интернет со своей организаци-
АН и ESP и «случаи» 177
ей (рис. 9.14). Мы уже приводили примеры использования такого варианта —
например, пользователи сотовых телефонов, находящиеся в командировках люди
и т. д. Как следует из текста в рамке внизу рисунка, между хостом и шлюзом
безопасности может использоваться только туннельный режим, в соответствии
с правилами случая 2. Между двумя хостами может быть использован и туннель-
ный, и транспортный режимы, в соответствии с правилами случая 1.
Случай 3:
Рис. 9.13. Случай 3 и варианты форматирования
Форматирование:
H1-SG2: Н1-Н2:
Шлюз безопасности 2: Туннель или
Туннель Транспорт
(как в случае 2) _ (как в случае 1)
Рис. 9.14. Случай 4 и варианты форматирования
178 Глава 9. IPSec: протоколы АН и ESP
IP-адресация в заголовках
Давайте взглянем на пакеты IPSec с точки зрения адресации. Пакеты IPSec коди-
руются более чем одним образом, и мы сейчас знаем, что это кодирование зави-
сит от применяемого протокола безопасности, который, в свою очередь, зависит
от настроек SA.
Туннельный режим используется в том случае, когда существует туннель между
двумя брандмауэрами (рис. 9.15) или между брандмауэром и удаленной систе-
мой (сервером, например).
Пользователь А
Пользователь Б
IP IP TCP/UDP Данные
V*V-----------
«Адреса: А и Б
'Адреса: В и Г
Или:
Пользователь А
TCP/UDP
Данные
Пакет IPSec
(защищенные данные)
IP IP
X1 Ч1
«Адреса: А и Удаленная система
'Адреса: Аи В
Рис. 9.15. Адресация в туннельном режиме
IP-адреса отправителя и получателя в IP-заголовке могут быть, а могут и не быть
теми же самыми, что и в исходной датаграмме IP. Например, адреса пользовате-
лей А и Б могут находиться в защищенном IP-заголовке, тогда как IP-адреса бранд-
мауэров В и Г могут быть в другом IP-заголовке. Конкретное использование ад-
ресов зависит от того, где начинается и где заканчивается туннель.
Адресация в транспортном режиме показана на рис. 9.16. Транспортный режим
используется тогда, когда конечными точкам^ туннеля безопасности являются
конечные пользователи соединения.
Создание пакета ESP
179
Пользователь А Пользователь Б
\ Пакет IPSec \
\(защищенные данные) \
IP ’ TCP/UDP Данные
'Адреса: А и Б
Рис. 9.16. Адресация в транспортном режиме
Создание пакета ESP
На рис. 9.17 дано другое представление пакета ESP. Он создается у отправителя
следующим образом. Первое — генерируется заголовок ESP. Затем к нему добав-
ляются пользовательские данные (полезная нагрузка). После этого создается кон-
цевик ESP и добавляется к данным. В этом концевике находится номер протоко-
ла внедренного пакета (такой как TCP или UDP), или, если используется туннельный
режим, это значение будет содержать номер IP-B-IP (4). Кроме того, концевик
ESP содержит блок шифра, использованного для шифрации (такой как DES) и,
если необходимо, байты, дополняющие блок данных до необходимой длины. Затем
блок данных и концевик ESP шифруются, образуя тем самым зашифрованную
часть пакета. Если нужна проверка сохранности, то МАС вычисляется на основе
заголовка и зашифрованной части, а результат помещается в конец пакета. И, на-
конец, все это добавляется к заголовку IP.
Процедура создания пакета АН сходна с только что описанной, смотрите рис. 9.18.
Но, как вы помните, АН используется для обеспечения идентификации, а значит,
при создании пакета АН не применяется шиффация. Первое — отправитель со-
здает заголовок протокола АН, который (как и в ESP) содержит последователь-
ный номер, SA IPSec, SPI, а также номер протокола для идентификации встроен-
180 Глава 9. IPSec: протоколы АН и ESP
ных данных. Здесь же будет находиться значение МАС (вычисляемое позже). На
‘ следующем этапе встраиваемый пакет просто добавляется к этому заголовку АН.
Затем перед ним помещается IP-заголовок. Последней операцией является вы- '
числение кода идентификации сообщения МАС для всего пакета, включая 1Р-за-
гловок, заголовок АН и передаваемые данные.
Вычисление кода идентификации сообщения
IP-заголовок Заголовок АН, МАС Блокданных
Пакет АН
Рис. 9.18. Формирование пакета АН
И, наконец, на рис. 9.19 приведен еще один метод форматирования. Я привожу
цитату прямо из [CHEN98], страница 51:
Хотя ESP может обеспечить как конфиденциальность, так и сохранность, АН, тем не менее,
нужен по следующим соображениям:
1. Если шифрация не нужна или запрещена законом, АН может предоставить защиту сохран-
ности данных без затрат на шифрацию.
2. Защита сохранности данных: АН относится и к части IP-заголовка, тогда как в ESP — нет.
То, нужна ли вам такая дополнительная защита, зависит от требований правил безопас-
ности. (Например, в военных приложениях может быть необходима защита наиболее чув-
ствительных полей в настройках IP-заголовка). Если нужна и шифрация, и защита
IP-заголовка, то IPSec SA может быть использован, результат чего и приведен на рис. 9.19.
Здесь показан пакет ESP, встроенный в пакет АН, а пакет АН, в свою очередь, помещен в
IP-пакет. В таком варианте предполагается, что пакет ESP создается первым. Лоле Пос-
ледовательный Номер в заголовке АН предоставляет защиту от повторения на ранних
стадиях обработки, без необходимости выполнения дешифрации.
Вычисление кода идентификации сообщения ----------►
-------- Идентифицировано ------------------------►
IP-заголовок Заголовок АН Заголовок ESP Блокданных Концевик ESP
। -<--- Зашифровано -----►
-4------------- Пакет ESP -------------►
------- Пакет АН ----------------------►
Рис. 9.19. Формирование пакета АН и ESP
Создание заголовка для туннельного режима 181
Создание заголовка для туннельного
режима
IPSec описывает обработку внутреннего и внешнего заголовков, заголовков рас-
ширений и настроек туннелей АН и ESP. Сюда входит создание внешнего
IP-заголовка, обработка полей внутреннего IP-заголовка, и другие необходимые
действия. Основная идея взята из описания в RFC 2003, «Встраивание IP с по-
мощью IP» (IP Encapsulation with IP):
О Поля внешнего IP-заголовка Адрес Отправителя и Адрес Получателя задают
конечные точки туннеля (формирователя и расформирователя). Поля внут-
реннего IP-заголовка Адрес Отправителя и Адрес Получателя задают, соот-
ветственно, начального отправителя и конечного получателя датаграммы
(с точки зрения этого туннеля).
О Внутренний IP-заголовок не модифицируется, за исключением поля TTL, и ос-
тается неизменным до точки выхода из туннеля.
О Не производится никаких изменений в настройках IP и заголовках расшире-
ний внутреннего заголовка в процессе доставки встроенной датаграммы че-
рез туннель.
О Если необходимо, то заголовки других протоколов, таких как Идентифици-
рующий заголовок IP, могут быть помещены между внешним и внутренним
заголовками IP.
Следующие таблицы показывают, как происходит обработка различных полей
заголовков/настроек. Термин «создан» означает, что значение в поле внешнего
заголовка создается независимо от значения соответствующего поля во внутрен-
нем заголовке.
В табл. 9.3 приведено создание заголовка IPv4 для туннельного режима. Приме-
чания к таблице сделаны в следующем за ней примечании.
Таблица 9.3. Создание заголовка IPv4 для туннельного режима
<— Как внешний заголовок соотносится с внутренним —>
IPv4 Поля заголовка Внешний заголовок у формирователя Внутренний заголовок у расформирователя
Версия 4(1) Не изменяется
Длина заголовка Создано Не изменяется
TOS Скопировано из внутреннего заголовка (5) Не изменяется
Общая длина Создано Не изменяется
Идентификатор Создано Не изменяется
Флаги (DF. MF) Создано, DF (4) Не изменяется
Смещение фрагмента Создано Не изменяется
TTL Создано (2) Уменьшается (2)
Протокол АН, ESP, заголовок маршрутизации Не изменяется
Контрольная сумма Создано Создано (2)
Адрес отправителя Создано (3) ». Не изменяется
Адрес получателя Создано (3) Не изменяется
Настройки Никогда не копируется Не изменяется
182 Глава 9. IPSec: протоколы АН и ESP
В табл. 9.4 приведено создание заголовка IPv6 для туннельного режима. Приме-
чания к таблице сделаны в следующем за ней примечании.
Таблица 9.4. Создание заголовка IPv6 для туннельного режима
<— Как внешний заголовок соотносится с внутренним —>
IPv6 Поля заголовка Внешний заголовок у формирователя Внутренний заголовок у расформировать
Версия 6(1). Не изменяется
Класс Скопировано или сконфигурировано (6) Не изменяется
Идентификатор потока Скопировано или сконфигурировано Не изменяется
Длина Создано Не изменяется
Следующий заголовок АН, ESP, заголовок маршрутизации Не изменяется
Ограничение пересылок Создано (2) Уменьшается (2)
Адрес отправителя Создано (3) Не изменяется
Адрес получателя Создано (3) Не изменяется
Заголовки расширений Никогда не копируется Не изменяется
Примечания к таблицам 9.3 и 9.4
1. Версия IP вложенного заголовка может отличаться от версии внешнего.
2. TTL во внутреннем заголовке уменьшается формирователем перед отправкой пакета и
расформирователем, если ои пересылает пакет дальше. (Контрольная сумма пересчитывается, если TTL
изменено.)
3. Адреса отправителя и получателя зависят от той SA, которая используется для определения адреса по-
лучателя, который, в свою очередь, определяет, какой адрес отправителя (интерфейс сети) использует-
ся при пересылке пакета дальше. В принципе, адрес отправителя из внешнего заголовка может быть
адресом любого из интерфейсов формирователя или даже отличным от его любого IP-адреса, напри-
мер когда он действует как транслятор сетевых адресов, так как этот адрес можно получить через фор-
мирователь из окружения, в которое этот пакет был послан. Это не будет проблемой, поскольку в IPSec
в настоящее время не производится никакой обработки входящих пакетов, использующей адрес отпра-
вителя из внешнего заголовка. Таким образом, получающая сторона туннеля использует адрес получа-
теля внешнего заголовка и адрес отправителя из внутреннего.
4. Настройка определяет, копируются ли флаги из внутреннего заголовка (только IPv4) и устанавливается
или сбрасывается флаг DF.
5. Если внутренний заголовок является IPv4 (Протокол » 4), тогда 70S копируется, если внутренний заго-
ловок — IPv6 (Протокол - 41), то класс отображается на TOS.
6. Если внутренний заголовок является IPv6 (Протокол - 41), тогда класс копируется, если внутренний
заголовок — IPv4 (Протокол 4), то 70S отображается на класс.
Применение НМАС в АН и ESP
Из-за эффективности НМАС (смотрите главу 5, «НМАС»; вы должны ознако-
миться с этой главой до того, как приступать к этому разделу), он был подготов-
лен для использования с АН и ESP. НМАС применяется в двух хэш-функциях,
Применение НМАС в АН и ESP 183
MD5 и SHA-1. В этой части главы мы сфокусируемся на том, как НМАС исполь-
зуется в следующих контекстах: НМАС и MD5 в ESP и АН (RFC 2403); и НМАС
и SHA-1 в ESP и АН (RFC 2402). В этом разделе даются основные понятия этих
RFC.
Повторяя уже сказанное: эти две операции разработаны для удостоверения того,
что полученный пакет действительно отправлен из ожидаемого места и что по-
лученный пакет не был изменен по пути.
Для алгоритмов MD5 и SHA-1 следующее верно: НМАС — это алгоритм иден-
тификации с секретным ключом. Удостоверение происхождения данных и их
сохранности, обеспечиваемое НМАС, зависит от способа распространения секрет-
ного ключа. Если ключ НМАС известен только отправителю и получателю, то этот
алгоритм обеспечивает идентификацию пакетов, посланных между этими двумя
сторонами. Если переданная и вычисленная величины НМАС совпадают, то это
доказывает, что именно эти данные были посланы отправителем.
MD5-HMAC-96
Алгоритм MD5-HMAC-96 выполняется на 64-битных блоках данных. Операция
дополнения до нужного размера описана в RFC 1321 и является частью алгорит-
ма MD5. MD5-HMAC-96 дает в результате 128-битное значение. В ESP или АН
используются только первые 96 бит. При отправке пакета это усеченное значе-
ние помещается в поле идентификации. По получении опять вычисляется пол-
ное 128-битное значение, первые 96 бит которого сравниваются с переданным
значением. В алгоритме MD5-HMAC-96 не поддерживаются МАС другой длины.
В RFC 2403 не задается фиксированная длина ключа. Тем не менее, для того чтобы
использовать MD5-HMAC-96 с АН или ESP, должна быть обеспечена поддержка
128-битной длины ключа. Другие длины ключа не разрешены. Длина в 128 бит
была выбрана на основе RFC 2104, где говорится, что ключи с длиной, меньшей,
чем у результата алгоритма МАС, уменьшают надежность защиты, а большей дли-
ны — увеличивают ее незначительно.
HMAC-SHA-1-96
Алгоритм HMAC-SHA-1-96 выполняется на 64-битных блоках данных. Опера-
ция дополнения до нужного размера описана в FIPS-180-1 и является частью
алгоритма SHA-1. В результате выполнения HMAC-SHA-1-96 выдается 160-бит-
ное значение. Это значение может быть уменьшено, как описано в RFC 2104. В ESP
или АН используются только первые 96 бит. При отправке пакета это усеченное
значение помещается в поле идентификации. По получении опять вычисляется
полное 160-битное значение, первые 96 бит которого сравниваются с передан-
ным значением. В алгоритме MD5-HMAC-96 не поддерживаются МАС другой
длины.
Как упоминалось ранее, в RFC 2104 не задается-фиксированная длина ключа, но
для того чтобы использовать MD5-HMAC-96 с АН или ESP, должна быть обеспе-
184 Глава 9. IPSec: протоколы АН и ESP
чена поддержка 160-битной длины ключа. Другие длины ключа не разрешены.
. Длина в 160 бит была выбрана на основе рекомендаций RFC 2104.
IPSec и NAT
Трансляция сетевых адресов (Network Addresses Translation — NAT) — это широко
распространенная операция в Интернете, позволяющая предприятиям исполь-
зовать свои собственные IP-адреса (адреса, применяемые в своей локальной сети)
и, тем не менее, сообщаться с внешними сетями, использующими общие IP-адреса,
выданные через соответствующую службу Интернета. RFC 2709 [SRIS99]1 опи-
сывает процедуру получения туннельного режима пользователями IPSec. Перед
тем, как перейти к описанию этой процедуры, будет полезным дать пару опре-
делений.
О Нормальный - NAT: Обычная обработка NAT, в соответствии с RFC 2663 (короткое
руководство по NAT приведено в конце этой книги в приложении Б).
О NAT, управляемый правилами IPSec (IPSec policy controlled NAT — IPC-NAT): Расши-
рение NAT, преобразующее пакеты IPSec в туннеле IP-IP. Узел NAT является
конечной точкой туннеля.
На рис. 9.20 показаны действия, выполняемые над исходящим пакетом на узле
IPSec (например, на брандмауэре туннеля, совмещенного с NAT). На рис. 9.21 по-
казаны действия над входящим пакетом.
Исходящий
пакет
(локальная
сеть)
Рис. 9.20. Действия IPSec и NAT, выполняемые над исходящим пакетом в туннельном режиме
В соответствии с RFC 2709, основными аспектами операций IPSec-NAT являются:
О Устройство NAT применяет правила безопасности на основе локальной облас-
ти адресации.
О Правила безопасности задают конечную точку туннеля IPSec. Пакет IPSec может
подвергнуться различным видам преобразований, в зависимости от конечной
точки туннеля.
1 [SRIS99J. Srisuresh, Р., RFC 2709. Security Model with Tunnel Mode IPSec for NAT Domains, October
1999.
Заключение
185
О IPC-NAT нуждается в уникальном наборе преобразований NAT для каждого на-
бора правил безопасности. IPC-NAT выполняет преобразование адреса совместно
с обработкой IPSec и различными способами для различных соединяемых сто-
рон, в соответствии с правилами безопасности.
Пакет IPSec,
предназ-
наченный
для этого
устройства
(из внешней
сети)
Рис. 9.21. Действия IPSec и NAT, выполняемые над входящим пакетом в туннельном режиме
Действия, выполняемые устройством IPC-NAT, отличаются от действий шлюза
IPSec, не поддерживающего NAT, следующим образом (цитата из RFC 2709):
О Устройство JPC-NAT применяет правила безопасности на основе локальной об-
ласти адресации. Обычный шлюз IPSec применяет правила безопасности на
основе единственной области адресации (Интернета).
О Базовыми элементами модели безопасности IPC-NAT являются: отображение
адресов (и других определений параметров NAT) совместно с правилами безо-
пасности и атрибутами SA. Базовые элементы обычного шлюза IPSec ограни-
чиваются только правилами безопасности и атрибутами SA.
Заключение
Протокол Идентифицирующий заголовок IP (IP Authentication Header — АН)
обеспечивает сохранность данных (называемую в спецификациях сохранностью,
независимой от соединения — connectionless integrity), удостоверение происхож-
дения данных и защиту от повторения. Последнее не является обязательным и
определяется получателем после установления ассоциации безопасности.
АН может быть использован совместно с ESP.
Протокол Вложенные защищенные передаваемые данные IP (IP Encapsulating
Security Payload — ESP) может обеспечить конфиденциальность (шифрацию),
ограниченную конфиденциальность потока данных, не зависящую от соедине-
ния сохранность данных, удостоверение происхождения, данных и защиту от по-
вторения. В ESP должна быть реализована одна из этих возможностей.
ГЛАВА
Распространение,
сертификация
и управление
ключами в Интернете
В этой главе описываются распространение и сертификация открытых ключей,
а также общее управление ими. Вначале мы совершим беглый обзор возни-
кающих проблем, после чего перейдем к описанию основных RFC и рабочих до-
кументов, относящихся к теме этой главы.
Из-за того что стандарты Интернета постоянно изменяются, процедуры обмена
ключами в Интернете, опубликованные в RFC, в некоторой степени повторяют
друг друга. Один из разделов этой главы посвящен наиболее важным RFC, опи-
сывающим обмен ключами, также в нем объясняются и взаимоотношения меж-
ду этими RFC. Чтобы понять материал, излагаемый здесь и в главе 11, необхо-
димо предварительно ознакомиться с разделами главы 3 под названием «Атака
типа “человек посередине"» и «Сертификация».
Что такое инфраструктура открытого
ключа?
Система, обеспечивающая шифрацию с открытым ключом и цифровую подпись,
называется инфраструктурой открытого ключа (Public Key Infrastructure — PKI)
[CURR97]1. Предназначение PKI — управление ключами и сертификатами.
* [CURR97]. Cuury, Ian. Trusted Public-Key Infrastructures, официальный документ, который вы можете
найти по адресу http://www.entrust.com. В этом разделоглавы приводится краткое изложение этого
документа. Вы должны осознавать тот факт, что здесь вы не найдете многое из того, что описывается
в этом документе, и если вам нужны детали, то лучше всего обратиться к веб-сайту Entrust. Кроме
того, я дополнил это изложение информацией об операциях, относящихся к Интернету.
Сертификаты и центры сертификации (СА) 187
Основной идеей PKI является идентификация пользователя на основе серти-
| фиката, им предъявляемого. Для того чтобы PKI мог обеспечивать сертифика-
цию и управление ключами, в ней необходимо реализовать следующие элементы:
I О Сертификаты открытых ключей и центры сертификации (Certificate
Authorities — СА).
О Сохранение и восстановление ключей.
1 О Поддержка принятия цифровой подписи.
О Автоматическое обновление пар ключей и сертификатов.
О Управление архивом ключей.
О Поддержка взаимной сертификации.
Сертификаты и центры сертификации (СА)
Для того чтобы шифрация с открытым ключом имела смысл, пользователи долж-
ны быть уверены, что сторона, с которой осуществляется связь, заслуживает
доверия. И чтобы удостовериться в этом, используется регистрация всех пользо-
вателей PKI, называемая сертификацией открытых ключей.
Центр сертификации является представителем пользователя при создании циф-
ровых сертификатов. Эти сертификаты связывают имена пользователей с их
открытыми ключами. СА действует в PKI как доверенное лицо. И коль скоро
пользователи доверяют СА выдачу и управление сертификатами, они могут до-
верять и сертификатам, выданным этим СА. Это называется трехсторонним до-
говором.
СА создает сертификаты пользователей путем цифровой подписи набора данных,
включающих в себя следующую информацию (и дополнительные элементы):
О Полное имя пользователя. Сюда может входит не только собственно имя, но
и номер работника, пароль и любые дополнительные атрибуты, необходимые
для однозначной идентификации этого пользователя.
О Открытый ключ пользователя.
О Время действия сертификата.
О Конкретные операции, в которых этот открытый ключ может быть использован
(идентификация, шифрация или и то и другое).
То, что С А подписывает этот сертификат, удостоверяет, что любые попытки из-,
менения содержимого этого сертификата будут замечены. Так как подпись СА
на сертификате может быть проверена, то можно считать, что сертификат защи-
щен от подделок и что ему можно доверять. Подлинность сертификата опреде-
ляется путем проверки подписи СА.
Чем занимаются центры сертификации. IETF учредила глобальный центр ре-
гистраций Интернета (Internet Policy Registration Authority — IPRA), который
занимается созданием инфраструктуры СА. IPRA выдает сертификаты глобаль-
188 Глава 10. Распространение, сертификация и управление ключами в Интернете
ным центрам сертификации (Policy Certification Authorities — РСА). В свою
• очередь, РСА управляют СА, которые и сертифицируют пользователей и подчи-
ненные структуры. Кроме того, к сертификации относится расширение службы
имен доменов (Domain Name System — DNS) — обеспечение безопасности
(Security Extensions — DNSSEC), которая позволяет защищать записи в DNS.
Рабочая группа инфраструктуры открытых ключей создала спецификацию сер-
тификатов Х.509. Кроме того, в настоящее время разрабатывается служба ката-
логов Х.500, которая позволит пользователям использовать эти сертификаты Х.509.
Что еще. Почтовая служба США разрабатывает иерархию СА. Рабочая группа
по инфраструктуре открытых ключей из Национального института стандартов и
технологий (National Institute of Standards and Technology — NIST) также рабо-
тает в этой области. В Министерстве обороны США существует программа под
названием «Инициатива по созданию многоуровневой защиты информационных
систем (Multi Level Information System Initiative — MISSI)», которая начала
развертывание инфраструктуры сертификатов для американского правительства.
Кроме того, в качестве альтернативы существует PGP Web Of Trust (сеть дове-
рия PGP) — организация, которая позволяет идентифицировать пользователей
и обмениваться ключами сообществам пользователей, знающих и доверяющих
друг другу.
Поддержка принятия (non-repudiation)
Принятие означает, что индивидуум не может отвергнуть свое участие в транз-
акции. Подпись предупреждает возможный отказ от транзакции. В мире ком-
пьютеров цифровая подпись является аналогом обычной подписи, и PKI под-
держивает принятие цифровой подписи.
Наиболее важным требованием принятия является то, что ключ, используемый
при создании цифровой подписи (ключ подписи), создается и хранится пользо-
вателем так, что доступ к нему имеет только этот пользователь. В отличие от пар
ключей, используемых при шифровании, не существует требований по сохране-
нию и восстановлению пар ключей подписи в случае, если пользователь забыл
пароль, потерял или повредил их. В таком случае, принято генерировать новую
пару ключей подписи и использовать ее в дальнейшем взамен утерянной.
Сохранение и восстановление ключей
Организация должна иметь возможность извлекать зашифрованные данные, даже
если пользователь потерял дешифровальные ключи. Поэтому в такой организа-
ции должна существовать система сохранения и восстановления утерянных
ключей. , ,, .... -
Сохранение ключей и передача их на Хранение — не одно и то же. Передача клю-
чей на хранение означает, что третье лицо (например, государственная организа-
ция) может получить доступ к ключам дешифрации, необходимым для доступа
к зашифрованной информации. Сохранение ключей и их восстановление не имеют
с этим ничего общего.
Сертификаты и центры сертификации (СА) 189
СА поддерживает два вида пар ключей, описанных в главе 3. Одна разновидность
используется для шифрации и дешифрации данных (шифровальные ключи),
а другая — для цифровых подписей и их удостоверения (ключи подписи).
Единственный вид ключей, нуждающийся в сохранении, — это шифровальные
ключи. Коль скоро СА надежно хранит копии ключей пользователя, безопасность
данных не нарушается, а доступ к информации может быть получен.
Использование двух пар ключей
В целях поддержки сохранения и восстановления ключи шифрации должны
сохраняться безопасным образом. В целях поддержки принятия ключи, исполь-
зуемые для цифровой подписи, не могут быть сохранены, поскольку доступ к ним
должен иметь только данный пользователь,
Чтобы соответствовать этим требованиям, PKI должен для каждого пользовате
ля хранить две пары ключей. В любой момент времени пользователь должен иметь
одну пару у себя, для выполнения операций шифрации и дешифрации, а вторую
пару — для цифровой'подписи и удосУо^ёрения сертификатов. С течением вре-
мени у пользователя появится множество пар ключей, которйми нужно будет
управлять соответствующим образом. Этот вопрос обсуждается в следующем
разделе.
г ' > 4 ‘ 2 'А- * ‘ •' ‘! АД / 1
Обновление ключей и управление их архивом
В главах 3 и 5 мы узнали, что пары шифровальных ключей не могут использо-
ваться бесконечно. Следовательно, PKI должен обеспечивать обновление клю-
чей пользователя и поддерживать архив с предыдущими парами. Процесс обнов-
ления ключей в PKI является прозрачным для Пользователей. После того, как
пара ключей была обновлена, предыдущая пара помещается в архив. Поддержа-
ние архива ключей гарантирует, что пользователь всегда сможет получить ста-
рые ключи в случае, если ему нужно будет расшифровать данные, зашифрован-
ные с их помощью. Этот архив ключей должен управляться системой сохранения
и восстановления ключей PKI. Этим гарантируется, что зашифрованные данные
могут быть безопасно расшифрованы, безотносительно того, какой из шифроваль-
ных открытых ключей был изначально использован для шифрации этих данных
(и, как следствие, безотносительно того, когда эти данные были зашифрована).
После обновления ключей подписи предыдущая пара уничтожается. Это позво-
ляет избежать того, что другое лицо может получить доступ к ключам подписи,
и зто допустимо, поскольку предыдущая пара больше не нужна.
Хранилище сертификатов и распространение
сертификатов
Как упоминалось ранее, выдавая сертификаты, GA действует как доверенное лицо
пользователей. Хранилища сертификатов устроены таким образом, что прИло-
190 Глава 10. Распространение, сертификация и управление ключами в Интернете
жения могут извлекать сертификаты от имени пользователей. Сам термин «хра-
. нилище» относится к сетевой службе, предназначенной для распространения сер-
тификатов. Это хранилище поддерживается службой директорий, например LDAP
(Lightweight Directory Access Protocol — облегченный протокол доступа к директо-
риям) или ITU-T Х.509 Directory.
Взаимная сертификация
Взаимная сертификация позволяет расширить диапазон действия агентов сер-
тификации. Например, два торговых партнера, каждый из которых использует
свой собственный СА, могут захотеть проверять сертификаты, выданные СА
партнера. Большой организации, имеющей множество отделений, также может
потребоваться использовать различные СА в различных географических регио-
нах. Взаимная сертификация может позволить СА из различных мест устанав-
ливать и поддерживать доверительные отношения.
Хочется еще раз отметить, что здесь приведено только краткое изложение доку-
мента [CURR97], ai его полную версию вы можете найти по адресу htpp://
www.entrust.com. Кроме того, там можно найти еще несколько текстов по этой теме.
ISAKMP, область интерпретации
ISAKMP и IKE
IPSec использует ассоциации безопасности (SA) при обмене данными через за-
щищенные туннели. В IPSec предполагается, что SA были установлены до того,
как начался обмен пакетами IPSec. Очевидно, что для задания SA между соеди-
няющимися сторонами, должны существовать определеннее средства, обеспечива-
ющие это. Таким средством является протокол ассоциаций безопасности и управ-
ления ключами в Интернете (Internet Security Association and Key Management
Protocol — ISAKMP) и протокол обмена ключами в Интернете (Internet Key
Exchange — IKE).
Эти протоколы определяют механизмы (процедуры и пакеты), обеспечивающие
создание, удаление, изменение и согласование SA, а также установление ключей
в пределах области интерпретации (Domain Of Interpretation — DOI). Базовая
идея — установить IPSec DOI для того, чтобы определить, что согласовывать (это
означает использование ISAKMP для безопасного соединения двух сторон), а за-
тем применить IKE для определения действительного обмена ключами.
Разумеется, сообщения, посылаемые между двумя соединяющимися сторонами,
должны быть защищены. Поэтому в соответствующих RFC определены проце-
дуры обеспечения защиты сообщений ISAKMP и IKE. Надежная идентификация
необходима при обмене сообщениями, цифровая подпись должна быть частью
функций идентификации, но использование центра сертификации не является
обязательным.
«Защитная оболочка»
191
5АКМР
ISAKMP был разработан в Агентстве национальной безопасности (National Security
Agency — NSA). В этом протоколе определены процедуры создания, изменения,
согласования и удаления SA. В нем не задается то, как происходит собственно
обмен ключами. Эта операция выполняется при помощи протокола IKE, который
мы будем обсуждать в следующей главе. По сути, ISAKMP является протоколом
управления ассоциациями безопасности и обеспечивает базу для управления SA,
независимую от генерации ключей, шифрации и механизмов идентификации.
ISAKMP независим от различных протоколов в многоуровневой модели стека про-
токолов Интернета.
Защитная оболочка»
На рис. 10.1 показаны взаимоотношения между ISAKMP й обычными протокола-
ми в стеке Интернета. ISAKMP выполняется поверх L_4 Интернета (TCP/UDP). Важ-
ной идей, лежащей в основе такого построения протоколов, является понятие
о том, что пользователю предоставляется согласованная реализация служб без-
опасности, основанной на защитной оболочке, показанной на рисунке.
OOI— область интерпретации
API — программный интерфейс приложения
Рис. ЮЛ. Защитная оболочка
Уровень сокета является по своей сути не уровнем, а просто программой, позво-
ляющей приложениям и ISAKMP взаимодействовать с L_4. Протокол.безопасно-
сти представляет собой вставку в стек протоколов? выполняющих функции защи-
ты в сетевых соединениях. IPSec-протоколы ESP и АН — протоколы безопасности.
192 Глава 10. Распространение, сертификация и управление ключами в Интернете
TLS — это уже другой пример. D0I описывает широкий набор служб безопасно-
сти, применимых к различным организационным объектам, таким как компания,
правительственное агентство и т. д. Интернет определяет D0I Интернета, но орга-
низация может определить свою собственную. D0I включает в себя все правила
безопасности, ключи и алгоритмы шифрации. DOI ISAKMP описывается в этой главе
позже.
Определение обмена ключей задает метод (или методы) обмена ключами, такие
как RSA, Диффи—Хеллман и т. д., и определяется при помощи IKE и RFC 1409.
API (программный интерфейс приложения) определяет интерфейс между про-
токолом безопасности и ISAKMP. API не является частью протокола безопасности
или ISAKMP и публикуется в отдельных спецификациях Интернета.
Другие соображения по поводу обмена ключами
Есть еще несколько приведенных в RFC 2408 соображений, которые относятся к
открытым ключам. Обмен ключами может быть идентифицирован в процессе
обмена данных протокола или сразу после. Идентификация обмена ключами в
процессе обмена данными протокола происходит тогда, когда каждая из сторон
приводит доказательство того, что у нее есть секретный ключ этого сеанса, и до
того, как завершится обмен данными протокола. Доказательство может быть при-
ведено в виде зашифрованных известных данных в секретном ключе сеанса в
процессе обмена данными протокола. Идентификация после протокола должна
иметь место в последующем обмене данными. Идентификация в процессе обме-
на данными протокола является предпочтительной, так как последующие соеди-
нения не устанавливаются, если секретный ключ сеанса с нужной стороной не
определен.
Обмен ключами обладает симметричностью в том, какая сторона может начать
обмен, и соответствующие сообщения могут быть посланы без того, чтобы по-
влиять на генерируемый ключ. Этот подход наиболее желателен, поскольку в этом
случае вычисление ключей не требует, чтобы каждая сторона знала, кто начал
обмен. И хотя такая симметричность при обмене ключами является желатель-
ной, симметричность всего протокола управления ключами может послужить
причиной уязвимости к атакам отражением.
Фазы согласования в ISAKMP
Подтверждение (согласование) между двумя узлами ISAKMP осуществляются
в две фазы:
О Фаза 1: Узлы ISAKMP договариваются о том, как они будут защищать
дальнейший обмен данными по согласованию, путем установления SA ISAKMP.
Эта SA используется для защиты последующих согласований запрошенной SA.
SA ISAKMP отделены от других SA.
Фазы согласования в ISAKMP
193
О Фаза 2: ISAKMP устанавливает SA для других протоколов, таких как IPSec.
.Результатом этой фазы будет способность IPSec защитить данные, ассоцииро-
ванные с его SA.
SA ISAKMP определяется при помощи двух полей cookies в заголовке сообщения
согласования, а конкретные SA пользователя определяются двумя другими по-
лями: идентификатором сообщения и SPI. Первые два поля cookies и идентифи-
катор сообщения используются для определения стадии процесса согласования.
Действия ISAKMP начинаются с обмена cookies — 8-байтными псевдослучайными
числами. Эти числа уникальны для обменивающихся сторон и данного обмена.
Cookies в ISAKMP используются для обеспечения уникальности и защиты от по-
вторения пакетов. Обычно cookies вычисляются как хэш-код IP-адреса второй
стороны, номера порта и протокола, секретного кода генератора и данных теку-
щего времени.
Хорошей идеей будет завершить обмен cookies до того, как начнется другой об-
мен данными, такой как Диффи—Хеллман, для того чтобы защититься от атаки
засорением, когда хакер мог бы наводнить одну йз сторон поддельными сообще-
ниями ISAKMP с ненастоящими обратными адресами. Это не будет иметь никако-
го эффекта, поскольку второе сообщение с фальшивым cookie (фальшивым ад-
ресом) будет отвергнуто.
В табл, 10.1 имеется шесть строк, описывающих то, как эти четыре поля исполь-
зуются в процессе согласований. Строки 1 и 2 относятся к фазе 1, а строки, на-
чиная с 3 по 6, — к фазе 2. Значок «X» означает, что это поле используется в
этой стадии согласований, значок «Н» — что нет, а значок «О» — что это поле не
является обязательным.
Таблица 10.1. Основные поля согласований в сообщении ISAKMP
Событие Действие I-Cookie R-Cookie Идентификатор сообщения SPI
1 Начать согласование SA ISAKMP X 0 0 0
2 Ответить на согласование SA X X 0 0
3 Начать согласование второй SA X X X X
4 Ответить на согласование второй SA X X X X
5 Другое (KE, ID и т. д.) X X х/0/ н
6 Протокол безопасности (ESP, АН) н н н X
События соотносятся с полями таблицы следующим образом:
О Событие ^Начинающая сторона ISAKMP помещает начальное cookie (I-cookie)
в заголовок передаваемого сообщения (другие поля необязательны).
О Событие 2: Отвечающая сторона помещает ответное cookie (R-cookie) в ответное
сообщение (остальные два необязательны).
194 Глава 10. Распространение, сертификация и управление ключами в Интернете
О Событие 3; Начинающая сторона помещает в заголовок идентификатор
сообщения и SPI для идентификации используемых в этом сеансе SA и про-
токола безопасности.
О Событие 4: Отвечающая сторона посылает эту информацию обратно.
О Событие 5: Идентификатор сообщения используется для отслеживания стадии
процесса согласования. Поле SPI не применяется на этом этапе, поскольку
Предлагаемые Данные (набор полей в сообщении, обсуждаемых чуть позже)
используется только в событиях 3 и 4. '
О Событие 6: Это событие завершает согласование SPI и используется для
определения применяемых в этом сеансе служб безопасности.
Сообщения
В этом разделе объясняется устройство сообщения ISAKMP и дается дополнитель-
ная информация об этом протоколе. Сообщение ISAKMP состоит из заголовка и
следующих за ним полей данных. Такой формат позволяет создавать модульные
сообщения, содержащие различные типы данных. Конкретные типы задаются
полем типа обмена, находящимся в заголовке. На рис. 10.2 показан формат заго-
ловка. Поля, входящие в заголовок, выполняют следующие функции:
О Начальная cookie: Cookie стороны, инициировавшей определение SA, извещение
SA или удаление SA.
О Ответная cookie: Cookie стороны, отвечающей на определение SA, извещение
SA или удаление SA.
О Следующие данные: Тип первых данных в сообщении. Тип следующих данных
и соответствующие им значения показаны в табл. 10.2.
О Основная версия: Задает основную версию используемого протокола ISAKMP.
О Дополнительная версия: Задает дополнительную версию используемого
протокола ISAKMP.
О Тип обмена: Тип осуществляемого обмена, что определяет порядок следования
сообщений и данных в обмене протокола ISAKMP. Типы обменов и
соответствующие им коды приведены в табл. 10.3 и будут пояснены в этой
главе позже.
О Флаги: Обозначают несколько настроек, используемых при обмене ISAKMP. Бит
Ш (шифрация) устанавливается, когда зашифрованы все данные, идущие за
заголовком в соответствии с алгоритмом, определяемым SA ISAKMP (задается
cookies инициирующей и отвечающей сторон). Бит У (установлено) исполь-
зуется, когда завершена установка SA, перед тем как начнут передаваться
защифрованные данные. Бит И (идентификация) позволяет пересылать инфор-
мацию, которая идентифицирована, но не зашифрована.
О Идентификатор сообщения: Уникальный идентификатор сообщения.
О Длина: Общая длина сообщения (заголовок и данные).
Фазы согласования в ISAKMP
195
0 1-7 8 9 10-15 16 17 18-22 23 24 25-30 31
Начальная cookie
Ответная cookie
Следующие данные Основная версия Дополни- тельная версия Тип обмена Флаги
Идентификатор сообщения
.Длина
Рис. 10.2. Заголовок ISAKMP
Таблица 10.2. Типы данных ISAKMP
Тил следующих данных Код
Нет данных 0
Ассоциации безопасности (SA) 1
Предложение (Р) 2
Преобразование 3
Обмен ключами 4
Идентификация 5
Сертификат 6
Запрос сертификата 7
Хэш 8
Подпись 9
Данные текущего времени 10
Извещение 11
Удалить 12
Идентификатор разработчика 13
Зарезервировано 14-127
Для нужд разработчиков 128-255
Таблица 10.3. Типы обмена ISAKMP
Тил обмена Код
Нет обмена 0
База 1
Защита подлинности 2
Только идентификация 3
Агрессивный 4
Информационный 5
Для будущего использования ISAKMP 6-31
Для нужд D0I 32-239
Для нужд разработчиков 240-255
196 Глава 10. Распространение» сертификация и управление ключами в Интернете
Общий заголовок
За только что описанным заголовком следует заголовок данных, показанный на
рис. 10.3. Этот заголовок передается перед собственно данными. В ISAKMP имеет-
ся 13 типов данных, описание которых следует ниже. Поля этого заголовка пред-
назначены для выполнения следующих функций:
О Следующие данные: Идентификатор типа следующих данных. Это поле
обеспечивает формирование цепочки данных, когда одни данные определяют
тип следующих, которые, в свою очередь, — следующих, и т. д. Этот подход
позволяет обеспечить гибкий, модульный способ выбора «элементов»
информации о защите данных, передаваемой другой стороне. Некоторые типы
данных зависят друг от друга, примеры чего будут приведены ниже.
О Зарезервировано: Не используется» все значения равны 0.,
О Длина данных: Длина данных, включая заголовок, передаваемых сразу после
этого заголовка.
0 1-6 7 8 15 16 17-3 0 31
с Следующие данные Зарезервировано Длина данных
Данные текущего времени
Рис. 10.3. Типичный заголовок данных
Атрибуты данных
Существует несколько случаев, когда в ISAKMP необходимо использовать атри-
буты данных. Одним из примеров такого случая могут быть атрибуты ассоциа-
ции безопасности, находящиеся в передаваемых данных. Такие данные не отно-
сятся к ISAKMP, но передаются с его помощью. Формат атрибутов данных
обеспечивает достаточную гибкость для того, чтобы с его помощью можно было
бы перелазать множество различных типов информации. В поле данных ISAKMP
могут передаваться несколько атрибутов данных одновременно.
Возможные типы передаваемых данных
В ISAKMP определены следующие типы передаваемых данных:
О Аса циация безопасности
О Предложение
О Преобразование
О Обмен ключами
О Идентификация
Фазы согласования в ISAKMP
197
О Сертификат
О Запрос сертификата
О Хэш-код
О Подпись
О Данные текущего времени
О Извещение
О Удаление
О Идентификатор разработчика
Некоторые из этих типов данных являются взаимозависимыми. Например, пре-
образование передается вместе с предложением.
Ассоциация безопасности; Этот тип данных Задает SA, как для ISAKMP, так и для
других протоколов, таких как IPSec. Кроме того, здесь же передается и D0I, в за-
висимости от которой переданная информация используется для согласования
атрибутов безопасности. Формат этих данных показан на рис. 10.4. Приведен-
ные на этом рисунке поля выполняют следующие функции:
О Следующие данные: Идентификатор типа следующих данных.
О Зарезервировано: Не используется, все значения равны 0.
О Длина данных: Длина в байтах всех передаваемых данных, включая ассоциацию
безопасности.
О Область интерпретации: Задает D0I, в которой имеет место это согласование.
Объяснение следует ниже.
О Ситуация: Поле, относящееся к D0I, которое задает ситуацию, в которой имеет
место это согласование.
0 1-6 7 8 9-14 15 16 17-2 2 23 24 25-3 0 31
Следующие данные Зарезервировано Длина данных
Область интерпретации (DQI)
Ситуация
Рис. 10.4. Данные ассоциации безопасности (SA)
Предложение. Этот тип данных содержит информацию, используемую при со-
гласовании SA. В этих данных содержится SPI, которой соответствует опреде-
ленный идентификатор протокола. Данные предложения обеспечивают возмож-
ность передачи информации о протоколе безопасности и соответствующих
механизмах безопасности, предназначенную для использования в согласовании
ассоциации безопасности. На рис. 10.5 показан фррмат данных предложения, где
поля выполняют следующие функции:
198 Глава 10. Распространение, сертификация и управление ключами в Интернете
О Следующие данные: Идентификатор типа следующих данных.
О Зарезервировано: Не используется, все значения равны 0.
О Длина данных: Длина в байтах всех передаваемых данных, включая данные
предложения.
О Номер предложения: Задает номер предложения для текущих данных.
О Идентификатор протокола: Задает протокол, применяемый для данного
согласования. Примеры: IPSec АН или IPSec ESP.
О Номер преобразования: Задает номер преобразования данного предложения.
Каждому из этих преобразований соответствует свое описание в приводимой
ниже формею /
О SPI: SPI отправителя.
0 1-6 7 8 9-14 15 18 17-30 31
Следующие данные Зарезервировано Длина данных
Номер предложения Идентификатор протокола _ _ егм Количество Размер SPI преобразований
SPI (переменной длины)
Рис. 10.5. Данные предложения
Преобразование. Как показано на рис. 10.6, в каждом из данных этого типа со-
держится набор атрибутов преобразования, таких как алгоритм шифрации. Поля
выполняют следующие функции:
О Следующие данные: Идентификатор типа следующих данных.
О Зарезервировано: Не используется, все значения равны 0.
О Длина данных: Длина в байтах всех передаваемых данных, включая заголовок,
значения преобразования и все атрибуты ассоциации безопасности.
О Номер преобразования: Задает номер преобразования для текущих данных. Если
имеется несколько преобразований заданного протокола в текущих данных,
то каждое из преобразований имеет свой уникальный номер.
О Идентификатор преобразования: Задает идентификатор преобразования для
данного протокола в пределах текущего предложения. Эти преобразования
задаются D0I и зависят от согласуемого протокола.
О Зарезервировано 2: Не используется, все значения равны 0.
О Атрибуты SA: Содержат атрибуты ассоциации безопасности в соответствии с
преобразованием, заданным в поле идентификатора преобразования. Атрибуты
SA располагаются в соответствии с форматом атрибутов данных, описанным
ранее.
Фазы согласования в ISAKMP
199
0 1-6 7 8 9-14 15 16 17-30 31
Следующие данные Зарезервировано Длина данных
Номер преобразования Идентификатор преобразования Зарезервировано 2
Атрибуты SA
Рис. 10.6. Данные преобразования
Обмен ключами. Этот тип данных предназначен для обеспечения поддержки
некоторых механизмов поддержки ключей, таких как Диффи—Хеллман, RSA,
OAKLEY и т. д. На рис. 10.7 показан формат этих данных, поля которых выполня-
ют следующие функции:
О Следующие данные: Идентификатор типа следующих данных.
О Зарезервировано: Не используется, все значения равны 0.
О Длина данных: Длина в байтах всех передаваемых данных, включая заголовок.
О Данные обмена ключей: Данные, необходимые при создании сеансового ключа.
Интерпретация данных зависит от D0I и используемого алгоритма обмена
ключей.
0 1-6 7 8 9-14 15 18 17-30 31
Следующие данные Зврезервировано Длина данных
Данные обмена ключей
Рис. 10.7. Данные обмена ключей
Идентификация. Данные этого типа содержат зависящую от D0I информацию,
предназначенную для обмена сведениями об идентификации, используемую для
определения подлинности соединяемых сторон или передаваемых данных.
На рис. 10.8 показан формат данных идентификации, поля которого выполняют
следующие функции:
О Следующие данные: Идентификатор типа следующих данных.
О Зарезервировано: Не используется, все значения равны 0.
О Длина данных: Длина в байтах всех передаваемых данных, включая заголовок.
О Идентификатор типа: Задает тип проводимой идентификации.
О Данные D0I: Содержит зависящие от D0I данные идентификации.
О Данные идентификации: Содержит данные идентификации. Значение этого поля
зависит от D0I.
200 Глава 10. Распространение, сертификация и управление ключами в Интернете
0 1-6 7 8 9-14 15 16 17-30 31
Следующие данные Зарезервировано Длине данных
Идентификатор типа Данные DOI
Данные идентификации
Рис. 10.8. Данные идентификации
Запрос сертификата. Этот тип данных предоставляет механизм запроса серти-
фиката через протокол ISAKMP. Такой запрос включается в обмен данными ISAKMP
всегда, когда невозможно получение сертификатов через соответствующую служ-
бу каталогов. В ответ на запрос сертификата вторая сторона посылает свой сер-
тификат, если таковой имеется, в соответствии с данными, переданными в за-
просе. Если необходимо получение нескольких сертификатов, тогда необходимо
послать соответствующее количество запросов сертификатов. На рис. 10.9 пока-
зан формат данных этого типа, где поля выполняют следующие функции:
О Следующие данные: Идентификатор типа следующих данных.
О Зарезервировано: Не используется, все значения равны 0.
О Длина данных: Длина в байтах всех передаваемых данных, включая заголовок.
О Тип сертификата: Содержит тип запрашиваемого сертификата (возможные зна-
чения будут приведены ниже).
О Центр сертификации: Содержит код приемлемого центра сертификации (на-
пример, Entrust) для запрошенного типа сертификата. Например, в случае
сертификата Х.509 это поле могло бы содержать код названия эмитента серти-
фиката Х.509 — центр сертификации Х.500, как приемлемый для отправителя
этих данных.
0 1-6 7 8 9-14 15 16 17-30 31
С Следующие данные Зарезервировано Длина данных
Идентификатор типа Центр сертификации
I * Центр сертификации (продолжение)
Рис. 10.9. Данные запроса сертификата
Сертификат. Этот тип данных предназначен для передачи сертификатов и отно-
сящейся к ним информации посредством протокола ISAKMP и может быть послан
в любом сообщении ISAKMP. Данные о сертификации должны обрабатываться в
любой точке обмена сообщениями. На рис. 10.10 показан формат этих данных.
Поля формата выполняют следующие функции:
О Следующие данные: Идентификатор типа следующих данных.
О Зарезервировано: Не используется, все значения равны 0.
Фазы согласования в ISAKMP
201
О Длина данных: Длина в байтах всех передаваемых данных, включая заголовок.
О Тип сертификата: Содержит тип сертификата или относящейся к нему ин-
формации, находящейся в поле данных сертификата. Например, здесь может
содержаться сертификат PGP, ключ подписи DSN, сертификат Х.509 и т. д.
О Данные сертификата: Содержит собственно данные сертификата. Тип данных
задается в поле типа сертификата.
0 1-6 7 В 9-14 15 16-30 31
Следующие данные Зарезервировано Длина данных
Идентификатор типа Данные сертификата
Данные сертификата (продолжение)
' Рис. 10.10. Данные сертификата
Хэш-код. Этот тип данных предназначен для пересылки данных, сгенерирован-
ных хэш-функцией (выбранной в процессе определения SA), выполненной над
данными части сообщения и/или состояния ISAKMP. Хэш-код может быть исполь-
зован для удостоверения целостности данных сообщения ISAKMP или для иден-
тификации в процессе согласования. На рис. 10.11 показан формат хэш-кода, а его
поля выполняют следующие функции:
О Следующие данные: Идентификатор типа следующих данных.
О Зарезервировано: Не используется, все значения равны 0.
О Длина данных: Длина в байтах всех передаваемых данных, включая заголовок.
О Данные хэщ-кода: Результат применения хэш-функции к сообщению и/или
состоянию ISAKMP.
0 1-6 7 8 9-14 15 16 17-30 31
Следующие данные Зарезервировано Длина данных
Данные хэш-кода
Рис. 10.11. Данные хэш-кода
Подпись. Этот тип данных предназначен для пересылки результата выполнения
функции цифровой подписи (выбранной в процессе определения SA), выполнен-
ной над данными части сообщения и/или состояния ISAKMP. Цифровая подпись
может быть использована для удостоверения Целостности данных сообщения
202 Глава 10. Распространение, сертификация и управление ключами в Интернете
ISAKMP или для обеспечения принятия (non-repudiation). На рис. 10.12 показан
формат цифровой подписи. Поля формата выполняют следующие функции:
О Следующие данные: Идентификатор типа следующих данных.
О Зарезервировано: Не используется, все значения равны 0.
О Длина данных: Длина в байтах всех передаваемых данных, включая заголовок.
О Данные цифровой подписи: Результат применения функции цифровой подписи
к сообщению и/или состоянию ISAKMP.
0 1-6 7 8 9-14 15 16 17-30 31
Следующие данные Зарезервировано Длина данных
Данные подписи
Рис 10.12. Данные подписи
Данные текущего времени. Этот тип данных предназначен для пересылки псев-
дослучайного числа, используемого для обеспечения живучести в процессе об-
мена и защиты от атак повторением. На рис. 10.13 показан формат данных теку-
щего времени. Если значение этого поля используется в конкретном обмене
данными, то его применение определяется этим обменом.
Поля формата выполняют следующие функции:
О Следующие данные: Идентификатор типа следующих данных. Если эти данные
последние в сообщении, то значение этого поля равно 0.
О Зарезервировано: Не используется, все значения равны 0.
О Длина данных: Длина в байтах всех передаваемых данных, включая заголовок.
О Данные текущего времени: Содержит случайное число, сгенерированное пере-
дающей стороной.
0 1-6 7 8 9-14 15 16 17-30 31
Следующие данные Зарезервировано Длина данных
Данные текущего времени
Рис. 10.13. Данные текущего времени
Извещение. Этот тип данных используется для передачи данных D0I или ISAKMP
и применяется при пересылке информационных сообщений, таких как возник-
новение ошибок. На рис. 10.14 показан формат извещения.
Фазы согласования в ISAKMP
203
Извещение, которое возникло в течение согласований фазы 1 или имеющее к этой
фазе отношение, идентифицируется парой cookies отправителя и получателя в за-
головке ISAKMP. Идентификатор протокола в этом случае будет ссылаться на
ISAKMP, а значение поля SPI будет равно 0, поскольку пара cookies в заголовке
ISAKMP идентифицирует SA ISAKMP. Если извещение посылается до завершения
обмена ключами, то в этом случае информация извещения будет не защищена.
Извещение, которое либо возникло в течение согласований фазы 2, либо имеет к
этой фазе какое-то отношение, идентифицируется парой cookies отправителя и
получателя в заголовке ISAKMP, идентификатором сообщения и SPI, соответству-
ющим текущему согласованию. Одним из примеров такого извещения может быть
объяснение причины отказа выполнения предложения.
Поля формата выполняют следующие функции:
О Следующие данные: Идентификатор типа следующих данных. Если эти данные
последние в сообщении, то значение этого поля равно 0.
О Зарезервировано: Не используется, все значения равны 0.
О Длина данных: Длина в байтах всех передаваемых данных, включая заголовок.
О Область интерпретации: Указывает D0I, в которую послано извещение.
Для ISAKMP это значение равно 0, а для DOI IPSec — 1.
О Идентификатор протокола: Задает протокол, к которому данное извещение имеет
отношение. Примерами могут быть ISAKMP, IPSec ESP, IPSec AH, OSPF, TLS и др.
О Размер SPI: Длина SPI в байтах, как задано идентификатором протокола.
О Тип сообщения извещения: Задает тип сообщения извещения. Дополнительная
информация, если задано в D0I, передается в данных извещения.
О SPI: Индекс параметра безопасности.
О Данные извещения: Данные извещения с информацией или ошибкой, пере-
даваемые, если это требуется, значением типа сообщения извещения.
0 1-6 7 8 9-14 15 16 17-30 31
Следующие данные Зарезервировано Длина данных
Идентификатор протокола Размер SPI Тип сообщения извещения
Индекс параметра безопасности (SPI) Область интерпретации (DO1)
Тип сообщения извещения
Рис. 10.14. Данные извещения
204 Глава 10. Распространение, сертификация и управление ключами в Интернете
Типы сообщений извещения. Информация извещения может содержать сооб-
щения об ошибках, объясняющих, почему SA не может быть определена. Это могут
быть данные о состоянии, которые процесс, управляющий базами данных SA, хотел
бы сообщить процессу другой соединяющейся стороны. Если вы хотите узнать
об этом поподробнее, то в RFC 2408 (раздел 3.14.1) даны соответствующие пояс-
нения.
Удаление. В поле данных «того типа содержится идентификатор ассоциации
безопасности, которую отправитель удалил из своей базы данных ассоциаций
безопасности и, таким образом, не имеющую больше силы. На рис. 10.15 показан
формат этого типа данных. Разрешается посылать несколько SPI в данных удале-
ния, однако все SPI должны быть для одного и того же протокола. Смешивание
идентификаторов протокола не разрешается в этом типе данных.
Поля формата выполняют следующие функции:
О Следующие данные: Идентификатор типа следующих данных. Если эти данные
последние в сообщении, то значение этого поля равно 0.
О Зарезервировано: Не используется, все значения равны 0.
О Длина данных: Длина в байтах всех передаваемых данных, включая заголовок.
О Область интерпретации: Указывает D0I, в которую послано извещение.
О Идентификатор протокола: ISAKMP может задавать ассоциации безопасности для
различных протоколов, включая ISAKMP и IPSec. Это поле определяет базу
данных ассоциаций безопасности, к которой относится запрос на удаление.
О Размер SPI: Длина SPI в байтах, как задано идентификатором протокола.
В случае ISAKMP пара cookies отправителя и получателя являются SPI ISAKMP.
О Количество SPI: Задает количество SPI, содержащихся в данных удаления.
О SPI: Задает удаляемую ассоциацию безопасности (удаляемые ассоциации
безопасности). Значение этого поля зависит от D0I и протокола.
0 1-6 7 8 9-14 15 16 17-3 0 31
Следующие данные Зарезервировано Длина данных
Область интерпретации (DOI)
Идентификатор протокола Размер SPI Размер SPI
Индексы) параметра безопасности (SPI)
Рис. 10.15. Данные удаления
Идентификатор разработчика. Этот тип данных предназначен для передачи оп-
ределяемой разработчиком константы. Эта константа используется производи-
телем для определения разработанного им программного обеспечения. Этот ме-
OAKLEY и ISAKMP 205
ханизм позволяет разработчикам экспериментировать с новыми возможностя-
ми, сохраняя при этом обратную совместимость хотя это не является общепри-
нятым методом расширения ISAKMP. На рис. 10.16 показан формат идентифика-
тора разработчика.
Поля формата выполняют следующие функции:
О Следующие данные: Идентификатор типа следующих данных. Если эти данные
последние в сообщении, тб значение этого поля равно 0.
О Зарезервировано: Не используется, все значения равны 0.
О Длина данных: Длина в байтах всех передаваемых данных, включая заголовок.
О Идентификатор разработчика (VID): Хэш-код строки данных разработчика плюс
номер версии (как описано выше).
0 1-6 7 8 9-14 15 16 17-30 31
Следующие данные Зарезервировано Длина данных
Идентификатор разработчика (VID)
Рис. 10.16. Данные текущего времени
OAKLEY и ISAKMP
Спецификация OAKLEY приведена в главе 5. Отображение полей OAKLEY на струк-
туру сообщения ISAKMP описывается далее. Все поля сообщения OAKLEY имеют
соответствие в данных сообщения ISAKMP или их компонентах. Такими данными
в ISAKMP являются SA, идентификация, сертификат и обмен ключами.
В табл. 10.4 приведен список соответствий между полями OAKLEY и структурой
сообщения ISAKMP. Это предварительный список, поскольку окончательное ре-
шение находится в процессе разработки.
Таблица 10.4. Отображение полей OAKLEY и ISAKMP
CKY-I Заголовок ISAKMP
CKY-R Заголовок ISAKMP
MSGTYPE Тип сообщения в заголовке ISAKMP
GRP Данные SA, раздел предложения
дАх (или д'у) Данные обмена ключами, кодируется как целое переменной
ДЛИНЫ
EHAOhEHAS Данные SA, раздел предложения
IDP Бит в поле Зарезервировано заголовка AUTH
продолжение &
206 Глава 10. Распространение, сертификация и управление ключами в Интернете
Таблица 10.4 (продолжение)
ID(I) Данные AUTH, поле Удостоверения
I0(R) Данные AUTH, поле Удостоверения
N1 Данные AUTH, поле Данных текущего времени
Nr Данные AUTH, поле Данных текущего времени
S{?}Kx Данные AUTH, поле Данных
Prf{K.?} Данные AUTH, поле Данных
Примеры согласований ISAKMP
Рисунки в этом разделе главы являются примерами (взятыми из RFC 2408, раз-
дел 4.2) обмена сообщениями при определении ассоциации безопасности между
двумя компьютерами. Многие детали в этих примерах опущены, но, тем не ме-
нее, вы можете получить представление о потоках данных в протоколе ISAKMP.
Во всех этих примерах «HDR» означает заголовок, что описывался в этой главе
ранее. Аббревиатуры на рисунках означают следующее:
О HDR: Заголовок ISAKMP, содержащий тип обмена, который определяет формат
данных.
О SA: Данные согласования, содержащие одно или больше полей предложений
и преобразований.
О КБ: Данные обмена ключами.
О Юх: Данные идентификации для х. х может быть 11 или 1г в случае ISAKMP
инициатора и получателя, соответственно, х может быть ui или иг (когда демон
ISAKMP служит посредником при согласовании), в случае когда пользователь
является инициатором или получателем.
О HASH: Данные хэш-кода.
О SIG: Данные подписи.
О AUTH: Общий механизм идентификации, такой как HASH или SIG.
О NONCE: Данные текущего времени.
О *: Означает шифрацию данных, следующих за заголовком ISAKMP.
О N/D: Данные извещения/удаления.
Базовый обмен
Этот обмен обеспечивает обмен ключами и данные идентификации. События,
происходящие при этом типе обмена, показаны на рис. 10.17, а их описание сле-
дует ниже:
О Событие 1: Инициатор начинает согласование SA ISAKMP путем отправления
предложения, соответствующего защищенному потоку информации. Данные
Примеры согласований ISAKMP 207
SA содержат SA, информацию о предложениях и преобразованиях, а данные
текущего времени включаются с целью защиты от атак повторением.
О Событие 2: Получатель отправляет обратно данные SA, предложения и пре-
образования (и текущего времени), что говорит инициатору, что основная SA
была определена.
О События 3 и 4: Инициатор и получатель обмениваются материалом ключей,
используемых для получения общего секретного кода и информации иденти-
фикации. Передача этих сведений защищается при помощи согласованной
ранее функции идентификации. В результате полностью определяется SA.
Получатель
Инициатор
Ф HDR, SA, NONCE
HDR, SA, NONCE (g)
(3) HDR, KE, iDil, AUTH
HDR, KE, IDir, AUTH ©
Рис. 10.17. Основной обмен
Обмен с защитой конфиденциальности
При этом обмене разделяется информация обмена ключей и относящиеся к иден-
тификации данные с целью защиты конфиденциальности соединяющихся сто-
рон. Идентификация защищается при помощи разделяемого секретного кода.
Обмен сообщениями показан на рис. 10.18, а происходящие при этом события
описываются ниже:
О Событие 1: Инициатор начинает согласование SA ISAKMP путем отправления
предложения, соответствующего защищенному потоку информации. Данные
SA содержат SA, информацию о предложениях и преобразованиях, а данные
текущего времени включаются с целью защиты от атак повторением.
О Событие 2: Получатель информирует инициатора, что режим защиты данных
принимается.
О Событие 3 и 4: Инициатор и получатель генерируют ключ и обмениваются
материалом ключей, используемым при создании разделяемого секретного
кода.
О События 5 и 6: Инициатор и получатель идентифицируют друг друга в режиме
защиты данных. Идентификация произошла.
208 Глава 10. Распространение, сертификация и управление ключами в Интернете
Инициатор
Получатель
Ф HDR, SA
ТО, SA@
®HDR, KE, NONCE
HDR, KE, NONCE® •
® HDR, IDii, AUTH
HDR. IDir,AUTH®
Рис. 10.18. Обмен с защитой конфиденциальности
Обмен идентификации
Этот тип обмена позволяет передать только информацию идентификации меж-
ду двумя защищенными узлами, в случае, когда шифрация данных не нужна. Вся
информация, передаваемая по каналу связи при этом типе обмена, не защищена.
На рис. 10.19 показаны сообщения, передаваемые между узлами, а происходя-
щие при этом события описываются ниже:
Инициатор
ф HDR, SA, NONCE
Получатель
HDR, IDii. AUTH
HDR, SA, NONCE, IDir, AUTH @
Рис. 10.19. Обмен с защитой конфиденциальности
О Событие 1: Инициатор начинает согласование SA ISAKMP путем отправления
предложения, соответствующего защищенному потоку информации. Данные
SA содержат SA, информацию о предложениях и преобразованиях, а данные
текущего времени включаются с целью защиты от атак повторением.
О Событие 2: Получатель информирует инициатора, что режим защиты данных
принимается. Кроме того, получатель передает информацию идентификации.
Область интерпретации (DOI) ISAKMP 209
Эти данные защищены с помощью предварительно согласованной функции
идентификации.
О Событие 3: Инициатор посылает его информацию идентификации, которая
защищена функцией идентификации.
Агрессивный обмен
Для того чтобы уменьшить количество передаваемых сообщений, необходимых
при определении SA, этот тип обмена'позволяет SA обмен ключами и идентифи-
кацию передавать в одном сообщении. Минусом такого подхода является то, что
идентификация происходит в незащищенном режиме. На рис. 10.20 показаны
сообщения, передаваемые при этом типе обмена, а происходящие при этом со-
бытия описываются ниже:
О Событие 1: Инициатор начинает согласование SA ISAKMP путем отправления
предложения, соответствующего защищенному потоку информации. Данные
SA содержат SA, информацию о предложениях и преобразованиях.
О Событие 2: Получатель информирует инициатора, что режим защиты данных
принимается, включая материал ключей, Используемых для получения
разделяемого секретного кода, а также случайное число, используемое для
защиты от повторения.
О Событие 3: Инициатор посылает результаты выполнения согласованной ранее
функции идентификации, защищенной при помощи разделяемого секретного
кода.
Инициатор
Получатель
(Dhdr,sa,ke
HDR, SA, KE, NONCE, IDir, AUTH (2)
@ HDR, AUTH
Рис. 10.20. Агрессивный обмен
Область интерпретации (DOI) ISAKMP
Область интерпретации (DOI) ISAKMP опубликована в RFC 2407 [PIPE98]1, и в
этом разделе приводится краткое описание DOI ISAKMP, данное в этом RFC. D0I
определяет формат данных, типы обмена и соглашения, принятые при наимено-
1 [Р1РЕ98]. Piper. D. The Internet IP Security Domain of Interpretation for ISAKMP, RFC 2407, November
1998.
210 Глава 10. Распространение, сертификация и управление ключами в Интернете
вании информации, относящейся к защите данных, такой как правила безопас-
ности, алгоритмы шифрации или режимы. Идентификатор P0I используется при
извлечении информации из данных ISAKMP.
DOI определяют:
О Ситуацию: Набор данных, задающих службы безопасности, предоставляемые
пользователю ISAKMP.
О Синтаксис: Конкретный синтаксис для предполагаемых служб безопасности.
О Наименование: Конкретные Схемы, используемые при именовании и
идентификации защищаемой информации, включая центры сертификации,
атрибуты правил безопасности и алгоритмы обмена ключей.
Поскольку ISAKMP занимается SA, тогда SA должны быть частью системы безо-
пасности и управления ключами. ISAKMP обеспечивает протокол для определе-
ния и управления SA следующим образом. Базовый набор атрибутов согласовы-
вается для обеспечения защиты обмена ISAKMP (включая обмен идентификации
и ключами, которые будут являться частью протокола ISAKMP). Этот начальный
обмен может быть пропущен в случае, если набор соответствующих атрибутов
уже задан. В любом случае после того, как эти атрибуты были согласованы, за-
данная SA используется стороной, вызвавшей ISAKMP.
Данные, передаваемые IPSec/ISAKMP
В этом разделе дается описание данных, передаваемых IPSec/ISAKMP: ассоциация
безопасности и идентификация. На рис. 10.21 показан формат данных для ассо-
циации безопасности. Поля выполняют следующие функции (все значения ре-
зервных полей равны 0 и все длины даются в байтах):
О Следующие данные: Задает тип данных следующих данных в этом сообщении.
О Длина данных: Длина данных, включая заголовок.
О Область интерпретации: Задает DOI IPSec, которое имеет значение 1.
О Ситуация: Используется при интерпретации оставшейся части данных
ассоциации безопасности. Ситуация (набор данных) является основой для
принятия решения о способе защиты канала связи (открытый или закрытый
алгоритм шифрации, например). Обе стороны должны понимать ситуацию для
того, чтобы установить безопасный канал связи между собой. Поле ситуации
зависит от значения D0I.
О Помеченный идентификатор домена: Номер, выданный IANA, который
используется при интерпретации информации о защите и целостности данных.
О Длина поля уровня секретности: Задает длину поля уровня секретности.
О Уровень секретности: Задает необходимый уровень секретности.
Данные, передаваемые IPSec/ISAKMP 211
О Длина битового массива категории секретности: Задает длину битового массива
категории секретности.
О Битовый массив категории секретности: Используется для определения
необходимых категорий секретности.
О Длина поля уровня сохранности данных: Длина идентификатора уровня
сохранности данных.
О Уровень сохранности данных: Задает необходимый уровень сохранности данных.
Q Длина битового массива категории сохранности данных: Задает длину битового
массива категории сохранности данных.
О Битовый массив категории сохранности данных: Используется для определения
необходимых категорий сохранности данных
0 1-6 7 В 9-14 15 16 17-30 31
Следуйщие данные Зарезервировано Длина данных
Область интепретации (IPSec)
Ситуация (битовый массив)
Помеченный идентификатор домена
Длина поля секретности (в байтах) Зарезервировано
Уровень секретности
Длина битового массива категории секретности (в битах) Зарезервировано
Битовый массив категории секретности
Длина поля уровня сохранности данных (в байтах) Зарезервировано
Уровень сохранности данных
Длина битового массива категории сохранности данных (в битах) Зарезервировано
Битовый массив категории сохранности данных
Рис. 10.21. Формат данных ассоциации безопасности
На рис. 10.22 показан формат данных идентификации, которые используются при
идентификации инициатора ассоциации безопасности. Получатель этого сооб-
щения применяет полученную информацию для определения правильного на-
бора правил безопасности для данной ассоциации. В качестве примера можно
привести SA, которая обуславливает то, какие определенные IP-адреса, иденти-
фикаторы протоколов и номера портов нуждаются в идентификации, а какие —
нет. Поля в этом формате выполняют следующие функции:
О Следующие данные: Задает тип данных следующих данных в этом сообщении.
О Зарезервировано: Не используется, равно 0.
О Длина данных: Длина данных, включая заголовок.
212 Глава 10. Распространение, сертификация и управление ключами в Интернете
О Тип идентификации: Значение, описывающее информацию идентификацйй,
найденную в поле данных идентификации.
О Идентификатор протокола: Значение, задающее используемый протокол IP
(например, TCP/UDP). Если значение этого поля равно 0, то оно игнорируется.
О Порт: Значение, задающее используемый порт. Если значение этого поля равно
0, то оно игнорируется..
О Данные идентификации: Значение, определяемое полем типа идентификации,
которое кодируется в соответствии с данными табл. 10.5. В последующей части
этого раздела приводится описание типов идентификации.
0 1-6 7 8 9-14 15 16 17-30 31
Следующие данные Зарезервировано Длина данных
Тип идентификации Идентификатор протокола Порт
Данные идентификации
Рис. 10.22. Формат данных идентификации
Типы идентификации. Как ясно из Названия, это поле данных используется для
обозначения типов операций, процедур и протоколов идентификации.
В табл. 10.6 перечисляются значения идентификаторов протоколов безопаснос-
ти используемых в данных предложения ISAKMP в DOI IPSec.
Таблица 10.5. Типы идентификации
Тип идентификации Значение Описание
RESERVED o
ID_IPV4_ADDR 1 Адрес IPv4
ID_FQDN 2 Полное доменное имя
ID_USER_FQDN 3 Полное имя пользователя
ID_IPV4_ADDR_SUBNET 4 Диапазон адресов IPv4 и маска
ID_IPV6_ADDR 5 Адрес IPv6
ID_IPV6_ADDR_SUBNET 6 Диапазон адресов IPv6 и маска
ID_IPV4_ADDR_RANGE 7 Начальный и конечный адрес диапазона (IPv4)
ID_IPV6_ADDR_RANGE 8 Начальный и конечный адрес диапазона (IPv6)
ID_DER_ASN1_DN 9 .ii- Полное имя Х.БОО
ID_DER_ASN1_GN 10 Общее имя Х.500
ID_KEY_ID 11 Защищенный поток байт (зависит от производителя)
Данные, передаваемые IPSec/ISAKMP 213
Таблица 10.6. Идентификаторы протоколов
Идентификатор протокола Значение
RESERVED 0
PRDTOJSAKMP i
PROTD_IPSEC_AH . 2
PROTO_IPSEC_ESP 3
PROTOJPCOMP 4
Как часть фазы 1 согласования ISAKMP, выбор инициатором предложения спосо-
ба обмена ключами делается на основе некоторых характеристик правил безо-
пасности узла. Реальный же выбор механизма обмена ключей осуществляется
на основе данных предложения ISAKMP. В табл. 10.7 приводится список иденти-
фикаторов преобразований ISAKMP, фаза 1, для данных предложения в DOI IPSec.
Таблица 10.7. Идентификаторы преобразований
Преобразование Значение
RESERVED 0
KEY IKE i
Протокол идентифицирующего заголовка (АН) определяет одно обязательное и
несколько факультативных преобразований, используемых при идентификации,
обеспечении сохранности данных и защите от повторений. В табл. 10.8 перечис-
ляются идентификаторы преобразований АН для данных предложения в DOI IPSec.
Таблица 10.8. Преобразования АН
Идентификатор преобразования Значения
RESERVED AH_MD5 AH_SHA AH_DES 0-1 2 3 4
Протокол Вложенные защищенные передаваемые данные (ESP) определяет одно
обязательное и несколько факультативных преобразований, используемых для
обеспечения конфиденциальности. В табл. 10.9 приводится список идентифика-
торов преобразования ESP для данных предложения в DOI IPSec.
214 Глава 10. Распространение, сертификация и управление ключами в Интернете
Таблица 10.9. Преобразования ESP
Идентификатор преобразования Значение
RESERVED ESP_DES_PV64 ESP_DES ESP_3DES ESP_RC5 ESPJDEA ’ ESP_CAST ESP-BLOWFISH ESP_3IDEA ESP_DES_IV32 ESP_RC4 ESP_NULL 0 1 2 3 4 5 6 7 8 9 10 11
Заключение
В ISAKMP определены процедуры для определения, согласования, изменения и
удаления SA, но не задаются процедуры собственно обмена ключей. Эта опера-
ция определена в IKE. ISAKMP является протоколом управления ассоциациями
безопасности, независимым от процедур генерации ключей, шифрации и меха-
низмов идентификации.
ГЛАВА Обмен ключами
В этой главе продолжается начатое в главе 10 обсуждение процедур обмена
ключами. В основном оно будет касаться протокола Обмена ключами в Ин-
тернете (Internet Key Exchange — IKE), специфицированного в RFC 2409. Основ-
ным подходом в описании IKE будет рассмотрение основных возможностей это-
го протокола и демонстрация примеров, показывающих, какие потоки данных
возникают между двумя узлами, желающими обменяться ключами. В заверше-
ние этой главы мы поговорим об двух организациях инфраструктуры открытых
ключей (Public-Key Infrastructure — PKI): Entrust и VeriSign.
Основы IKE
IKE описывает протокол, использующий OAKLEY и SKEME совместно с ISAKMP, пред-
назначенные для обмена идентифицированным материалом ключей между дву-
мя соединяющимися сторонами й установления ассоциаций безопасности, таких
как АН и ESP в DOI IPSec. Его предназначение — защищенное согласование и достав-
ка идентифицированного материала ключей для ассоциаций безопасности (SA).
Возможности IKE позволяют использовать его для определения SA, отличных от
IPSec. Установленные SA зависят от конкретной области интерпретации (D0I).
В настоящий момент существуют D0I для IPSec, RIPV2 и OSPF.
IKE тесно связан с ISAKMP и проходит те же две фазы (приведенные в главе 10),
что и ISAKMP. В случае IKE эти фазы такие:
1. Фаза 1: Установить ассоциацию безопасности IKE.
2. Фаза 2: Использовать ассоциацию безопасности IKE для согласования SA IPSec
или другого протокола.
В IKE определены два типа обмена для фазы 1 и один обмен для фазы 2, кроме
того, существуют два «специальных» типа обмена. Фаза 1 использует два типа
обмена ISAKMP: обмен с защитой конфиденциальности и агрессивный обмен, ко-
216
Глава 11. Обмен ключами
торые называются в IKE основным и агрессивным режимом, соответственно.
Полный обмен IKE состоит из следующих пунктов:
О Обмен фазы 1
О Основной режим
О Агрессивный режим
О Обмен фазы 2
О Быстрый режим
О Информационный обмен
О Обмен новых групп
Как описывается в главе 10, IKE представляет собой комбинацию OALEY и SKEME
с ISAKMP, которая применяется для согласования и получения материала ключей
для ассоциаций безопасности в защищенном режиме. Конфиденциальность дос-
тигается путем использования согласованного алгоритма шифрации. Идентифи-
кация обеспечивается согласованием и применением одного из следующих ме-
тодов: цифровая подпись, алгоритм открытых ключей (поддерживающий
шифрацию) или разделяемый ключ.
Определения
IKE — это всеохватывающий и сложный протокол. Перед тем как начать разбор
его правил и процедур, необходимо сделать несколько определений терминов,
применяемых в IKE:
О HDR: Заголовок ISAKMP, поле типа обмена которого определяет режим. Если
пишется HDR*, то это означает, что данные зашифрованы.
О SA: Данные согласования, содержащие одно или несколько предложений.
Инициатор может сделать несколько предложений в процессе согласования.
Получатель отвечает только одним.
О <Р>_Ь: Означает тело данных <Р> — сюда не входят данные общего вида
ISAKMP.
о SAi_b: Все тело данных SA (минус заголовок общего вида ISAKMP). Иными
словами, это D0I, ситуация, все предложения и все преобразования,
предложенные инициатором.
О CKY-I и CKY-R: Соответственно, cookies инициатора и получателя из заголовка
ISAKMP.
О дЛх1 и дЛхг: Открытые значения Диффи—Хеллмана инициатора и получателя,
соответственно.
О дЛху: Разделяемый секретный код Диффи-Веллмана.
О КЕ: Данные обмена ключами, которые содержат открытую информацию,
передаваемую в процессе обмена Диффи—Хеллмана. •
Аспекты IKE и ISAKMP
217
О Nx: Данные текущего времени, х может быть i или г в случае инициатора и
получателя ISAKMP, соответственно.
о IDx: Данные идентификации для х. х может быть И или ir в случае инициатора
и получателя ISAKMP, соответственно, в течение согласований фазы 1; или ui и
иг для инициатора и получателя, соответственно, в течение фазы 2.
О SIG: Данные подписи. Подписываемые данные зависят от типа обмена.
о CERT: Данные сертификации.
О HASH: Данные хэш-кода (как и для всех производных обозначений, например
HASH(2) или HASH_I). Эти данные интерпретируются в зависимости от метода
идентификации.
о prf(key. msg): Псевдослучайная функция с ключом (часто хэш-функция с
ключом), используемая для получения предопределенного результата,
выглядящего псевдослучайным. Эта функция используется как при получении
ключей, так и для идентификации (например, как МАС с ключом).
о SKEYID: Строка, получаемая из секретного материала ключей, известного только
участникам обмена.
о SKEYID e: Материал ключей, используемый SA ISAKMP для защиты конфиден-
циальности своих сообщений.
О SKEYID_a: Материал ключей, используемый SA ISAKMP для идентификации своих
сообщений.
о SKEYID_d: Материал ключей, используемый при получения ключей для SA, не
относящихся к ISAKMP.
О <х>у: Означает, что х зашифрован при помощи ключа у.
О |: Означает конкатенацию информации, например X|Y означает конкатенацию
Хи Y.
О [х]: Означает, что х не является обязательным.
Совершенная прямая секретность
IKE обеспечивает совершенную прямую секретность (Perfect Forward Secrecy —
PFS) как материала ключей, так и участников соединения. Путем установки груп-
пы Диффи—Хеллмана и передачи открытых значений в данных КЕ стороны ISAKMP
могут установить PFS ключей. Конфиденциальность обеспечивается SKEYID e из
SA ISAKMP и, таким образом, не защищается при помощи PFS.
Аспекты IKE и ISAKMP
Следующие атрибуты используются IKE и согласовываются как часть ассоциа-
ции безопасности ISAKMP: алгоритм шифрации, алгоритм хэш-функции, метод
идентификации и информация о группе Диффи—Хеллмана.
218
Глава 11. Обмен ключами
Режимы установления
идентифицированного обмена ключей
Как объяснялось ранее, в IKE определено два метода фазы 1, предназначенных
для установления идентифицированного обмена ключей: основной метод и аг-
рессивный метод. Каждый режим генерирует идентифицированный материал
ключей на основе обмена Диффи—Хеллмана. Использование основного метода
обязательно, агрессивный метод является рекомендованным;
В добавление к этому быстрый режим фазы 2 представляет собой механизм ге-
нерации нового материала ключей и для согласования служб безопасности, не
относящихся к ISAKMP. Кроме того, режим новой группы рекомендуется в RFC
1409 как механизм определения частных групп для обменов Диффи—Хеллмана.
В конечных реализациях не предполагается изменять режимы обмена в середи-
не операции обмена ключами.
Все типы обмена соответствуют-стандартному синтаксису данных, передаваемых
в ISAKMP, кодированию атрибутов, тайм-аутам и повторной передаче сообщений,
а также информационным сообщениям, описанным в главе 10. При обмене в фазе
1 данные SA передаются впереди всех остальных данных.
Основной и агрессивный режимы относятся к обмену в фазе 1 и используются
для установления ассоциации безопасности IKE. Таким образом, все другие типы
обмена могут иметь место только после успешного завершения одной из этих фаз.
Основной режим
Основной режим — это установление обмена ISAKMP с защитой конфиденциаль-
ности, который состоит из пересылки шести сообщений. Как будет показано позже,
первые два сообщения согласовывают правила; в следующих двух — обменива-
ются открытыми значениями Диффи—Хеллмана и вспомогательными данными
(данными текущего времени, например), необходимыми для обмена; последние
два сообщения используются для идентификации обмена Диффи—Хеллмана.
*
Агрессивный режим
Агрессивный обмен — это установление агрессивного обмена ISAKMP, который со-
стоит из пересылки 3 сообщений. В первых двух сообщениях согласовываются
правила, обмениваются открытыми значениями Диффи—Хеллмана, а также пе-
редаются вспомогательные данные. Кроме того, во втором сообщении происхо-
дит идентификация второй стороны. В третьем сообщении передается идецти-
фикация инициатора и подтверждение участия в обмене.
Согласование ассоциации безопасности ограниченно в агрессивном режиме.
Например, группа, в которой выполняется обмен Диффи—Хеллмана, не может
Режимы установления идентифицированного обмена ключей 219
быть изменена. Вдобавок различные методы идентификации могут еще больше
сократить возможности согласования атрибутов. Если все эти ограничения не-
приемлемы, то нужно воспользоваться основным режимом.
Быстрый режим и режим новой группы
Быстрый режим и режим новой группы не имеют соответствия в ISAKMP. Основ-
ной, агрессивный и быстрый* режимы осуществляют согласование ассоциации
безопасности. Предложения ассоциации безопасности принимают форму данных
преобразования, помещаемых в данные предложения, которые, в свою очередь,
помещаются в данные SA.
Четыре метода, используемых в основном
и агрессивном режимах
Четыре различных режима идентификации используются в основном и агрес-
сивном режимах: цифровая подпись, два вида идентификации с шифрацией от-
крытым ключом и разделяемый секретный код. Значение SKEYID вычисляется
по-разному в разных методах идентификации и, таким образом, зависит от тако-
го метода, как показано ниже:
О Для цифровых подписей: SKEYID • prf(Ni_b | Nr_b, gAxy)
О Для шифрации открытым ключом: SKEYID - prf(HASH(Ni_b | Nr_b). CKY-I |
CKY-R)
О Для разделяемого секретного кода: SKEYID - ргТ(разделяемый_код. Ni_b | Nr_b)
В результате применения как основного, так и агрессивного режимов, получает-
ся три группы идентифицированного материала ключей:
SKEYID d - prf(SKEYID. дАХУ | CKY-I | CKY-R | 0)
SKEYID a - prfCSKEYID. SKEYID_d | gAxy | CKY-I | CKY-R | 1)
SKEYID^e - prf(SKEYID. SKEYID_a j gAxy | CKY-I | CKY-R | 2)
Для того чтобы идентифицировать обмен фазы 1, инициатор этого обмена гене-
рирует HASH-I, а получатель генерирует HASH-R. Как вы наверняка помните, хэш-
функцию очень трудно взломать, то есть невозможно с вычислительной точки
зрения определить, какие аргументы нужно передать в эту функцию для того,
чтобы получить данный результат. Поэтому хэш-функция и применяется для
идентификации соединяющихся сторон. Вычисление хэш-кодов происходит сле-
дующим образом:
HASH I - prf(SKEYID. gAxi | gAxr | CKY-I | CKY-R | SAi b | IDii b)
HASHER - prf(SKEYID. gAxr j gAx1 | CKY-R | CKY-I | SAi_b j IDirb)
Для идентификации с помощью цифровой подписи значения HASH_I и HASH_R
подписываются и подтверждаются. Для идентификации с помощью шифрации
открытым ключом или разделяемого секретного кода значения HASH_I и HASH_R
220
Глава 11. Обмен ключами
напрямую идентифицируют обмен. Все передаваемые данные идентификации
(включая номер порта, протокол, но исключая общий заголовок) применяются
при вычислении хэш-кода HASH_I и HASH R.
Примеры обмена сообщениями IKE
В этом разделе приводятся примеры обмена сообщениями IKE. В разделе 5 RFC
2409 определены действия, которые мы рассмотрим в приведенном ниже поряд-
ке. Здесь будут приведены только отдельные примеры этих операций, но в упо-
мянутом выше RFC вы можете найти значительно более подробное описание
и дополнительные примеры.
О Фаза 1: обмен идентифицирован при помощи цифровой подписи.
О Фаза 1: обмен идентифицирован при помощи шифрации с открытым ключом.
О Фаза 1: обмен идентифицирован при помощи исправленной шифрации с от-
крытым ключом. .
О Фаза 1: обмен идентифицирован при помощи разделяемого секретного кода.
О Фаза 2: быстрый режим.
О Режим новой группы.
Фаза 1: обмен идентифицирован при помощи
цифровой подписи
Как показано на рис. 11.1, информация, передаваемая во время второго обмена
данными, является данными текущего времени. Обмен идентифицируется под-
писью хэш-кода.
Инициатор Получатель
Ф HDR, SA______________________________
;_________________________HDR.SA®
@HDR, KE.Ni
__________________________________ HDR, KE, Nr®*"
® HDR*, IDII, [CERT,] SIG J_______
HDR*, IDir, [CERT,] SIG R ®
Рис. 11.1. Фаза 1: обмен идентифицирован при помощи цифровой подписи, основной режим
Примеры обмена сообщениями IKE 221
На этапах 1 и 2 обе стороны согласовывают SA IKE и договариваются о других
настройках обмена. Как и в ISAKMP, на этих этапах необходимо, чтобы обе сторо-
ны передали свои cookies в соответствующих по!лях заголовка.
На этапах 3 и 4 стороны обмениваются ключами Диффи—Хеллмана (КЕ, кото-
рый был задан на этапах . 1 и 2) и псевдослучайными значениями (N1 и Nr). Те-
перь стороны могут завершить обмен Диффи-Хеллмана и защищать сообщения,
передаваемые на этапах 5 и 6..
На этапах 5 и 6 происходит обмен зашифрованной (при помощи SKEYID e) ин-
формацией идентификации. SIG I и SIG R обозначают подписанные данные и
являются результатом применения ранее согласованного алгоритма цифровой
подписи к HASH I и HASH_R, соответственно. ID11 и ID1 г — идентификации данных.
Помещение CERT в квадратные скобки означает, что сертификат не является обя-
зательным в этом обмене. "° i! ' 1 •
На рис. 11.2 показан обмен данными в агрессивном режиме с использованием
подписей в комбинации.с ISAKMP. Обратите внимание, что в два раза уменьши-
лось количество передаваемых сообщений, по сравнению с основным режимом.
Платой за это является то, что в агрессивном режиме ограниченны возможности
согласования, поскольку инициатор должен передать значение Диффи—Хеллмана
и данные текущего времени в первом же сообщении. Таким образом, инициатор
не может предложить разные группы Диффи—Хеллмана в разных защитных обо-
лочках.
(1) HDR, SA, KE, Ni, IDii_________________________________
_____________________HDR, SA, KE, Nr, IDir, [CERT,] SIG R (2)
(3) HDR. [CERT,] SiGJ,
Рис. 11.2. Фаза 1: обмен идентифицирован при помощи цифровой подписи, агрессивный режим
Тем не менее, агрессивный режим может быть единственным способом установ-
ления SA IKE. Например, в ситуации, когда происходит соединение по коммути-
руемым линиям, адрес инициатора изначально неизвестен получателю. Кроме
того, если инициатор имеет данные о получателе, то агрессивный режим будет
более эффективным, чем основной.
В любом из этих режимов, SIG_I и SIG_R являются результатом применения ра-
нее согласованного алгоритма цифровой подписи к HASH I и HASH R, соответственно.
222
Глава 11. Обмен ключами
Фаза 1: обмен идентифицирован при помощи
шифрации с открытым ключом
Обмен идентифицируется при помощи шифрации с открытым ключом, допол-
нительная информация, передаваемая между сторонами, — это зашифрованные
данные текущего времени. Способность каждой из сторон восстановить хэш-код
(предполагая, что другая сторона дешифровала данные текущего времени) иден-
тифицирует сообщение. Эта операция требует, чтобы инициатор обмена имел
у себя открытый ключ получателя.
Если получатель имеет несколько открытых ключей, тогда часть третьего сооб-
щения передает хэш-код сертификата, используемого инициатором для шифра-
ции вспомогательной информации. Таким образом, получатель может определить,
какой закрытый ключ нужно применять при дешифрации зашифрованных дан-
ных, а, следовательно, сохраняется и конфиденциальность. Вдобавок к данным
текущего времени, идентификаторы сторон (ID11 и ID1 г) также зашифровывают-
ся с помощью открытого ключа второй стороны.
На рис. 11.3 и 11.4 показаны основной и агрессивный режимы, соответственно,
использованные в фазе 1 для идентификации обмена с открытым кдючом. HASH(l) —
это хэш-код (полученный при помощи предварительно согласованной хэш-функ-
ции) сертификата, при помощи которого инициатор шифрует данные текущего
времени и идентификаторы. В отличие от других методов идентификации, иден-
тификация с открытым ключом позволяет защищать идентификаторы в агрес-
сивном режиме.
Получатель
Инициатор
(j) HDR, SA
HDR, SA ®
(3) HDR, KE,[HASH(1)]
<IDii >PubKey_r,
I <NiJb>PubKeymr
HDR, KE ®
® HDR*, HASH J
<iDir b>PubKey i,
<Nrb>PubKeyJ
HDR*, HASH.R (§)
Рис. 11.3. Фаза 1: обмен идентифицирован при помощи шифрации с открытым ключом,
основной'режим
На этапах 2 и 3 данные идентификации (ID11 и ID1 г) и текущего времени (N1 и
Nr) шифруются при помощи открытых ключей противоположной стороны. ID11
и IDir нужны для того, чтобы другая сторона могла использовать правильный
открытый ключ в своих сообщениях.
Примеры обмена сообщениями IKE 223
Инициатор
Ф HDR, SA, [HASH(1)], КЕ
<IDIi >PubKey_r,
<Ni E>PubKey r
HDR, SA, KE @
(3) HDR, HASH J
<IDir b>PubKey I,
<Nr b>PubKeyJ, HASH Jr
Рис. 11.4. Фаза 1: обмен идентифицирован при помощи шифрации с открытым ключом,
агрессивный режим
Фаза 1: обмен идентифицирован при помощи
исправленной шифрации с открытым ключом
Идентификация при помощи шифрации с открытым ключом имеет преимуще-
ство перед идентификацией цифровой подписью, но эта операция влечет за со-
бой четыре действия с открытыми ключами, два для шифрации и два для де-
шифрации. Режим идентификации, описываемый в этом разделе, сохраняет
преимущества идентификации шифрацией с открытым ключом, но требует вдвое
меньшего количества операций с ключами.
Данные текущего времени также шифруются при помощи открытого ключа дру-
гой стороны, однако идентификаторы (и, если передаются, сертификаты) шиф-
руются при помощи согласованного симметричного алгоритма шифрации (на
основании данных SA), ключ для которого получен на основании данных теку-
щего времени.
Как и в предыдущем методе идентификации, данные HASH могут быть посланы
для идентификации сертификата в том случае, если получатель имеет несколько
сертификатов, имеющих годный к употреблению открытый ключ (то есть когда
сертификат не является только сертификатом подписи или когда в сертификате
имеются соответствующие ограничения). Если данные HASH посылаются, то они
должны быть первыми данными во втором сообщении, за которыми следуют
зашифрованные данные текущего времени. Кроме того, инициатор может (не
обязательно) отправить данные сертификата для того, чтобы получатель знал
открытый ключ, который нужно использовать для ответов. На рис. 11.5 показан
поток данных в случае использования этого способа в основном режиме (агрес-
сивный режим не показан, но его можно найти в RFC 2409).
Предназначение HASH(l) идентично описанному выше. КЕ_1 и КЕ_г — ключи сим-
метричного алгоритма шифрации, согласованного во время обмена данными SA.
Шифруются только сами данные (как в случае открытого ключа, так и симмет-
ричного алгоритма), сами заголовки данных передаются открытым текстом. Поле
длины данных должно отражать действие шифровального алгоритма.
224
Глава 11. Обмен ключами
HDR, SA@
@ HDR, [HASH(1)]
<NI b>PubKey г,
<KE_b>KeJ,
<IDii_>Ke_i,
. [<Cert-l b>Ke i
@ HDR*, HASHJ
HDR, <Nr_b>PubKeyJ, @
<KE_b>Ke_r,
<JDir_b>Ke_r,
HDR*, HASH.R (6)
Рис. 11.5. Фаза 1: обмен идентифицирован при помощи исправленной шифрации
с открытым ключом, основной режим
Фаза 1: обмен идентифицирован при помощи
разделяемого секретного кода
В случае применения идентификации с разделяемым ключом в основном режи-
ме ключ может быть определен по IP-адресу каждой из сторон, поскольку хэш-
код инициатора HASH_I должен быть посчитан до того, как инициатор начнет
обработку IDir. Агрессивный режим предусматривает использование широкого
диапазона идентификаторов разделяемого ключа. В дополнение к этому агрес-
сивный режим позволяет двум сторонам иметь множество различных разделяе-
мых ключей и при согласовании обмена сообщать, какой именно из них исполь-
зуется в данном случае.
Фаза 2: Быстрый режим
Быстрый режим не является полным обменом. После того как основной или аг-
рессивный режимы были применены для определения SA IKE, быстрый режим
может быть использован для установки SA IPSec. Сообщения в этом режиме за-
щищены SA IKE, установленной в фазе 1.
Сообщения быстрого режима идентифицируются при помощи функции prf(key,
msg). SKEYID используется для идентификации сообщения.
Информация, передаваемая в быстром режиме, защищается SA ISAKMP, то есть
шифруются все передаваемые данные, за исключением заголовка ISAKMP. В бы-
стром режиме данные HASH следуют сразу за заголовком ISAKMP, а данные SA дол-
жны идти сразу за HASH. Этот HASH идентифицирует сообщение.
Группы OAKLEY 225
Режим новой группы * - « ,
Режим новой группы не может быть использован до того, как будет установлена
SA ISAKMP. Описание новой группы следует только после завершения согласова-
ний фазы 1. На рис. 11.6 показан поток данных, происходящий в этом режиме.
Эти данные защищаются при помощи SA IKE. Это позволяет сторонам согласо-
вать частные группы и идентификатор группы (для дальнейшего использования).
Рис. 11.6. Режим новой группы
HASH(l) — это результат функции prf, где SKEYID a использован в качестве ключа,
а идентификатор сообщения из заголовка ISAKMP, сцепленного со всеми данными
предложения SA, телом и заголовком, в качестве данных; HASH(2) — это результат
функции prf, где SKEYID_a использован в качестве ключа, а идентификатор
сообщения из заголовка ISAKMP, сцепленного с данными ответа, в качестве данных.
Другими словами, хэш-коды для этого режима обмена подсчитываются
следующим образом:
HASH(l) - prf(SKEYID_a. И-ID | SA)
HASH(2) - prf(SKEYID_a. M-ID | SA)
Информационный обмен ISAKMP
Этот протокол защищает информационный обмен ISAKMP всегда, когда это воз-
можно. Как только ассоциация безопасности ISAKMP установлена (и значения
SKEYID e и SKEYID_a сгенерированы), она используется сторонами протокола IKE
для обмена друг с другом сообщениями достояния и ошибок.
Группы OAKLEY
В IKE это группа, в которой происходит согласование обмена Диффи—Хеллмана.
Определены 4 группы (значения от 1 до 4). Эти группы появились из OAKLEY,
и поэтому их называют «группы OAKLEY». Атрибутивный класс для «группы» оп-
ределяется в приложении A, RFC 2409.
226
Глава 11. Обмен ключами
Все сообщения при обмене IKE
В этом разделе описываются сообщения, которыми необходимо обменяться для
того, чтобы установить защищенный канал связи между процессами ISAKMP, сге-
нерировать материал ключей, а затем согласовать SA IPSec. На рис. 11.7 показан
формат сообщения, передаваемого между двумя сторонами во время первого
обмена информацией (в основном режиме). Вторая сторона отвечает таким же
образом, за исключением того, что она выбирает и возвращает одно предложе-
ние преобразования (атрибуты SA ISAKMP).
0 1-6 7 8 16 17 18-30 31
Заголовок ISAKMP, те поле XCHG задает основной режим, а поле следующих данных ISA_SA
0 Резервное Длина данных
Область интерпретации
Ситуация
0 Резервное Длина данных
Предложение 1 PROTOJSAKMP Размер SPI.0
ISA TRANS Резервное Длина данных
Преобразование 1 KEY_OAKLEY Резервное 2
Предпочтительные атрибуты SA
0 Резервное Длина данных
Преобразование 2 KEYOAKLEY Резервное 2
Альтернативные атрибуты S
Рис. 11.7. Первый обмен сообщениями
Формат сообщений во втором обмене информацией показан на рис. 11.8, а и б.
Разделяемые ключи SKEYID_e и SKEYID_a теперь используются для защиты и иден-
тификации всех передаваемых данных. Заметьте, что и SKEYID e, и SKEYID_a не
идентифицированы. Обмен ключами идентифицируется посредством подписан-
ного хэш-кода. Как только подпись была проверена при помощи алгоритма иден-
тификации, согласованного как часть SA ISAKMP, эти разделяемые ключи, SKEYID_e
и SKEYID_a, могут быть помечены как идентифицированные. В этом примере об-
мен данными сертификатов не происходит.
Все сообщения при обмене IKE 227
0 1-6 7 8 16 17 18-30 31
Заголовок ISAKMP, где поле XCHG задает основной режим, а поле следующих данных ISA_KE
ISA NONCE Резервное Длина данных
Открытое значение Диффи—Хеллмана (0*xi от инициатора и 0*хг от получателя) ' •>
0 Резервное Длина данных J
NI от инициатора или Nr от получателя
а. Второй обмен
0 1-6 7 8 16 17 18-30 31
Заголовок ISAKMP, ще поле XCHG задает основной режим, а поле следующих данных iSA_KE
ISASIG Резервное Длина данных
Данные идентификатора участника обмена ISAKMP
0 Резервное Длина данных
Подпись подтверждается открытым ключом, заданным данными идентификатора
б. Второй обмен (продолжение)
Рис. 11.8. Второй обмен (разделяемые ключи)
Фаза 2 с применением быстрого режима
Сообщения, формат которых показан на рис. 11.9, а и б, передаются в начале
быстрого режима согласования SA ISAKMP. В обсуждаемом варианте участники
обмена ISAKMP являются посредниками для сторон, запрашивающих идентифи-
кацию.
Содержимое поля хэш-кода описывается на рис. 11.9, а. Вторая сторона отвечает
сообщением сходного формата, содержащего только одно преобразование — пре-
образование выбранного АН. По получении сообщения инициатор может сгене-
рировать ключ на основе согласованной ассоциации безопасности и материала
ключей. Для защиты от атаки повторением получатель ожидает до тех пор, пока
не получит сообщение, показанное на рис. 11.9, б.
228
Глава 11. Обмен ключами
0 L 1-6 7 8 16 17 18-30 31
Заголовок ISAKMP, где поле XCHG задает быстрый режим, поле следующих данных ISA_HASH, а бит шифрации установлен
ISA_SA Резервное Длина данных
Хэш-код сообщения, созданный с ключом * . . . .. .
ISA_NONCE Резервное Длина данных
Область интерпретации
Ситуация
0 Резервное Длина данных
Предложение 1 PROTOJPSEC_AH Размер SPI = 4 I Количество преобразований
Размер SPI = 4
ISA_TRANS Резервное Длина данных
Преобразование 1 AHSHA Резервное 2
Другие атрибуты SA
0 Резервное Длина данных
П раибомэмвание 2 AH_MD5 Резервное 2
Другие атрибуты SA
ISAJD Резервное Длина данных
Данные текущего вримеии
ISAJD Резервное Длина данных
Идентификатор отправителя, для которого ISAKMP является клиентом
0 Резервное Длина данных
Идентификатор получателя, для которого ISAKMP является клиентом
а. Быстрый режим
0 1-6 7 6 16 17 18-30 31
Заголовок ISAKMP, где поле XCHG задает быстрый режим, поле следующих данных ISA_HASH, е бит шифрации установлен
0 Резервное Длина данных
Данные хэш-кода - II I - ч Ill - - ’ - - . —
б. Быстрый режим (продолжение)
Рис. 11.9. Первый обмен сообщениями
IPSec, NAT и IKE 229
IPSec, NAT и IKE
В предыдущих главах мы обсуждали IPSec. а в главе 9 объяснялось, как в узле
IPSec организуется поддержка IPSec и NAT в соответствии со спецификацией RFC
2709. В этой же части главы обсуждается роль IKE в таком узле.
На рис. 11.10 показано то, какие действия выполняет IKE в узле IPC-NAT. В RFC
2709 не требуется, чтобы пакеты IKE подвергались обработке NAT. IKE-ALG просто
преобразует некоторую часть данных IKE согласно правилам отображения NAT.
Рис. 11.10. Преобразование правил безопасности в IKE-ALG при помощи
отображений NAT (RFC 2709)
В быстром режиме обмен правилами с другой стороной осуществляется как ком-
бинация данных I-Dci и IDcr. Эти правила, передаваемые каждой из сторон, дол-
жны соответствовать параметрам SA каждого из участников с тем, чтобы их при-
менение было единообразным. Если такой обмен не состоялся, то предполагается,
что согласованные параметры SA быстрого режима могут быть использованы
между IP-адресами, принятыми основным режимом.
В зависимости от природы правил безопасности, принятых в том или ином мес-
те (например, прямая связь между сторонами или соединение с использованием
диапазона адресов), IKE-ALG может быть нужно запросить NAT с тем, чтобы уста-
новить привязку адресов и/или привязку транспорта для согласуемого сеанса
связи. В случае когда ALG не сможет установить необходимую привязку адресов
или транспорта, IKE-ALG не сможет преобразовать правила безопасности, что в,,
результате приведет к тому, что IKE не перейдет ко второй фазе согласований этих
правил.
После того как согласования успешно завершились, IKE передает согласованные
параметры безопасности прямо шлюзу IPC-NAT, как показано на рис. 11.10.
230
Глава 11. Обмен ключами
Необходимо, чтобы устройство NAT, обеспечивающее защиту IPSec при помощи
туннельного режима, применяло правила безопасности, основанные на отдель-
ной области адресации и второй стороне, соединяемой с первой туннелем IPSec.
Как результат, может возникнуть необходимость подвергнуть пакет различным
типам преобразований NAT, в зависимости от другой стороны. Иными словами,
IPC-NAT будет нуждаться в уникальном наборе отображений NAT для каждого скон-
фигурированного правила безопасности. IPC-NAT, совместно с обработкой IPSec,
на основе правил безопасности преобразует адреса различным образом для раз-
личных соединяющихся сторон. На рис. 9.20 и 9.21 (глава 9) показана совмест-
ная с NAT обработка IPSec в туннельном режиме.
Работа устройства IPC-NAT может отличаться от работы шлюза IPSec, не поддер-
живающего NAT, по следующим пунктам:
о В устройстве IPC-NAT правила безопасности применяются с использованием
отдельной области адресации. Обычный шлюз IPSec применяет свои правила
безопасности, основываясь на единственной области адресации.
о Наиболее важными элементами модели безопасности устройства IPC-NAT яв-
ляются отображение адресов (и другие определения параметров NAT) совместно
с правилами безопасности н атрибутами SA. Базовые элементы обычного шлюза
IPSec ограничены только правилами безопасности и атрибутами SA.
о Обычное NAT ориентировано на сеанс, разрешая преобразование только исхо-
дящих соединений. Все другие разновидности NAT являются двунаправлен-
ными. Любой вариант преобразования NAT может применяться совместно с
правилами безопасности и их применением в устройстве IPC-NAT.
Тем не менее, устройство NAT, которое может обеспечить защиту в туннелях IPSec,
может работать и как обычное NAT для тех пакетов, которые не нуждаются в IPC-
NAT. Преобразование .адресов и другие определения параметров NAT отличаются
в обычном NAT и IPC-NAT.
Примеры реализаций PKI
Entrust и VeriSign — две наиболее заметные компании, предлагающие услуги PKI.
Их подходы отличаются в том, что Entrust предлагает продукт, который покупа-
ется, устанавливается и поддерживается пользователем. VeriSign предлагает
пользователю полный комплекс услуг PKI, разработанный (в некоторой степе-
ни) сторонними фирмами. Это отличие важно для клиентов, позволяя им выби-
рать то, что им наиболее подходит. Подход Entrust иногда называют «лучшим в
своем роде» потому, что обеспечение безопасности находится под контролем
пользователя. VeriSign предлагает метод, основанный на Интернете. Каждый из
этих подходов может быть приемлемым для одних и недопустимым для других.
Подробный анализ соотношения цена-качество для Entrust и VeriSign вы може-
те найти в [МАСН98]1, цитата из которого приводится здесь:
1 [МАСН98]. Machefsky, Ira. A Total Economic Impact Analysis of Two PKI Vendors: Entrust and VeriSign, A
White Paper from Giga Information Group, One bmgrater Circle, Norwell, MA 02061.
Заключение
231
Существенная разница между этими двумя версиями управления безопасностью вы-
является снова и снова во время наших опросов. Пользователи Entrust единодуш-
ны в том, что их защита является «лучшей в своем роде» и находится под их управ-
лением. Клиенты VeriSign довольны моделью безопасности, de facto основанной на
Интернете, поскольку она создана разработчиками броузеров и VeriSign. По сути,
они верят, что только общедоступная услуга может достигнуть того всеобъемлюще-
го масштаба, который необходим для Интернета. Вот как один из них сформулиро-
вал это: «VeriSign — это провидец. Они предоставляют общедоступную услугу, и она
работает. Они являются единственной сконцентрированной на этой проблеме ком-
панией. Тем самым эта услуга должна сделать глобальный толчок». Именно эта вера
в общедоступную услугу, основанную на Интернете, в противовес подходу с полно-
стью управляемой защитой, дает им основание для того, чтобы передать управле-
ние безопасностью VeriSign.
Кажется, что именно это обстоятельство является в одинаковой степени и началь-
ной точкой, и заключением для опрошенных нами людей. Это и есть предпосылка,
на основании которой они осуществляли свое решение, которое, в свою очередь,
скорее всего, лишь отражение политики, принятой в компании. Мы полагаем, что
это смягчается тем фактом, что в этих подходах (особенно у VeriSign) имеется опре-
деленная гибкость (дополнительно о гибкости вы можете найти в разделе «Гиб-
кость»), Как нам кажется, подход пользователей VeriSign к PKI можно назвать эк-
спериментальным и выжидательным. Это заставляет их быть более склонными к
готовым решениям, а не создавать свои собственные. Клиенты Entrust, кажется,
знают, чего они хотят, что они с этим собираются делать, и более агрессивны в ре-
ализации своих решений.
Нам нужно будет подождать того момента, когда или время, или опыт внесут свои
изменения в эти полностью противоположные подходы таким образом, что можно
будет принять безоговорочно один из этих вариантов. Нужно сказать, что даже наи-
более пылкие сторонники Entrust находят положительные стороны в модели VeriSign,
пригодные для развития своей собственной PKI. Для того чтобы начать использо-
вать PKI Entrust, клиенту необходимо установить соответствующую программу. Как
это может быть осуществлено надежным образом? Один из клиентов Entrust ис-
пользует для этой цели поддерживающий SSL-сервер, сертифицированный VeriSign.
После того как клиентское приложение установлено, принимается PKI Entrust,
которое замещает PKI VeriSign.
Заключение
IKE является расширением ISAKMP, которое применяется для обмена идентифи-
цированным материалом ключей между двумя соединяющимися сторонами и
установки ассоциации безопасности, такой как ESP и АН, в DOI IPSec. IKE доста-
точно гибок и может быть использован для определения SA, отличных от IPSec.
Принятая SA зависит от конкретной области интерпретации (DOI).
ГЛАВА
Безопасность
беспроводных сетей
В этой главе рассматривается IS-41-C — протокол, применяемый в северо-
американских беспроводных сетях. Глава начинается с описания архитекту-
ры IS-41-C, за этим последует перечисление его возможностей, с акцентом на
идентификации пользователя передвижного устройства.
В этой главе для операций с беспроводным интерфейсом я использую примеры
IS-54-B, кроме тех случаев, когда указано обратное. Другие беспроводные интер-
фейсы, такие как IS-136 и IS-95, используют те же процедуры. Заметьте, что в
IS-41-C приняты следующие соглашения: сообщения, показанные заглавными
буквами, — это сообщения запросов; сообщения, показанные строчными буква-
ми, — это сообщения ответов.
Спецификация IS-41-C
Спецификация протокола IS-41-C опубликована Ассоциацией телекоммуника-
ционной промышленности (Telecommunication Industry Association — TIA). Этот
протокол позволяет взаимодействовать оборудованию, разработанному различ-
ными производителями (путем помещения IS-41-C в каждый продукт). IS-41-C
был впервые опубликован в феврале 1988 года, как вариант A (Revision А). С тех
пор был выпущен вариант В и теперь С. С каждым новым вариантом протокол
становился все более мощным и гибким. В своем текущем варианте он поддер-
живает беспроводные интерфейсы AMPS, IS-54-B, IS-136 и IS-95.
МодельIS-41-C
IS-41-C имеет топологию и модель, которая в достаточной степени сходна с GSM.
На рис. 12.1 показаны функциональные блоки IS-41-C и связывающие их
Модель IS-41-C
233
интерфейсы (базисные точки). Этот рисунок является только концептуальной
моделью, в конкретной реализации могут быть дополнительные блоки и базисные
точки. В данном случае эти дополнительные компоненты не требуются для
соответствия стандарту IS-41-C.
AC Access Control (Контроль доступа) ,
BS Base Station (Базовая станция)
CSS Cellular Subscriber Station (Станция сотового подписчика)
EIR Equipment Identity Register (Реестр идентификаторов оборудования)
HLR Home Location Register (Реестр местоположения базы)
ISDN Integrated Services Digital Network (Цифровая сеть связи с комплексными услугами)
МС Message Center (Центр сообщений)
MSC Mobile Switching Center (Передвижной коммутирующий центр)
PSTN Public Switching Telephone Network (Публичная коммутируемая телефонная сеть)
SME Short Message Entity (Блок коротких сообщений)
VLR Visitor Location Register (Реестр местоположения посетителя)
Рис. 12.1. Блоки IS-41-C и базовые точки
Термины на рисунке поясняются внизу рисунка. Базовые точки, обозначенные
как Um, А, Вит. д., используются для обозначения интерфейсов и процедур
(протоколов) между блоками IS-41-C, такими как передвижные коммутирующие
центры (Mobile Switching Center — MSC). В этой главе мы сфокусируемся на
интерфейсах В, С, Е, Н и Um. Интерфейс А не определен в IS-41-C.
234 Глава 12. Безопасность беспроводных сетей
Пять операций
безопасности/конфиденциальности
В следующих разделах этой главы будет рассказано об операциях, используемых
IS-41-C для обеспечения идентификации и конфиденциальности. Эти операции
преследуют две основные.цели: во-первых, удостоверить сеть в том, что иденти-
фикаторы пользователя (и его счет) не используются кем-то другим (что может
привести к неправильному счету); во-вторых, гарантировать, что разговоры
пользователя или передаваемые им данные не перехватываются сторонними
лицами.
Для того чтобы удостовериться в подлинности пользователя, в IS-41-C опреде-
лены пять процедур идентификации передвижного устройства. Помните, что IS-
41-С применяется во всех беспроводных интерфейсах в Северной Америке, а опе-
рации идентификации в целом одинаковы для всех этих интерфейсов.
Несущественные отличия, конечно, существуют, но они столь незначительны, что
нет нужды их отдельно обсуждать.
Операции идентификации влекут за собой обмен информацией между сетью и
передвижным устройством с тем, чтобы удостовериться, что пользователь этого
устройства тот, за кого себя выдает. Для этого применяется разделяемый секрет-
ный ключ, называемый SSD (Shared Secret Data — разделяемые секретные дан-
ные), который известен только сети и передвижному устройству. Успешная иден-
тификация означает, что сеть и передвижное устройство: во-первых, имеют
одинаковые копии SSD; во-вторых, применяют SSD для получения других значе-
ний, которые используются для проверки (идентификации) передвижного уст-
ройства и сети, а также для шифрации голоса и данных.
В этой части главы будут описаны пять операций (перечисляемых ниже) обес-
печения идентификации и конфиденциальности, используемых в IS-41-C. Для
каждой операции дается: объяснение используемых параметров, примеры опе-
раций в беспроводных интерфейсах, примеры операций в сети.
О Процедуры проверки регистрации передвижного устройства.
О Процедуры вызов/ответ.
О Проверка местоположения передвижного устройства.
О Идентификация звонка на передвижное устройство.
О Обновление разделяемых секретных данных (SSD).
Параметры идентификации
Перед тем как начать обсуждение этих пяти операций, давайте рассмотрим па-
раметры, используемые при идентификации (см. рис. 12.2). Упомянутые ранее
SSD являются 128-битным значением, которое хранится в передвижном устрой-
стве и сети. Это значение разделено на две части: SSD-А и SSD-В, как показано на
Пять операций безопасности/конфиденциальности 235
рис. 12.1, a. SSD-A применяется в процедурах идентификации, a SSD-B — для шиф-
рации голоса и некоторых сообщений. В дальнейшем вы увидите, как осуществ-
ляется генерация SSD и управление ими.
Случайное значение вызова (RAND), показанное на рис. 12.1, б — это 32-битное
случайное число, которое периодически посылается (всем станциям) сетью в виде
двух 16-битных пар: RAND1_A и RAND1J3. RANDC — это 8-битное число, используемое
для подтверждения последнего полученного передвижным устройством RAND, это
наиболее важные 8 бит RAND. *
SSD-A
SSD-B
Содержание
64 64 Биты
а. Разделяемые секретные данные
RAND
32
RANDC
8
б. Случайное значение вызова (RAND) и RANDC
ESN
32
е. Электронный серийный номер (ESN)
MINI
24
а. Электронный серийный номер (ESN)
A-KEY
64
6. А-кеу
RANDSSD
56
в. Случайная переменная разделяемых секретных данных (RANDSSD)
AUTHR AUTHU
18 18
ж. Вызов идентификации (AUTHR & AUTHU)
Рис. 12.2. Операции и параметры защиты данных
Электронный серийный номер (Electronic Serial Number — ESN), показанный на
рис. 12.2, в — это идентификатор телефонной трубки передвижного устройства.
Идентификационный номер передвижного устройства (Mobile Identification
236 Глава 12. Безопасность беспроводных сетей
Number — MIN), рис. 12.3, г — это 34-битное представление 10-значного теле-
фонного номера передвижного устройства.
A-key — это секретное 64-битное значение, хранящееся только в передвижном
устройстве и центре идентификации (Authentication Center — АС), как показано
на рис. 12.2, д. Если АС не существует, то этот ключ хранится в HLR пользователя.
Случайная переменная разделяемых секретных данных (Shared Secret Data Random
Variable — RANDSSD), показанная на рис. 12.2, e, — это 56-битное число, генери-
руемое базовой системой передвижного устройства. Ответ идентификации на уни-
кальный вызов (AUTHU & AUTHU) — это 18-битное значение, вычисляемое алгорит-
мом идентификации (рис. 12.2, ж).
Процедуры идентификации регистрации
передвижного устройства
Параметры
Идентификация регистрации — это первый тип операций идентификации, под-
держиваемый IS-41-C. Базовая идея, лежащая в основе идентификации регист-
рации, показана на рис. 12.3. И сеть, и телефон выполняют алгоритм сотовой
идентификации и шифрации речи (Cellular Identification and Voice Encryption —
CAVE) для того, чтобы получить AUTHU*. В качестве входных данных алгоритма
CAVE передвижное устройство и сеть используют RAND, ESN, MINI и SSD-A. MINI — это
часть Nxx-xxxx телефонного номера.
AUTHR Вызов идентификации (ответ)
CAVE Сотовая идентификация и шифрация речи
ESN Электронный серийный номер
MIN Идентификационный номер передвижного устройства
RAND Случайное значение
SSD Разделяемые секретные данные
Рис. 12.3. Вычисление AUTHU длй вызова регистрации
* CAVE не определяется в IS-41-C - его можно найти в других спецификациях TIA.
Процедуры идентификации регистрации передвижного устройства 237
В беспроводном интерфейсе
Операции регистрации в беспроводном интерфейсе продолжаются в событии 1,
рис. 12.4, путем отправки сетью сообщения Директива Идентификации, в кото-
ром указывается, что передвижное устройство отправило сети вычисленный AUTHU.
В событии 2 передвижное устройство выполняет алгоритм CAVE, как показано на
предыдущем рисунке, и отправляет в сеть AUTHU и другие параметры, как показа-
но в событии 3. Значение подсчета (COUNT s-p будет объяснено поЗже) и RANDC
также отправляются в сеть. RANDC используется для подтверждения последнего
полученного RAND. Эта информация пересылается (для IS-54-B) в сообщении
команды автономной регистрации RECC.
В событии 4 процесс регистрации передается в центр идентификации. После
завершения этого процесса передвижное устройство получает его результат (со-
бытие 5). Предназначение этих процедур — сравнить AUTHU, вычисленный внут-
ри сети, с AUTHU, полученным от передвижного устройства.
Передвижное
Идентификации
] J3) AUTHR, RANDC,
! COUNTs-p, ESN,
' MINI
Операции j
IS-41-C i ©Результаты
©Выполнить
CAVE
AUTHR Вызов идентификации (ответ)
CAVE Сотовая идентификация и шифрация речи
ESN Электронный серийный номер
MIN Идентификационный номер передвижного устройства
RANDC Случайное значение (часть RAND)
Рис. 12.4. Идентификация регистрации передвижного устройства в беспроводном интерфейсе
В сети
На рис. 12.5 показаны операции идентификации регистрации, выполняемые в сети.
Базовая станция передает параметры передвижного устройства в обслуживаю-
щий MVC, который отправляет в VLR сообщение AUTHUEQ (Authorization Request —
запрос авторизации) протокола IS-41-C для того, чтобы инициировать операцию
238 Глава 12. Безопасность беспроводных сетей
запроса идентификации (событие 1). Эта информация передается в HLR пере-
движного устройства (событие 2), а затем в центр идентификации (АС, событие
3). АС сравнивает полученное значение RANDC (и, что необязательно, COUNT s-p) с
хранящимися в нем значениями, связанными с переданными MIN1/ESN. Если срав-
ниваемые величины совпали, АС выполняет алгоритм CAVE, используя свое зна-
чение SSD-A, а также других параметров, показанные на рис. 12.3. Результатом
вычислений будет AUTHU, который сравнивается с AUTHU, вычисленный передвиж-
ным устройством. Результат сравнения возвращается в HLR, MSC/VLR в сооб-
щении AUTHUEQ, как показано на рис. 12.5 в событиях 4 — 6.
Обслуживающая система
| AUTHREQ 2.
^AUTHREQ ------------------
4. authreq
15. authreq
AUTHREQ 1
6. authreq
Рис. 12.5. Выполняемые в сети операции идентификации регистрации
Значение подсчета COUNT s-p, упомянутое ранее, предоставляется передвижным
устройством и сопоставляется с переменной подсчета в АС. Если они равны и AUTHU
совпадают, АС принимает идентификацию.
Возможности шифрации. АС может вернуть передвижному устройству два дру-
гих значения. Ключ шифрации сигнальных сообщений (Signaling Message
Encryption Key — SMEKEY) используется для шифрации сообщений, а шаблон
конфиденциальности разговора (Voice Privacy Mask — VP-MASK) — для шиф-
рации речи. Эти возможности не являются обязательными в IS-41-C и беспро-
водном интерфейсе, поддерживаемом IS-41-C.
Процедуры уникального вызова/ответа
Параметры
Уникальный вызов является вторым типом идентификации, поддерживаемой 1S-
41-С. Другой параметр вычисляется для этойоперации. Он отличается от иден-
тификации регистрации передвижного устройства, описанного выше, тем, что:
Процедуры уникального вызова/ответа 239
во-первых, сеть первой (а не передвижное устройство) выполняет вычисления
по алгоритму CAVE и посылает вызов; во-вторых, если идентификация регистра-
ции передвижного устройства не удалась, то эта операция может быть вызвана;
в-третьих, значение RAND, используемое при идентификации регистрации пере-
движного устройства, посылается всем передвижным устройствам в соте и пери-
одически обновляется сетью. В отличие от этого, значение, используемое в уни-
кальном вызове, RANDU, является 24-битным шаблоном, созданным для
однократного уникального вызова, посылаемого конкретному передвижному ус-
тройству.
Сеть генерирует AUTHU, как показано на рис. 12.6. Она использует RANDU и другие
параметры, показанные на рисунке, для вычисления AUTHU. Как будет объяснено
далее, это значение отправляется передвижному устройству в качестве уникаль-
ного вызова.
*8 самых младших бит MIN2
AUTHR Уникальный вызов идентификации
CAVE Сотовая идентификация и шифрация речи
ESN Электронный серийный номер
M1N Идентификационный номер лередаижного устройства
RAND Случайное значение
SSD Разделяемые секретные данные
Рис. 12.6. Вычисление AUTHU для уникального вызова
В беспроводном интерфейсе
На рис. 12.7 показаны операции уникальных процедур вызова/ответа в беспро-
водном интерфейсе. Этот рисунок сходен с рис. 12.4, иллюстрирующим описан-
ную ранее идентификацию регистрации передвижного устройства. Отличия при-
ведены в тексте, относящемся к предыдущему рисунку.
240 Глава 12. Безопасность беспроводных сетей
В событии 6 MSC сети извещает АС о том, что директива была принята, но не о
том, что идентификация была завершена. Другими словами, событие'6 является
подтверждением операций АС, приведших к событию 1. Эти операции показаны
на рис. 12.8.
(J) Сгенерировать RANDU
и выполнить CAVE
для получения AUTHU
Передвижное
устройство I
(2) Команда уникального
вызова (RANDU)
Подтверждение (4)
Операции (5)
> команды .уникального
ызова (AUTHU)
(3) Выполнить CAVE
для полученного
RANDU для
получения AUTHU
IS-41-C
® Результаты
AUTHU Идентификация уникального вызова
CAVE Сотовая идентификация и шифрация речи
ESN Электронный серийный номер
MIN Идентификационный номер передвижного устройства
Рис. 12.7. Идентификация регистрации передвижного устройства в беспроводном интерфейсе
В сети
Рисунок 12.8 изображает операции, выполняемые в сети при выполнении про-
цедур уникального вызова/ответа. Эти операции сходны с операциями, выпол-
няемыми в сети, при идентификации регистрации передвижного устройства, опи-
санной ранее. Этот пример показывает, что инициатором этой операции является
АС. Инициатором также может быть VLR, если VLR и АС имеют у себя разделя-
емые секретные данные (SSD).
В этой операции (инициируемой АС) используются следующие параметры: MIN
обслуживаемого передвижного устройства; ESN обслуживаемого передвижного
устройства; номер RANDU, генерируемого для вычисления AUTHU; AUTHU, которое
ожидается от передвижного устройства в ответ на этот вызов. Эти параметры
передаются HLR, а затем в VLR в событиях 1 и 2. VLR добавляет в сообщение
Процедуры уникального выэова/ответа 241
идентификатор местоположения (location ID - LOCID), если он доступен, азатем
пересылает это сообщение в MSC (событие 3).
В событиях 4, 5 и 6 пустое сообщение authdi г возвращается для индикации Того,
что директива была получена. Эти операции показаны на рис. 12.7 как событие 5.
Это пустое сообщение authdi г также посылается в том случае, если в данный
момент MSC не может инициировать уникальный вызов к передвижному уст-
ройству.
Обслуживающая система
АС
HLR
VLR
MSC
(j) AUTHDIR
(?) AUTHDIR
authdlr(§)f
authdjr (5)
(3) AUTHDIR
authdlr @
а. Немедленный ответ
Обслуживающая система
б. Ответ с задержкой
Рис. 12.8. Выполняемые в сети операции уникального вызова/ответа
ВIS-41-C не объясняется, как происходит последующая передача сообщения. Это
должно означать, что MSC действительно возвращает сообщение authdi г поз-
же с успехом или неудачей идентификации.
242 Глава 12. Безопасность беспроводных сетей
Идентификация звонка от передвижного
устройства
Параметры
Этот третий вид идентификации выполняется, когда передвижное устройство
выполняет звонок. Для этой операции передвижное устройство генерирует AUTHU,
как и для процедуры идентификации регистрации, описанной ранее, но входные
данные CAVE немного отличаются, что и показано на рис. 12.9. Вместо значения
MINI используются последние шесть цифр набираемого номера. Передвижное
устройство Посылает AUTHU вместе с RANDC и COUNT s-p в сеть, что показано на
рис. 12.10.
AUTHR Вызов идентификации
CAVE Сотовая идентификация и шифрация речи
ESN Электронный серийный номер
RAND Случайное значение
8SD Разделяемые секретные данные
Рис. *2.9. Вычисление AUTHU в случае звонка с передвижного устройства
В беспроводном интерфейсе
Как только что было объяснено, когда передвижное устройство осуществляет
звонок, оно должно сгенерировать AUTHU с помощью CAVE, входными параметрами
которого служат RAND, ESN, последние шесть цифр набираемого номера и SSD-A.
Эта информация посылается сети в слове идентификации С сообщения проис-
хождения RECC в случае IS-54-B. Рис. 12.10 иллюстрирует эту операцию.
Идентификация звонка от передвижного устройства
243
Операции
IS-41-C
Передвижное
^(2) Идентификация
* (AUTHR, RANDC,
COUNTs-p, MINI,
ESN) ♦
©Результаты
Использовать RAND
и вычислить CAVE
для получения AUTHU
AUTHR Идентификация уникального вызова
CAVE Сотовая идентификация и шифрация речи
RANDC 8 самых старших битов RAND
Рис. 12.10. Идентификация звонящего передвижного устройства в беспроводном интерфейсе
Сеть использует полученное AUTHU для сравнения со своим собственным значе-
нием, используя для его вычисления те же входные данные, что передвижное
устройство. Если обе величины совпадают, то тогда начинается процедура выде-
ления канала.
В сети
MSC получает сообщение идентификации от передвижного устройства. Его за-
дача — сравнить полученное значение RANDC (и, что необязательно, значение
подсчета) с внутренним значением, соответствующим полученному MIN1/ESN.
Сеть, кроме того, вычисляет AUTHU, используя в качестве входных данных те же
значения, что были описаны выше, и сравнивает результат с AUTHU, переданный с
передвижного устройства. Если они совпадают, передвижное устройство полу-
чает ресурсы, необходимые для настройки звонка, а также и для собственно со-
вершения звонка.
На рис. 12.11 показаны операции в сети для успешной идентификации в случае,
когда SSD не разделяются. То есть тогда, когда передвижное устройство соверша-
ет звонок через обслуживающую систему, которая не разделяет SSD с АС.
Обслуживающая MSC посылает сообщение AUTHUEQ в VLR, которое имеет AUTHU
и идентификатор вызываемой стороны (набранный номер). В событиях 1, 2 и 3
эта информация пересылается в АС, который определяет передвижное устрой-
ство и посылает ответное сообщение AUTHUEQ обратно к HLR, VLR и MSC. Это
сообщение может также содержать частную маску длинного кода CDMA (если
используемый беспроводной интерфейс — CDMA). Кроме того, здесь может быть
передан SMEKEY и VP-MASK, описанные ранее в этой главе. Сообщения AUTHUEQ
показаны в событиях 4, 5 и 6.
244 Глава 12. Безопасность беспроводных сетей
Обслуживающая система
^AUTHREQ® ^AUTHREQ @ AUTHREQ®
(б) authreq
® authreq *
® authreq
Рис. 12.11. Идентификация в сети звонящего передвижного устройства
Идентификация звонка на передвижное
устройство
Параметры
AUTHR Ключ для звонка к передвижному устройству
CAVE Сотовая идентификация и шифрация речи
ESN Электронный серийный номер
RAND Случайное значение
SSD Разделяемые секретные данные
Рис. 12.12. Вычисление AUTHU в случае звонка к передвижному устройству
Идентификация звонка к передвижному устройству — это четвертый тип иден-
тификации. Он сходен с другими операциями_уже описанными в этой главе, но
также имеет и несколько отличий. Во-первых, как показано на рис. 12.12, вычис-
Идентификация звонка на передвижное устройство 245
ление AUTHU в случае звонка на передвижное устройство отличается от подобного
вычисления в случае звонка от передвижного устройства: вместо набираемого
номера используется MINI. В остальном все выполняется точно так же.
В беспроводном интерфейсе
Как изображено на рис. 12.13, в случае звонка на передвижное устройство это
устройство получает сообщение. В системе IS-54-B это сообщение пересылается
в виде системного параметра служебного сообщения. Передвижное устройство
выполняет алгоритм CAVE и вычисляет AUTHU, которое, вместе с RANDC и COUNT s-p,
пересылается в сеть в слове идентификации С сообщения ответа RECC (в случае
IS-54-B).
Сеть получает эту информацию и сравнивает посланные значения RANDC (и, воз-
можно COUNT,s-p) с хранящимися в сети значениями, определяемыми числами
MINI и ESN, переданными в этом же сообщении. Если значения AUTHU равны, то
передвижное устройство получает необходимые ресурсы, как для получения звон-
ка, так и для собственно соединения.
Передвижное
Идентификация (3)
(AUTHR, RANDC,
COUNTs-p, MINI,
ESN)
(S) Результаты
Операции
IS-41-C
Использовать RAND
и вычислить CAVE
для получения AUTHU
Рис. 12.13. Идентификация при звонке к передвижному устройству в беспроводном интерфейсе
В сети
Поток сообщений в IS-41-C в случае звонка на передвижное устройство иденти-
чен потоку при звонке от передвижного устройства, за исключением того (как
уже обсуждалось ранее), что CAVE для вычисления "'значения AUTHU использует
246 Глава 12. Безопасность беспроводных сетей
другие входные параметры. Рис. 12.14 показывает поток сообщения при выпол-
нении этих операций.
Обслуживающая система
! *. ' ^AUTHREQ @
AUTHREQ (3)|-<т—--------**
• _ ।
[ ф authreq ;
I **!© authreq
^AUTHREQ Ф
(§) authreq
Рис. 12.14. Идентификация в сети при звонке к передвижному устройству
Обновление разделяемых секретных
данных (SSD)
Параметры
Обновление SSD — это пятая основная операция защиты/конфиденциальности,
определенная в IS-41-C. SSD генерируются на основании ключа, хранящегося в
телефоне и в АС. Этот ключ называется A-key. SSD создаются при помощи A-key
по команде сети. Этот подход в какой-то мере сходен с мерами безопасности,
применяемыми в GSM, за исключением того, что в североамериканских систе-
мах не определено использование SIM-карт (Subscriber Interface Module — мо-
дуль интерфейса подписчика). АС генерирует новые SSD путем выполнения ал-
горитма CAVE, входными параметрами которого являются А-key, ESN, 56-битное RAND
(называемое RANDSSD), как показано на рис. 12.15, а.
Другое значение, называемое AUTHBS, используется в процедурах обновления SSD.
Оно генерируется алгоритмом CAVE, входными параметрами которого являются
RANDBS и SSD-A_NEW. Последнее значения получается в результате вычислений, по-
казанных на рис. 12.15, а, которое затем используется как входные данные алго-
ритма CAVE, как показано на рис. 12.15, б.
Обновление разделяемых секретных данных (SSD) 247
а. Вычисление разделяемых секретных данных (SSD)
б. Вычисление AUTHBS
Рис. 12.15. Вычисления SSD
В беспроводном интерфейсе и в сети
На рис. 12.16 показано, как обновляются значения SSD. Как показано в событии 1,
когда сеть создает новые SSD, она посылает сообщение передвижному устройству
с указанием обновить SSD при помощи RANDSSD. В свою очередь передвижное ус-
тройство генерирует новые SSD на основе A-key, ESN и RANDSSD. После этого,
передвижное устройство посылает сети вызов, используя случайное число, на-
зываемое RANDBS, — событие 2.
Передвижное устройство снова выполняет алгоритм CAVE и, используя в качестве
параметров RANDBS и новые SSD-А, генерирует 18-битное значение AUTHBS. Центр
идентификации выполняет такие же действия у себя. По завершению этих вы-
числений сеть отправляет в качестве ответа значение AUTHBS, событие 3. Если
248 Глава 12. Безопасность беспроводных сетей
эти два значения AUTHBS совпадают, то телефон сохраняет новое значение SSD и по-
сылает подтверждение сети, как показано в событии 4.
Передвижное
или неудача)
Рис. 12.16. Операции обновления разделяемых секретных данных (SSD)
Некоторые могут поинтересоваться: «Почему столько операций выполняется
только для того, чтобы обновить какие-то параметры защиты?» Ответом являет-
ся то, что эти процедуры позволяют сети проверить передвижное устройство,
а также передвижному устройству проверить сеть. В конце концов, команда об-
новления SSD (событие 1) может прийти и от чужой сети. Поэтому передвиж-
Заключение
249
ное устройство проверяет сеть путем посылки сообщения вызова базовой стан-
ции в событии 2. Значение RANDBS, переданное передвижным устройством, дол-
жно использоваться сетью для вычисления AUTHBS совместно с SSD-A_NEW, который
и посылается передвижному устройству в событии 3. Передвижное устройство
сравнивает полученное значение AUTHBS с вычисленным у себя значением для того,
чтобы определить, является ли данная сеть своей.
Заключение
IS-41-C использует информацию из беспроводного интерфейса или обычной
телефонной сети для управления сетевой частью звонка сотового телефона. Этот
протокол обеспечивает как конфиденциальность, так и идентификацию, хотя
поставщики услуг сети могут и не использовать эти методы безопасности.
j ГЛАВА
Дополнение к этой
книге
Как вы, скорее всего, догадались после прочтения этой книги, безопасность в
Интернете — необъятная тема. Как я уже говорил в предисловии, одной из
целей этой книги являлось введение вас в сам обсуждаемый предмет — безопас-
ность в Интернете и протоколы, используемые при обеспечении такой безопас-
ности. Одной из самых сложных задач, стоявших передо мной, был выбор того,
что нужно, а что не нужно включать в эту книгу.
Мы только прикоснулись к данному предмету, поскольку огромное количество
материала написано о безопасности в Интернете.
Предназначение этой серии книг — ознакомить вас с основными принципами,
понятиями и идеями обсуждаемого предмета и помочь вам в поиске дополни-
тельной информации, если вы решите ознакомиться с этим предметом поближе.
Я рекомендую вам в целях более полного изучения проблемы обеспечения за-
щиты данных в Интернете посетить следующие сайты:
О Общее обсуждение: ipsec@lists.tislabs.com
О Подписка: ipsec-request@lists.tislabs.com
О FTP-архивы: ftp://ftp.tis.com/pub/lists/ipsec или ftp://ftp.ans.com/pub/archive/
ipsec
Как вы заметили, я рекомендую вам сконцентрироваться на IPSec. Я делаю это
потому, что важность этой «оболочки протоколов» осознается повсеместно. Тем
не менее, приведенные внизу ссылки помогут вам найти и спецификации, не от-
носящиеся к IPSec.
В этой книге я цитировал многие книги и документы, библиографию которых
вы можете найти в конце этой книги. А здесь я бы хотел обратить ваше внима-
ние на четыре книги, которые я очень рекомендую почитать:
О Simon Sigh, The Code Book
О Michael Smith, Station X
Рабочие документы 251
О William Stallings, Cryptography and Network Security
О Naganand Dorawamy and Dan Harkins, IPSec. The new security standard for the
Internet, Intranets, and Virtual Private Networks
Спецификации безопасности в Интернете (черновики) являются рабочими до-
кументами, некоторые из которых довольно часто меняются. Тем не менее, спи-
сок рабочих документов и RFC, приведенный ниже, даст вам необходимые ссылки,
которые позволят вам поднять ваше понимание безопасности данных на новый
уровень.
Я желаю вам удачи (и упорства), поскольку все эти документы дают в совокуп-
ности многие сотни страниц текста.
Этот список взят с web-страницы IPSec (вы можете ввести слово IPSec на страни-
це поиска в Интернете). А еще проще получить эти документы, еслй пойти по
адресу http://www.ietf.org и перейти по ссылкам в соответствии с приведенными
там указаниями.
Рабочие документы
The ESP Triple DES Transform
ESP with Cipher Block Chaining (CBC)
The ESP DES-XEX3-CBC Transform
The ISAKMP Configuration Method
The Use of HMAC- RIPEMD-160-96 within ESP and AH
A GSS-API Authentication Method for IKE
DHCP Configuration of IPSEC Tunnel Mode
Extended Authentication Within ISAKMP/Oakley (XAUTH)
A Hybrid Authentication Mode for IKE
A Framework for Group Key Management for Multicast Security
A PKIX Profile for IKE
Security Policy Specification Language
Intra-Domain Group Key Management Protocol
Security Policy System
IPSec Monitoring MIB
IPSec DOI Textual Conventions MIB
Policy Framework for IP Security
IPSec Interactions with ECN
ISAKMP & IKE Extensions Methods
IPSec Policy Schema
The Internet Key Exchange (IKE)
252
Глава 13. Дополнение к этой книге
The ESP SKIPJACK-CBC Cipher Algorithm With Implicit IV
Additional ECC Groups For IKE
ISAKMP DOI-Independent Monitoring MIB
Content Requirements for ISAKMP Notify Messages
Security Policy Protocol
IKE Base Mode
IKE Monitoring MIB
IPSec Flow Monitoring MIB
Fixing IKE Phase 1 Authentication HASH
RFC
IP Authentication using Keyed MD5 (RFS 1828)
The ESP DES-CBC Transform (RFC 1829)
HMAC: Keyed-Hashing for Message Authentication (RFC 2104)
MD5-HMAC IP Authentication with Replay Prevention (RFC 2085)
Security Architecture for the Internet Protocol (RFC 2401)
The NULL Encryption Algorithm and Its Use With IPSec (RFC 2410)
IP Security Document Roadmap (RFC 2411)
IP Authentication Header (RFC 2402)
The OAKLEY Key Determination Protocol (RFC 2412)
The ESP CBC-Mode Cipher Algorithms (2451)
The Use of MD5-HMAC-96 within ESP and AH (RFC 2403)
The Use of HMAC-SHA-1-96 within ESP and AH (RFC 2404)
The ESP DES-CBC Cipher Algorithm With Explicit IV (RFC 2405)
IP Encapsulating Security Payload (ESP) (RFC 2406)
The Internet IP Security Domain of Interpretation for ISAKMP (RFC 2407)
Internet Security Association and Key Management Protocol (ISAKMP) (RFC 2408)
The Internet Key Exchange (IKE) (RFC 2409)
ПРИЛОЖЕНИЕ
Исходные коды наиболее важных
функций защиты
Это приложение содержит примеры исходного кода, в котором реализованы
наиболее важные алгоритмы функций защиты данных, используемых в
протоколах безопасности Интернета. Описание этих алгоритмов приводится в
соответствующих главах этой книги. Тем не менее, было бы очень полезно прочитать
RFC, в которых приведен этот код, поскольку у авторов этих RFC обычно имеются
дополнительные комментарии к своему коду, а также другие возможные реализации
этих функций, что выходит за рамки этой книги.
Следующие примеры приведены в этом приложении:
О MD5, исправленный алгоритм
О MD5, шаг 4
О НМАС, идентификация сообщения при помощи хэширования
О Создание и извлечение зашифрованного текста в DESE-bis
Пожалуйста, ознакомьтесь с уведомлением об авторских правах на RFC,
приведенным в предисловии этой книги. Кроме того, в отношении RFC о MD5 верно
следующее:
© 1991-1992 Компания RSA Data Security Inc. Все права защищены.
Право на копирование и использование данной программы разрешается при усло-
вии, что она будет обозначена как «RSA Data Security Inc. MD5 Message-Digest
Algorithm» во всех материалах, в которых упоминается или которые ссылаются на
эту программу или эту функцию. Кроме того, разрешается модифицировать и пользо-
ваться модифицированными программами, основанными на данной, если эти моди-
фицированные программы обозначены как «derived from the RSA Data Security Inc.
MD5 Message-Digest Algorithm» во всех материалах, в которых упоминается или ко-
торые ссылаются на эту модифицированную программу или эту функцию.
254 Приложение А. Исходные коды наиболее важных функций защиты
RSA Data Security Inc. не утверждает ни пригодность к продаже данной программы, ни
ее пригодность для той или иной цели. Она предоставляется «как есть» без гаран-
тий какого-либо рода.
Это примечание должно быть помещено во все копии всех частей документации и/
или программы.
Исправленный алгоритм MD5 (RFC 1321,
Appendix А, автор Рон Ривест)
Листинг А.1. globaLh*
/* GLOBAL.Н - RSAREF типы и константы
*/
/* PROTOTYPES должны быть 1 только в тон случае, если коипилятор поддерживает прототипы
аргументов функций.
По умалчанию PROTOTYPES устанавливаются в 0. если это не было уже сделано с помощью фла-
гов компилятора.
*/
#ifndef PROTOTYPES
tfdefine PROTOTYPES О
#endif
/* POINTER - указатель общего назначения */
typedef unsigned char ‘POINTER:
/* UINT2 - двухбайтное слово */
typedef unsigned Short int UINT2:
/* UINT4 - четырехбайтное слово */
typedef unsigned long int UINT4;
/* PROTO_LIST зависит от значения PROTOTYPES, оперделенного выше.
PROTO_LIST, в случае использования PROTOTYPES, возвращает список.
а в противном случае - пустой список.
*/
#if PROTOTYPES
^define PROTO_LIST(liSt) list
#el se
#define PR0T0_LIST(11St) ()
#endif
Листинг A.2. md5.h
/* MD5.H - файл заголовка MD5C.C
•i*/
1 Все исходные тексты можно найти на сайте издательства «Питер» www.piter.com
Исправленный алгоритм MD5 (RFC 1321, Appendix А, автор Рон Ривесг) 255
/* Авторские права® 1991-1992. RSA Data Security. Inc.
Создано в 1991. Все права защищены.
Лицензия на копирование и использование этого програииного обеспечения дается при усло-
вии. что оно будет упомянуто как «RSA Data Security. Inc. MD5 Message-Digest Algorithm»
во всех материалах, в которых упоминается эта программа или какая-то функция оной.
Кроне того, лицензия дается и на модернизацию с тем условием, что
в таких разработках будет сказано «derived from the RSA Data
Security. Inc. MD5 Message-Digest AJgorithm» (сделано на основе RSA Data Security. Inc.
MD5 Message-Digest Algorithm) во всех материалах, касающихся этой модернизации.
RSA Data Security. Inc. не делает никаких оценок годности этой
программы к продаже или использованию в каких-либо определенных целях.
Код предоставляется «как есть» без каких-либо гарантий.
Это предупреждение должно находиться во всех копиях любой части этой
документации и/или кода.
*/
/* Контекст MD5. */
typedef struct {
UINT4 state[4]: /* состояние (ABCD) */
UINT4 count[2]; /* количество бит. по модулю 2А64 (сначала Isb) */
unsigned char buffer[64]; /* входной буфер*/
} MD5_CTX:
void MD5Init PROTO_LIST ((MD5_CTX *)):
void MD5Update PROTO_LIST
((MD5_CTX *. unsigned char *. unsigned int)):
void MD5F1nal PR0T0_LIST ((unsigned char [16]. MD5_CTX *));
Листинг A.3.md5c.c
/* MD5C.C - RSA Data Security. Inc.. MD5 message-digest algorithin
*/
/* Авторские права® 1991-1992. RSA Data Security. Inc.
Создано в 1991. Все права защищены.
Лицензия на копирование и использование этого программного обеспечения дается при усло-
вии. что оно будет упомянуто как «RSA Data Security. Inc. MD5 Message-Digest Algorithm»
во всех материалах, в которых упоминается эта программа или какая-то функция оной.
Кроме того, лицензия дается и на модернизацию с тем условием, что
в таких разработках будет сказано «derived from the RSA Data
Security. Inc. MD5 Message-Digest Algorithm» (сделано на основе RSA Data Security. Inc.
MD5 Message-Digest Algorithm) во всех материалах, касающихся этой модернизации.
RSA Data Security. Inc. не делает никаких оценок годности этой
программы к продаже или использованию в каких-либо определенных целях.
Код предоставляется «как есть» без каких-либо гарантий.
Это предупреждение должно находиться во всех копиях любой части этой
документации и/или кода.
*/
#include «global.h»
#include «md5.h»
продолжение
256 Приложение А. Исходные коды наиболее важных функций защиты
Листинг А.З (продолжение)
/* Константы функции MD5Transform.
*/
tfdefine Sil 7
#define S12 12
#define S13 17
#define S14 22
fldefine S21 5
#define S22 9
#define S23 14
#define S24 20
fldefine S31 4
tfdefine S32 11
#define S33 16
#define S34 23
#define S41 6
#define S42 10
#define S43 15
#define S44 21
static void MD5Transform PROTO_LIST ((UINT4 [4], unsigned char [64]));
static void Encode PROTO_LIST ((unsigned char *. UINT4 *. unsigned int));
static void Decode PROTO_LIST ((UINT4 *. unsigned char *. unsigned int)):
static void MD5jnemcpy PROTO_LIST ((POINTER. POINTER, unsigned int));
static void MD5_memset PROTOJ.IST ((POINTER, int. unsigned int));
static unsigned char PADDING[64] - {
0x80. 0. 0, 0. 0. 0. 0. 0 0. 0. 0, 0. 0, 0. 0. 0. 0. 0. 0. 0. 0, 0. 0. 0. 0.
0. 0. 0. 0. 0, 0. 0. 0. 0. 0. 0, 0. 0. 0. 0. 0. 0. 0. 0, o'. 0. 0. 0. 0. 0. 0.
0. 0. 0. 0. 0. 0. 0. 0. 0. 0. 0. 0. 0
}:
/* F, G. Ни 1 - базовые функции M05.
*/
#define F(x. y. z) (((x) & (y)) | ((-x) & (z)))
#define G(x. У. z) (((x) & (z)) | ((y) & (-Z)))
#define H(x. У. z) ((x) A (y) * (z))
#define I(x. У. z) ((y) A ((x) | (-Z)))
/* ROTATE_LEFT перемещает в цикле значение х влево на п бит.
*/
#define ROTATE_LEFT(x. n) (((х) « (n)) | ((х) » (32-(п))))
/* FF. GG. НН и II - преобразования для стадий 1. 2. 3 и 4.
Перемещение в цикле отделено от прибавления для того,
чтобы предотвратить повторное вычисление.
*/
^define FF(a. b. с. d. х. s. ас) { \
(а) +- F ((b), (с), (d)) + (х) + (UINT4)(ac); \
(а) - ROTATEJ.EFT ((a), (s)); \
(а) +- (Ь); \
}
#define GG(a. b. с. d. х. s. ас) { \
Исправленный алгоритм MD5 (RFC 1321, Appendix А, авторРок Рчвест)
257
(а) +- G ((b). (с), (d)) + (х) + (VINT4)(ac): \
(а) - ROTATE LEFT ((a). (S)): \ (а) +- (Ь): \ } #define НН(а. b. с. d. х, s. ас) { \
(а) +- Н ((b). (с), (d)) + (х) + (UINT4)(ac): \
(а) - ROTATE LEFT ((a), (s)): \ (а) +- (Ь); \ }
#define II(a. b. с. d. х. s. ас) { \
(а) +- I ((b). (с), (d)) + (х) + (UINT4)(ac): \
(а) - ROTATE LEFT ((a), (s)): \
(а) +- (Ь): \
}
/* MD5 initialization. Begins an М05 operation, writing a new context.
*/
/* Инициализация MD5. Начинает выполнение MD5.
записывание нового контекста.
void MD5Init (context)
MD5_CTX *context: /* context */
{
context->count[0] - context->count[l] - 0:
/* Загружает волшебные константы инициализации.
*/
context->state[0] - 0x67452301:
context->state[l] - 0xefcdab89;
context->state[2] - 0x98badcfe:
context->state[3] - 0x10325476:
}
/* Операция обновления блока MD5. Продолжает выполнение алгоритма MD5.
обрабатывая другой блок сообщения и обновляя контекст.
*/
void MD5Update (context, input. InputLen)
MD5_CTX *context: /* контекст */
unsigned char *1nput: /* входной блок */
unsigned int InputLen: /* длина входного блока */
{
unsigned int i. index, partLen;
/* Вычисляем количество байт no модулю 64 */
index - (unsigned 1nt)((context->count[0J » 3) & 0x3F):
/* Обновляем количество бит */
if ((context->count[0] +- ((UINT4)1nputLen « 3))
< ((UINT4)inputLen « 3))
context->count[l]++:
context->count[l] +- ((UINT4)inputLen » 29);
partLen - 64 - index:
/* Преобразовываем как можно большее количество раз
продолжение &
258 Приложение А. Исходные коды наиболее важных функций защиты
Листинг А.З (продолжение)
if (inputLen >- partLen) {
MD5 memcpy
~((POINTER)&context->buffer[index]. (POINTER)input. partLen): MD5Transform (context-
>state. context->buffer):
for (1 - partLen; i + 63 < inputLen; 1 += 64)
MD5Transform (context->state. &input[i]);
index - 0:
}
else
i - 0;
/* Буферизируем остаток входных данных */
MD5_memcpy
((POINTER)&context->buffer[indexJ. (POINTER)&input[i].
inputLen-i);
}
/* Завершение MD5. Запись дайджеста сообщения и обнуление контекста.
*/
void MD5F1nal (digest, context)
unsigned char digest[16J; /* дайджест сообщения */
MD5_CTX ‘context: /* контекст */
{
unsigned char bits[8];
unsigned int index. padLen;
/* Сохраняем количество бит */
Encode (bits. context->count. 8):
/‘ Дополняем до 56 no модулю 64.
*/
index - (unsigned int)((context->count[0] » 3) & 0x3f);
padLen - (index < 56) ? (56 - index) : (120 - index):
MD5Update (context. PADDING. padLen);
/* Добавляем длину (до дополнения) */
MD5Update (context, bits. 8);
/* Сохраняем состояние в дайджесте */
Encode (digest. context->state. 16);
/* Стираем важную информацию
*/
MD5 memset ((POINTER)context. 0. sizeof (‘context));
}
/* Базовое преобразование MD5. Преобразует состояние на основе блока.
*/
static void MD5Transform (state, block)
UINT4 state[4]:
unsigned char block[64]:
{
UINT4 a - state[0], b - state[l], c - state[2], fr- state[3], x[16]:
Decode (x. block. 64);
/* 1 заход */
Исправленный алгоритм MD5 (RFC 1321, Appendix А, автор ₽он Ривест) 259
FF (а. b. c. d. x[ 0]. Sil. 0xd76aa478); /* 1 */
FF (d. a. b. с. x[ 1]. S12. 0xe8c7b756); /* 2 */
FF (с. d. a. 1?. x[ 2]. S13. 0x242070db); /* 3 */
FF (b. c. d. a. x[ 3]. S14. Oxclbdceee): /* 4 */
FF (a. b. c. d. x[ 4]. Sil. 0xf57c0faf): /* 5 */
FF (d. a. b, c. x[ 5]. S12. 0x4787c62a); /* 6 */
FF (c. d. a. b. x[ 6]. S13. 0xa8304613): /* 7 */
FF (b. c. d. a. x[ 7]. S14. 0xfd469501); /* 8 */
FF (a. b. c. d. x[ 8]. Sil. 0x6980?8d8): /* 9 */
FF (d. a. b. c. x[ 9], S12. 0x8b44f7af); /* 10 */
FF (c. d. a. b. x[10]. S13. 0xffff5bbl): /*’11 */
FF (b. c. d. a. x[ll]. S14. 0x895cd7be); /* 12 */
FF (a. b. c. d. x[12]. Sil. 0x6b901122): /* 13 */
FF (d. a. b. c. x[13J. S12. 0xfd987193); /* 14 */
FF (c. d. a. b. x[14]. S13. 0xa679438e); /* 15 */
FF (b. c. d. a. x[15]. S14. 0x49b40821): /* 16 */
/* 2 заход */ GG (a. b. c. d. x[ 1]. S21. 0xf61e2562): /* 17 */
GG (d. a. b. c. x[ 6]. S22. 0xc040b340): /* 18 */
GG (c. d. a. b. x[ll]. S23. 0x265e5a51); /* 19 */
GG (b. c. d. a. x[ 0]. S24, 0xe9b6c7aa); /* 20 */
GG (a. b. c. d. x[ 5]. S21. 0xd62fl05d): /* 21 */
GG (d. a. b. c. x[10]. S22. 0x2441453); /* 22 */
GG (c. d. a. b. x[15]. S23. 0xd8ale681): /* 23 */
GG (b. c. d. a. x[ 4]. S24. 0xe7d3fbc8); /* 24 */
GG (a. b. c, d. x[ 9]. S21. 0x21elcde6): /* 25 */
GG (d. a. b, с. x[14]. S22. 0xc33707d6): /* 26 */
GG (c. d. a. b. x[ 3]. S23. 0xf4d50d87); /* 27 */
GG (b. c. d. a. x[ 8]. S24. 0x455al4ed): /* 28 */
GG (a, b. c. d. x[13]. S21, 0xa9e3e905); /* 29 */
GG (d. a. b. c. x[ 2]. S22. 0xfcefa3f8): /* 30 */
GG (c. d. a. b, x[ 7], S23. 0x676f02d9); /* 31 */
GG (b. c. d. a. x[12]. S24. 0x8d2a4c8a): /* 32 */
/* 3 заход */ HH (a. b. c. d. x[ 5]. S31. 0xfffa3942): /* 33 */
HH (d. a. b. c. x[ 8]. S32. 0x8771f681); /* 34 */
HH (c. d. a. b. x[ll]. S33. 0x6d9d6122); /* 35 */
HH (b. c. d. a. x[14]. S34. 0xfde5380c): /* 36 */
HH (a. b. c. d. x[ 1]. S31. 0xa4beea44); /* 37 */
HH (d. a. b. c. x[ 4]. S32. 0x4bdecfa9): 7* 38 */
HH (c. d. a. b. x[ 7]. S33. 0xf6bb4b60); /* 39 */
HH (b. c. d. a. x[10]. S34. 0xbebfbc70): /* 40 */
HH (a. b. c. d. x[13]. S31. 0x289b7ec6): /* 41 */
HH (d. a. b. c. x[ 0]. S32. 0xeaal27fa); /*-42 */
HH (c. d. a. b. x[ 3], S33. 0xd4ef3085): /* 43 */
HH (b. c. d. a. x[ 6]. S34. 0x4881d05); /* 44 */
HH (a. b. c. d. x[ 9]. S31. 0xd9d4d039); /* 45 */
г^пАмжеиыи &
260 Приложение А. Исходные коды наиболее важных функций защиты
Листинг А.З (продолжение)
hh (d. HH (c. a. d. c. b. с. x[12L S32, 0xe6db99e5): 7* 46 */ S33. 0xlfa27cf8); 7* 47 */
a. d. b. a. x[15], x[ 2].
HH (b. S34. 0xc4ac5665): 7* 48 */
/* II 4 заход *7 (a. b. c. d. x[ 0]. S41. 0xf4292244); /* 49 *7
II (d. a. b. c. x[ 7]. S42. 0x432aff97): /* 50 */
II (c. d. a. b. x[14]. S43.‘ 0xab9423a7): /* 51 *7
II (b. c. d. a. x[ 5]. S44, Oxfc93aO39); /* 52 */
II (a. b. c. d. x[12]. S41. 0x655b59c3); 7* 53 */
II (d. a. b. c. x[ 3]. S42. 0x8f0ccc92): /* 54 *7
II (c. d. a. b. x[10L S43. 0xffeff47d): /* 55 *7
II (b. c. d. a. x[ 1]. S44. 0x85845ddl); /* 56 *7
II (a. b. c. d. x[ 8]. S41. 0x6fa87e4f): /* 57 *7
II (d. a. b. c. x[15]. S42. Oxfe2ce6eO); /* 58 *7
II (c. d. a. b, x[ 6]. S43. 0xa3014314): /* 59 *7
II (b. c. d. a. x[13L S44, 0x4e0811al): /* 60 */
II (a. b. c. d. x[ 4]. S41. 0xf7537e82): /* 61 *7
II (d. a. b. c. x[ll]. S42. 0xbd3af235): /* 62 *7
II (c. d. a. b. x[ 2]. S43. 0x2ad7d2bb): /* 63 *7
II (b. c. d. a. x[ 9]. S44. 0xeb86d391); 7* 64 *7
state[0] statetl] state[2] +- a: b; C;
state[3] +- d:
7* Стираем важную информацию
*/
MD5_memset ((POINTER)x. 0. sizeof (х)):
}
7* Преобразует входные данные (UINT4) в выходные (unsigned char),
предполагая, что 1еп кратно 4.
*/
static void Encode (output, input, len)
unsigned char *output:
UINT4 *input:
unsigned int len;
{
unsigned int 1. j:
for (1 - 0. j - 0; j < len: i++. j +- 4) {
output[j] - (unsigned char)(input[i] & Oxff);
output[j+l] - (unsigned char)((input[i] » 8) & Oxff):
output[j+2] - (unsigned char)((input[i] » 16) & Oxff):
output[j+3] - (unsigned char)((input[i] » 24) & Oxff):.
} '
} -
/* Преобразует входные данные (unsigned char) в выходные (UINT4).
предполагая, что len кратно 4. *
*7
static void Decode (output, input, len)
Исправленный алгоритм MD5 (RFCT321, Appendix А автор Roh Ривест) 261
UINT4 *output: . • . с
unsigned char *input:
unsigned int len:
{
unsigned int i. j:
for (i - 0. j - 0: j < len: i++, j += 4)
outputEi] - ((UINT4)inputEj]) | (((UINT4)input[j+l]) « 8) |
(((UINT4)inputEJ+2]) « 16) | (((UINT4)input[j+3J) « 24):
}
/* Замечание: Замените "цикл for" на стандартную функцию memcpy. если это возможно.
*/
static void MD5_memcpy (output, input, len)
POINTER output:
POINTER input:
unsigned int len;
{
unsigned int i:
for (i - 0: i < len; i++) v
outputEi] - inputEi]:
}
/* Замечание: Замените "цикл for" на стандартную функцию memset. если это возможно.
*/
static void MD5_memset (output, value, len)
POINTER output:
int value:
unsigned int len;
{
unsigned int i:
for (i - 0; i < len; i++)
((char *)output)Ei] - (char)value:
}
Листинг A.4. mddriver.c
/* MDDRIVER.C - тестовая процедура для алгоритмов MD2. MD4 и MD5
*/
/* Авторские права® 1991-1992. RSA Data Security. Inc.
Создано в 1991. Все права защищены.
RSA Data Security. Inc. не делает никаких оценок годности этой
программы к продаже или использованию в каких-либо определенных целях.
Код предоставляется «как есть» без каких-либо гарантий..
Это предупреждение должно находиться во всех копиях, любой части этой
документации и/или кода.
*/ i
/* Следующее делает MD равным по умолчанию MD5, если это не было уже
сделано при помощи флагов компилятора С. >
*/
#ifndef МО
продолжение &
262 Приложение А. Исходные коды наиболее важных функций защиты
Листинг А.4 (продолжение)
# define MD MD5
#endif
include <stdio.h>
include <time.h>
include «string.h>
^Include "global.h"
# if MD — 2
include "md2.h"
#endif
# if MD — 4
#include "md4.h"
#endif
# if MD — 5
#include "md5.h"
#endif
/* Длина тестового блока, количество тестовых блоков.
*/
tfdefine TEST_8LOCK_LEN 1000
tfdefine TEST_BLOCK_COUNT 1000
static void MDString PROTO_LIST ((char *)):
Static void MDTimeTrial PROTO_LIST ((void));
static void MDTestSuite PROTO_LIST ((void));
static void MDFile PROTO_LIST ((char *)):
static void MDFilter PR0T0_LIST ((void));
static void MDPrint PROTO_LIST ((unsigned char [16]))
# if MD -- 2
tfdefine MD_CTX MD2_CTX
# define MDTnit MD2Init
# define MDUpdate MD2Update
tfdefine MDFinal MD2Final
#endi f
# if MD — 4
tfdefine MD_CTX MD4_CTX
# define MDInit MD4Init
# define MDUpdate MD4Update
# define MDFinal MD4Final
#endif
# if MD — 5
# define MD_CTX MD5_CTX
# define MDInit MD5Init
# define MDUpdate MD5Update
# define MDFinal MD5Final
#endif
/* Главная часть.
Аргументы (могут быть любые их комбинации)
-sstring - строка дайджеста
Исправленный алгоритм MD5 (RFC 1321, Appendix А, автор Рон Ривест) 263
-t - проверка быстродействия
-х - тестовый сценарий
filename - файл дайджеста
(ничего) - стандартные входные данные дайджеста
*/
int main (argc. argv)
int argc:
char *argv[]:
{
int i:
if (argc > 1)
for (i - 1: i < argc; i++)
if (argv[i][0J -- && argv[i][l] — "s")
MDString (argv[i] + 2):
else if (strcmp (argv[i], "-t") — 0)
MDTimeTrial 0;
else if (strcmp (argv[i], ”-x") — 0)
MDTestSuite ():
else
MDFile (argv[i]);
else
MDFilter ():
return (0):
}
/* Вычисляет дайджест строки и выводит результат.
*/
static void MDString (string)
char ‘string:
{
MD_CTX context:
unsigned char digest[16]:
unsigned int len - strlen (string):
MDInit (&context):
MDUpdate (&context. string, len);
MDFinal (digest. ^context):
printf ("MDM (VlsV) - ". MD. string):
MDPrint (digest):
printf (“\n*'):
}
/* Измеряет время вычисления дайджеста TEST_BLOCK_COUNT
ТЕ5Т_В10СК_1ЕМ-байтных блоков.
*/
static void MDTimeTrial 0
{
MD_CTX context;
time_t endTime, startTime:
unsigned char block[TEST_8LOCK_LEN], digest[16]:
unsigned int 1:
264 Приложение А. Исходные коды наиболее нажных функций защиты,
Листинг А.4 (продолжение)
printf < •
("MD«d time trial. Digesting «d «d-byte blocks ...". MD,
TEST_BLOCK_LEN, TEST_BLOCK_COUNT);
/* Инициализация блока */
for (i - 0; i < TEST_BLOCK_LEN: i++)
block[i] - (unsigned char)(i & Oxff):
/* Запускаем таймер */
time (&startTime):
/* Вычисляем дайджесты блоков */
MDInit (&context):
for (i - 0: i < TEST_BLOCK_COUNT: i++)
MDUpdate (&context. block. TEST_BLOCK_LEN):
MDFinal (digest. &context):
/* Останавливаем таймер */
time (&endTime):
printf (” done\n");
printf (“Digest - ”);
MDPrint (digest):
printf ("InTime - «Id secondsXn". (long)(endT1me-startTime)): printf
("Speed - «Id bytes/secondin''.
(long)TEST_BLOCK LEN * (long)TEST_BLOCK_COUNT/(endTime-startTime)):
}
/* Вычисляем дайджесты заданных строк и выводим результат.
*/
static void MDTestSuite О
{
printf ("MD«d test suiteAn", MD):
MDString (" ");
MDString ("a”):
MDString ("abc");
MDString ("message digest"): ';
MDString ("abcdefghijklmnopqrstuvwxyz"):
MDString
("ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghi jklmnopqrstuvwxyz0123456789"): MDStri ng
("12345678901234567890123456789012345678901
1234567890123456789012345678901234567890"):
}
/* Вычисляем дайджест файла и выводим результат.
*/
static void MDFile (filename)
char *filename:
{ ..........................................................
FILE *file:
MD_CTX context:
int len: . -
unsigned char buffer[1024], digest[16]: j, 1
if ((file - fopen (filename. "rb")y — NULL)
printf ("«s can’t be openedln". filename):
Исправленныйалгоритм МО5 (RFC 1321, Appenidx А, автор: Roh Ривест) 265
else {
MDInit (tontext);
while (len - freed (buffer. 1. 1024. file)) «>
MDUpdate (&context. buffer, len):
MDFinal (digest, tontext);
fclose (file);
printf («MDSd (Us) - «. MD. filename);
MDPrint (digest):
printf («\n»);
}
}
/* Вычисляет дайджест строки из стандартного входного устройства и выводит результат.
*/
static void MDFilter О
{
MD_CTX context;
int len;
unsigned char buffer[16]. digest[16]:
MDInit (tontext);
while (len - fread (buffer. 1, 16. stdin))
MDUpdate (tontext. buffer, len);
MDFinal (digest, tontext):
MDPrint (digest):
printf («\п»);
}
/* Печатает дайджест сообщения в шестнадцатеричном виде.
*/
static void MDPrint (digest)
unsigned char digest[16]:
{
unsigned int 1;
for (1 - 0; i < 16: 1++)
printf («102х», digest[i]):
}
Листинг A.5. Тест
При выполнении тестовой программы для алгоритма MD5 (с флагом -х) должны получиться
следующие результаты:
MD5 test suite:
MD5 ("") - d41d8cd98f00b204e9800998ecf8427e
MD5 ("а") - 0ccl75b9c0flb6a831c399e269772661
MD5 Cabc") - 900150983cd24fb0d6963f7d28el7f72
MD5 (’message digest") - f96b697d7cb7938d525a2f31aafl61d0
MD5 ("abcdefghijklmnopqrstuvwxyz") - c3fcd3d76192e4007dfb496cca67el3b
MD5 ("ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789”) -
dl74ab98d277d9f5a5611c2c9f419d9f
MD5 (’’ 12345678901234567890123456789012345678901234567890123456789012345678901234567890”)
- 57edf4a22be3c955ac49da2e2107b67a
266 Приложение А. Исходные коды наиболее важных функций защиты
Исправленный алгоритм MD5 (RFC 1321,
Section 3.4, автор Рон Ривест)
/* Process each 16-word block. */
For 1 - 0 to N/16-1 do
7* Copy block 1 into X. */ .
For j - 0 to 15 do
Set X[j] to M[i*16+j]. .
end /* of loop on j */
/* Save A as AA. 8 as BB. C as CC. and D as DD. */
AA - A
BB - 8
CC - C
DD - D
/* Round 1. *7
/* Let [abed k s i] denote the operation
a - b ♦ ((a + F(b.c.d) + X[k] + T[i]) «< s). */
7* Do the following 16 operations. *7
[ABCD 0 7 1] [DABC 1 12 2] [CDAB 2 17 3] [BCDA 3 22 4]
[ABCD 4 7 5] [DABC 5 12 6] [CDAB 6 17 7] [BCDA 7 22 8]
[ABCD В 7 9] [DABC 9 12 10] [CDAB 10 17 11] [8CDA 11 22 12]
[ABCD 12 7 13] [DABC 13 12 14] [CDAB 14 17 15] [BCDA 15 22 16]
/* Round 2. */
7* Let [abed k s 1] denote the operation
a - b + ((a + G(b.c.d) + X[k] + T[i]) «< s). *7
7* Do the following 16 operations. *7
[ABCO 1 5 17] [DABC 6 9 IB] [CDAB 11 14 19] [BCDA 0 20 20]
[ABCO 5 5 21] [DABC 10 9 22] [CDAB 15 14 23] [BCDA 4 20 24]
[ABCD 9 5 25] [DABC 14 9 26] [CDAB 3 14 27] [BCDA 8 20 28]
[ABCD 13 5 29] [DABC 2 9 30] [CDAB 7 14 31] [BCDA 12 20 32]
/* Round 3. *7
7* Let [abed k s t] denote the operation
a - b 7* Do the •• ((a + H(b.c.d) + X[k] + T[i]) «< s). *7
following 16 operations . *7 [CDAB 11 16 35] 16 39] 16 43] 16 47] [BCDA 14 23 36] [BCDA 10 23 40]
[ABCO [ABCD [ABCD [ABCO 5 1 13 9 4 33] 4 37] 4 41] 4 45] [DABC [DABC [DABC [DABC 8 11 34]
4 11 38] 42] 46] [CDAB [CDAB [CDAB 7 3 15
0 12 11 11 [BCDA [BCDA 6 2 23 44] 23 48]
7* Round 4 . *7
/* Let [abed k s t] denote the operation
a - b + ((a + I(b.c.d) + X[k] + T[i]) «< s). */
7* Do the following 16 operations. */
[ABCD 0 6 49] [DABC 7 10 50] [CDAB 14 15 51]^ [BCDA 5 21 52]
[ABCD 12 6 53] [DABC 3 10 54] [CDAB 10 15 55]' [BCDA 1 21 56]
[ABCD В 6 57] [DABC 15 10 58] [CDAB 6 15 59] [BCDA 13 21 60]
[ABCD 4 6 61] [DABC 11 10 62] [CDAB 2 15 63] [BCDA 9 21 64]
НМАС: Идентификация сообщения при помощи хэширования 267
/* Then perform the following additions. (That is increment each’’
of the four registers by the value it had before this block
was started.) */
A - A + AA
В - 8 + BB
C - С + CC
D - D + DD
end /* of loop on i */
НМАС: Идентификация сообщения при
помощи хэширования (RFC 2104,
Appendix, Авторы: Хьюго Кравчик, Михир
Беллар и Ран Канетти)
/*
** Функция: hmac_md5
void hmac_md5(text. unsigned char* int unsigned char* int caddr_t text_len. key. text: textjen: key; key_len; digest; key_len. digest) /* указатель на поток данных */ /* длина потока данных */ /* указатель на ключ идентификации */ /* длина ключа идентификации */ /* возвращаемый дайджест */
{ MD5 CTX context;
unsigned char k_ipad[65]: /* внутреннее дополнение -
* ключ ИСКЛЮЧАЮЩЕЕ ИЛИ ipad
*/
nsigned char k_opad[65J; /* внешнее дополнение -
* ключ ИСКЛЮЧАЮЩЕЕ ИЛИ opad
*/
unsigned char tk[16];
int i:
/* если ключ длиннее чем 64 байта - сбросить его на key-MDS(key) */
if (key_len > 64) {
MD5_CTX tctx;
MD5Init(&tctx); '
MD5Update(&tctx, key, keylen);
MD5F1nal(tk. &tctx):
продолжение £
268 Приложение А. Исходные коды наиболее ващных функций защиты
key - tk;
keyjen - 16:
/*
* преобразование HMAC_MD5 выглядит так:
* MD5(K ИСКЛЮЧАЮЩЕЕ_ИЛИ opad. М05(К ИСКЛЮЧАЮЩЕЕ..!» ipad. text))
* Где К - байтовый ключ
* ipad - байт 0x36, повторенный 64 раза
* opad - байт 0ч5с. повторенный 64 раза
* text - защищаемые данные
*/
•’ - *.. Jll..
/* начинаем с того, что сохраняем ключ в дополнениях*/'
bzero( kjpad. sizeof k_1pad): !
bzero( k_opad. sizeof k_opad):
bcopy( key. kJ pad. keyjen);
bcopy( key. k_opad. keyjen);
/* ключ ИСКЛЮЧАЮЩЕЕ J» c ipad
for (i-0: i<64: i++' { f
kipad[i] 0x36:
к «pad[i] **= QxSc.
}
/*
* выполнение внутреннего MD5
• Ч Г- » л A • ! V ... * i , ...
R • 'J V- 'i(= ОV *
- - • ’ f -* Vs 4 ft . f » 41 т v
и opad */ . „
-I • : ' J i/v « 'л. ГЧ
Л <.<’•' . 1 <S-'J
*’ ’ ' *>' ; ' . ‘ л Ч'-ГУ’ЛС
*/
/* инициализация контекста для первого прохода */ ' /
MD5Init(&context); . /* начинаем с внутреннего дополнения */
M05Update(&context. kJpad. 64) /* затем идет текст датаграммы */
MD5Update(&context. text, text ler). /* завершаем первый проход */
MDSFinal(digest. &context): 1 . -
/*
* выполнение внешнего MD5
*/
/* инициализация контекста для второго прохода */
MD5Init(&context): /* начинаем с внешнего дополнения */
M05Update(&context. k_opad. 64): /* затем идет результат первого хэширования */
MD5Update(&context. digest. 16): /* завершаем второй проход */
MDSFinal(digest. &context);
}
Тестовые векторы (завершающий строку байт “\0‘ в тест не' включаемся).:
key - OxObObObObObObObObObObObQbObObObOb
keyjen - 16 bytes . v
data - "Hi There"
data Jen - 8 bytes
Создание и извлечение зашифрованного текста в RFC 1969 2 69
digest - 0x9294727a3638bblcl3f48ef8158bfc9d
key - data - data_len - digest - "Jefe" "what do ya want for nothing?" 28 bytes 0x750c783e6ab0b503eaa86e310a5db738
key - key_len data - OxAiAAAAAAAAAVA^AAATAW^VAAiVAAA 16 bytes OxUOOX)OOjDDDDDi»JOi»D... . .DDDDDDDDDDDDDDDDDDDD... . .[IX'XXXftiDDDDDDDDD... . (ШШШХШП1Ш)... ..DDDDDDDDDDDDDDDDDDDD
data len - igest - 50 bytes 0x56be34521dl44c88dbb8c733f0e8b3f6
Создание и извлечение зашифрованного
текста в RFC 1969: РРР-протокол
шифрования DES (DESE-bis) (авторы Кейт
Склоуер и Джерри М. Мейер)
Создание зашифрованного текста
В этом обсуждении Е[к] будет обозначать определяемый 56-битным ключом к основной шифр
DES. применяемый к 64-битным блокам. D[k] будет обозначать соответствующий механизм де-
шифрации. Текст, дополненный до длины, кратной 64 битам, и описанный в предыдущем разде-
ле. станет последовательностью 64-битных блоков P[i] (где 1 находится в диапазоне от 1 до
п). Диакритический знак " служит для обозначения побитовой операции исключающего или.
применяемой к 64-битным блокам.
В процессе шифрации первого блока, предназначенного для передачи по открытым линиям, да-
вайте называть С[0] результатом применения Е[к] к Начальным данным текущего времени, по-
лученным в настройках ESP DESE от второй стороны. Для последующих пакетов С[0] будет оз-
начать последний блок пакета, переданного перед данным.
Шифрация данных происходит повторением операции
С[1] - E[k](P[i] ‘ С[т-1])
для 1 в диапазоне от 1 до п.
6.3. Извлечение текста из шифровки
В процессе дешифрации первого пакета, переданного по открытой линии. С[0] будет результа-
том применения Е[к] к начальным данным текущего времени, переданным в настройках ESP
DESE. Первый пакет имеет номер 0. Для последующих пакетов. С[0] - последний блок пакета,
переданного перед данным. Дешифрация осуществляется повторением операции
P[i] - C[i-1] А D[k](C[i])
для 1 в диапазоне от 1 до п.
270 Приложение А. Исходные коды наиболее важных функций защиты
Восстановление после потери пакета
Потеря пакета обнаруживается в тон случае, если прерывается последовательность получения
пакетов. Предположим, пакет номер N-1 содержит ошибки или вообще потерян, а пакеты N и
N+1 успешно получены.
Поскольку в соответствии с алгоритмом в предыдущем разделе требуется, чтобы С[0] пакета N
был последним С[последний] в пакете N-1, то тогда невозможно дешифровать содержимое паке-
та N. Однако все пакеты N+1 и последующие могут быть декодированы обычным способом, по-
скольку для этого нужен последний блок предыдущего пакета (в данном случае N. который был
получен). •
ПРИЛОЖЕНИЕ
Трансляция сетевых адресов (NAT)
Трансляция сетевых адресов (Network Address Translation — NAT) позволяет
организации в пределах своей области маршрутизации использовать свою
IP-адресацию (не регистрируя их, что необходимо для маршрутизации адресов в
Интернете). Если же данные нужно отправить за пределы этой области, то NAT
транслирует эти адреса в адреса, маршрутизируемые в Интернете. Обратный
процесс выполняется маршрутизатором, когда приходят данные, предназначен-
ные пользователям этой организации. Таким образом, NAT позволяет примене-
ние своих собственных локальных адресов. Кроме того, NAT поддерживает про-
цедуру, называемую распределением данных, которая позволяет устанавливать
соответствие между одним глобальным адресом и множеством локальных адре-
сов. Эта возможность позволяет экономить глобальные адреса, что будет объяс-
нено чуть позже. NAT описывается в RFC 1631, а примеры, приведенные далее,
взяты как из этого RFC, так и из [CISC98].
Рис. Б.1 использован здесь для того, чтобы ввести основные понятия NAT. Во-
первых, нужно сделать несколько определений.
Внутренний локальный IP-адрес — это локальный адрес, назначенный хосту.
Внутренний глобальный IP-адрес — глобальный адрес, который служит внутрен-
ним адресом для внешних сетей (сетей с глобальной адресацией).
Шлюз А на этом рисунке содержит в себе таблицу NAT, которая служит для
связывания этих адресов.
Нижняя часть рис. Б.1 показывает, как используется NAT для отображения ад-
ресов между внешними и внутренними сетями. В событии 1 хост Б посылает
IP-датаграмму хосту Г через маршрутизатор А. Маршрутизатор А проверяет ад-
рес в датаграмме и распознает, что адрес отправителя (АО) 176.16.1.1 — это внут-
ренний адрес. Если в таблице NAT нет соответствующей записи, маршрутизатор
272 Приложение Б. Трансляция сетевых адресов (NAT)
динамически выбирает доступный глобальный адрес из пула адресов и создает
такую запись. В событии 2 маршрутизатор замещает внутренний АО соответству-
ющим внешним адресом отправителя, после чего пересылает датаграмму. >•
ф SA= 176.16.1.1 -
DA= 191.1.1.3 “
лл SA= 191.1.1.1
DA =191.1.1.3 r ;-j
<SA= 191.1.1.3
SA =191.1.1.3 DA =191.1.1.1
DA =176.16.1.1
АП Адрес получателя
ПП Порт получателе
АО Адрес отправителя
ПО Порт отправителя
Рис. Б.1. Трансляция сетевых адресов (NAT)
В событии 3 хост Г отвечает и использует свой АО (191.1.1.3) и глобальный ад-
рес NAT в качестве АП (191.1.1.1). Эта датаграмма приводит маршрутизатору
А, который производит преобразование глобального АП (191.1,1.1) во внутрен-
ний АП (176.16.1.1), как показано в событии 4 рисунка.
NAT имеет очень простую конфигурацию. По сути, только локальные и глобаль-
ные IP-адреса при настройке вводятся в таблицу, а также внутренние и внешние
интерфейсы маршрутизатора.
NAT позволяет использовать один глобальный адрес для отображения на мно-
жество локальных. Эта операция называется перегрузкой внутреннего глобально-
го адреса. Эта способность поддерживать однозначную идентификацию всех сес-
сий пользователя обеспечивается при помощи внутренних лекальных адресов,
внутренних глобальных адресов и номеров портов, которые передаются в заго-
ловках TCP и UDP.
Трансляция сетевых адресов (NAT) 273
NAT определяет другой адрес, называемый внешним глобальным IP-адресом, ко*
торый является обычным IP-адресом, выделенным данному хосту во внешней
сети с глобальной адресацией.
176.16.1.1
176.16:1.2
191.1.1.1
Интернет
191.1.1.3
Таблица NAT
Протокол Внутренний локальный 1Р-адрес: протокол ."Внутренний глобальный IP-адрес: протокол Внешний глобальный 1Р-адрес: протокол
TCP 176.16.1.1:1500 191.1.1.1:4500 i 191.1.113:25
TCP 176.16.1.2:3001 191.1.1.1:3001 191.1.1.3:25
SA = 176.16.1.1
у, SP = 1500
DA =191.1.1.3
DP = 25
SA =191.1.1.1
~ SP = 1500
DA =191.1.1.3
DP = 25
SA= 191,1.1.3
SP = 25
DA = 191.1,1.1
DP = 1500
SA =191.1.1.3
SP = 25
DA =176.16.1.1
DP =1500
АП Адрес получателя •
ПП Порт получателя
АО Адрес отправителя
ПО Порт отправителя
Рис. Б.2. Перегрузка внутренних глобальных адресов
На рис. Б.2 показано, как работает эта часть NAT. В событии 1 хост Б посылает
датаграмму хосту Г через маршрутизатор А. Маршрутизатор получает этот па-
кет и выполняет либо статическое, либо динамическое преобразование внутрен-
него локального IP-адреса (176.16.1.1) в разделяемый глобальный 1Р*адрес
(191.1.1.1). •
274 Приложение Б. Трансляция сетевых адресов (NAT)
В событии 2 маршрутизатор пересылает датаграмму хосту Г. В событии 3 хост Г
посылает ответное сообщение. Для этого он просто меняет местами адрес и порт
получателя и адрес и порт отправителя.
Маршрутизатор А получает эту датаграмму и просматривает таблицу NAT с тем,
чтобы определить, что делать с этим пакетом. Для поиска он использует адрес
и порт получателя.
В событии 4 глобальные адрес и порт получателя преобразованы в локальные
адрес и порт, что соответствует хосту Б.
Конфигурация маршрутизации влечет за собой выделение пула глобальных
адресов и установления соответствия им внутренних адресов и связанных
внутренних и внешних интерфейсов.
Сокращения
3DESE (Triple-DESE Encryption Protocol) — Протокол тройной DESE-шифрации
ACK (Acknowledgement) — Подтверждение
AH (Authentication Header) — Идентифицирующий заголовок
AUC (Authentication Control Center) — Центр контроля идентификации
BITC (Bump-In-The-Code) — Запихнуть-в-код
BITS (Bump-In-The-Stack) — Запихнуть-в-стек
BITW (Bump-In-The-Wire) — Запихнуть-в-железо
CA (Certification Authorities) — Центр сертификации
СЕК (Content-Encryption Key) — Ключ шифровки данных
CHAP (Challenge-Handshake Authentication Protocol) — Протокол идентификации
запрос-подтверждение
CLNP (Connectionless Network Protocol) — Сетевой протокол без установления соединения
CSU (Channel Service Unit) — Модуль обслуживания канала
DES (US Data Encryption Standard) — Стандарт шифрации данных США
DESE-bis (DES Encryption Protocol Version 2) — Протокол шифрации DES, версия 2
DNS (Domain Name Server) — Служба имен доменов
DOI (Domain Of Interpretation) — Область интерпретации
DSU (Data Service Unit) — Модуль обслуживания данных
ЕАР (Extensible Authentication Protocol) — Расширяемый протокол идентификации
ЕСР (Encryption Control Protocol) — Протокол управления шифрацией
ESP (Encapsulated Security Payload) — Вложенные защищенные^передаваемые данные
ПР (File Transfer Protocol) — Протокол передачи файлов
GSM (Global System for Mobile Communications) — Глобальная система мобильной связи
276 Сокращения
HDLC (High-level Data Link Control) — Управление каналом передачи данных верхнего уровня
НМАС (Hashing for Message Authentication) — Проверка сообщений с хэшированием по ключам
HTML (Hypertext Markup Language) — Язык гипертекстовой разметки web-страниц
HTTP (Hypertext Transfer Protocol) — Протокол передачи гипертекстовых файлов
IANA (Internet Assigned Numbers Authority) — Агентство no выделению имен и уникальных
• параметров протоколов в Интернете
ICMP (Internet Control Message Protocol).— Протокол управляющих сообщений в сети Интернет
ICV (Integrity Check Value) — Значение проверки сохранности
IETF (Internet Engineering Task Force) — Проблемная группа проектирования Интернета
IKE (Internet Key Exchange) — Протокол обмена ключами в Интернете
IMEI (International Mobile Equipment Identity) — Идентификатор оборудования мобильной сети
IMSI (International Mobile Subscriber Identity) — Идентификатор подписчика мобильной сети
IP (Internet Protocol) — Протокол Интернета \
IPCP (Internet Protocol Control Protocol) — Протокол управления протоколом Интернета
IPSec (Internet Security Protocol) — Протокол безопасности Интернета
IPv4 (Internet Protocol version 4) — Интернет-протокол, версия 4
IPv6 (Internet Protocol version 6) — Интернет-протокол, версия б
ISAKMP (Internet Security Association and Key Management Protocol) — Протокол ассоциаций
безопасности и управления ключами Интернета
ISO (International Organization for Standardization) — Международная организация
no стандартизации . > : ; •
ISP (Internet Service Provider) — Поставщик услуг Интернета > »;
КЕК (Key-Encryption Key) — Ключ для шифровки ключей
LAN (Local Access Network) — Локальная сеть
LCP (Link Control Protocol) — Протокол управления соединением
MAC (Message Authentication Code) — Код подтверждения подлинности сообщения
MD (Message Digest) — Дайджест сообщения
MFWS (Managed Firewall Service) — Услуга управления брандмауэром
MTU (Maximum Transmission Unit) — Максимальный размер передаваемого блока
NAK (Negative Acknowledgement) — Подтверждение отказа
NAS (Network Access Server) — Сервер доступа к сети
NAT (Network Address Translation) — Трансляция сетевых адресов
NCP (Network Control Protocol) — Протокол управления сетью
NIST (National Institute of Standards and Technology) — Национальный Институт стандартов
и технологий США
Сокращения 277
OSI (Open Systems Interconnection) — Взаимодействие открытых систем
OSPF (Open Shortest Path First) — Первоочередное открытие кратчайших маршрутов
ОТК (One-Time Key) — Одноразовый ключ
РАР (Password Authentication Protocol) — Протокол проверки пароля
PAD (Packet Assembler/Disassembler) — Сборщик/разборщик пакетов
PARC (Palo Alto Research Center) — Исследовательский центр в Пало Альто
PCI (Protocol Control Information) — Управляющая информация протокола
PDU (Protocol Data Unit) — Блок данных протокола
PFS (Perfect Forward Security) — Совершенная прямая секретность
PGP (Pretty Good Privacy) — Достаточно хорошая секретность
PKI (Public-Key Infrastructure) — Инфраструктура открытого ключа
PPP (Point-to-Point Protocol) —г Протокол двухточечного соединения
QOS (Quality Of Service) — Качество предоставляемых услуг
RA (Request Authenticator) — Идентификатор запроса
RADIUS (Remote Authentication Dial-In User Service) — Система удаленной авторизации
пользователей по коммутируемым линиям
RARP (Reverse Address Resolution Protocol) — Протокол определения адреса
по местоположению хоста
RFC (Request For Comments) — Запрос комментариев
RPC (Remote Procedure Call) — Удаленный вызов процедуры
RR (Resource Record) Ресурсная запись
RSA (Rivest-Shamir-Adleman) — Ривест-Шамир-Адлеман
RSVP (Resource Reservation Protocol) — Протокол резервирования ресурсов
RTT (Round Trip Time) — Время пересылки туда и обратно
SA (Security Association) — Ассоциация безопасности
SAD (Security Association Database) — База данных ассоциаций безопасности
SAP (Service Access Point) — Точка доступа к службе
SDLC (Synchronous Data Link Control) — Синхронное управление передачей данных
SGNC (Signaling Gateway/NAS Controller) — Сигнальный шлюз и/или NAS-контроЛлер
SHA (Secure Hash Algorithm) — Алгоритм защищенного хэширования
SIM (Subscriber Identity Module) — Модуль идентификации подписчика
SLA (Service Level Agreement) — Соглашение о качестве предоставляемых услуг
SMTP (Simple Mail Transfer Protocol) — Простой протокол электронной почты
SNA (System Network Architecture) — Системная сетевая архитектура
278 Сокращения
SNMP (Simple Network Management Protocol) — Простой протокол сетевого управления
SPD (Security Policy Database) — База данных правил безопасности
SPI (Security Parameter Index) — Индекс параметров защиты
SRES (Signed Response) — Подтвержденный ответ
TCP (Transmission Control Protocol) — Протокол управления передачей
TFTP (Trivial FTP) — Простейший ПР
TLS (Transport Level Security) — Защита-на транспортном уровне
TOS (Type Of Service) — Тип сервиса
TTL (Time To Live) — Время жизни
UDP (User Data Protocol) — Протокол данных пользователя
URL (Uniform Resource Locator) — Унифицированный указатель ресурса
VoIP (Voice over IP) — Речь через IP
VPN (Virtual Private Network) — Виртуальная частная сеть
WAN (Wide Area Network) — Глобальная сеть
Алфавитный указатель
Символьный
3DESE, См. Протокол тройной DESE, 101
А
Адлеман, Леонард (см. RSA), 54
Алгоритм
3DESE, 114
АЗ, 68
А8, 69
CAVE, 236
DES, ИЗ
DES-CBC, 115
DES-EDE3-CBC, 115
НМАС, 94
HMAC-SHA-1-96, 183
MD4, 93
MD5, 88
MD5-HMAC-96, 134, 183
RSA, 54, 56
SHA, 92
X9.42, 86
Диффи—Хеллмана, 57
Хэш-кода, 47
Циклический счетчик, 43
Часовая арифметика, 43
Анонимность, 18
Апплет, 36
Арифметика в остаточных классах, 43
RSA, 54
Диффи—Хеллмана, 45
Асимметричные ключи, 49, 51
Асимметричное шифрование, 39, 49, 52
Ассоциация безопасности, 97, 143, 145
Пакет, 146, 150
Примеры, 146
Типы, 148
Атака
Бомба, 32
Вирус, 30
Закупорка, 31
Затопление, 31
Лазейка, 33
Отказ в обслуживании, 29
Повторение, 33
Салями, 33
Троянский конь, 31
Червь, 30
Человек посередине, 64
База данных ассоциаций безопасности, 143, 153
Записи, 155
Селекторы, 155
База данных правил безопасности, 143, 153
Записи, 155
Селекторы, 155
Беллар, Михир, 94
Бомба, 32
Брандмауэр, 20, 71
IPSec, 80
MFWS, 78
SOCKS, 81
Виды доступа, 72
Внешний, 72
Внутренний, 72
Возможности, 73
Фильтрация пакетов, 74
В
Взлом шифра, 47
Виртуальная частная сеть
Современная схема, 22
Соглашение о качестве предоставляемых
услуг, 25
280 Алфавитный указатель
Виртуальная частная сеть (продолжение)
Старая схема, 21
Вирус, 30
Вложенные защищенные передаваемые
данные, 96, 144, 162, 170
НМАС, 183
Преобразования идентификации, 213
Создание пакета, 179
Транспортный режим, 164, 170 *
Туннельный режим, 164, 171
Г
Генерация ключей, 56
Глобальная система мобильной связи, 68
Идентификация, 68
Глобальные сети, 25
д
Дайджест сообщения, 40, 45, 54, 88
Диффи, Випфилд, 44, 84
Диффи—Хеллман, 45, 84
Алгоритм, 57
Достаточно Хорошая Секретность, 61
OpenPGP, 62
Сеть доверия PGP, 188
3
Закупорка, 31
Запихнуть-в-железо, 153
Запихиуть-в-код, 152
Запихнуть-в-стек, 152
Затопление, 31 г
Защита данных на транспортном
уровне, 101, 109
Handshake Protocol, 110
Record Protocol, ПО
Предназначение, 110
Защищенный по вычислениям, 39
Значение проверки сохранности, 163
Для входящих пакетов АН, 170
Для входящих пакетов ESP, 175
Для исходящих пакетов АН, 169
Для исходящих пакетов ESP, 174
И
Идентифицирующий заголовок, 96, 144, 162
НМАС, 183
Преобразования идентификации, 213
Транспортный режим, IPv4, 166
Транспортный режим, 164
Транспортный режим, IPv6, 166 л
Туннельный режим, 164
Туннельный режим, IPv4, 166
Туннельный режим, IPv6, 166
Инфраструктура открытого ключа, 186, 215
Две пары ключей, 189
Примеры реализаций, 230
Принятие, 188
Управление ключами, 189
Центр сертификации, 187
Канетти, Ран, 94
Ключ для шифровки ключей, 85
Генерация, 86
Код подтверждения подлинности сообщения, 57
ICV, 163
Надежность, 95
Контроль доступа, 19
Конфиденциальность, 18
Кравчик, Хьюго, 94
-1 > '
Л
Лазейка, 33
М
Меркл, Ральф, 84
Модуль идентификации подписчика, 68, -246
О
Область интерпретации, 190, 192
ISAKMP, 209
Обмен ключами, 49, 50
Агрессивный обмен, 209
Базовый обмен, 206
Односторонняя функция, 43
Отказ в обслуживании, 29
п
Пакет
LCP, 106
Ассоциаций безопасности, 146, 150
Нумерация, 67 . s • , ,,
Сборщик/разборщик, 22
Фильтрация, 74
Формат в 3DESE, 116
Формат в DESE, 114
Формат в PAR 119
Повторение, 33
Подлинность, 18
Принятие, 19
Проверка сообщений с хэшированием
по ключам, 88, 94, 183
IPSec, 96
Надежность, 95
Применение в АН и ESP, 183
Производительность, 95
Алфавитный указатель 281
Протокол ассоциаций безопасности
и управления, 97, 190, 191
Cookies, 193
OAKLEY, 206
Агрессивный обмен, 209
Базовый обмен, 206
Защитная оболочка, 191
Область интерпретации, 209 ,
Обмен идентификации, 208
Обмен с защитой конфиденциальности, 207
Передаваемые данные, 196, 210
Примеры согласований, 206
Фазы согласования, 192
Формат сообщения, 194 ,,
Протокол безопасностин,Интернета, 23
Местоположение, 152
НМАС, 94, 96
NAT, 184
Архитектура, 143
Ассоциации безопасности, 145
Базы данных, 153
Брандмауэр, 80
Возможности, 144
Защищенный туннель, 144
Основы, 143
Примеры посылки и получения данных, 157
Протоколы АН и ESP, 162
Режимы, 148, 164
Создание заголовка для туннельного .
режима, 181
Хэширование ключа, 57
Протокол двухточечного соединения, 23, 101
DESE-bis, ИЗ
EAP, 111
ЕСР, 110
HDLC, 101
LCP, 103 - ' !
Вспомогательные протоколы, 109
Примеры использования, 104
Протоколы авторизации РАР и CHAP, 118
Фазовая диаграмма, 105
Протокол идентификации
запрос-подтверждение, 118, 120
NAS-клиент, 125
Протокол обмена ключами в .... 97
Протокол обмена ключами в Интернете, 190, 215
Группы OAKLEY, 225
Примеры обмена сообщениями, 220
Протокол передачи гипертекстовых файлов, 34
Протокол тройной DESE, 101, 114
Настройка конфигурации в ЕСР, 116
Формат пакета, 116
Протокол управления соединением, 101, 103
Пакеты, 106
Фаза завершения соединения, 106
Фаза установления соединения, 105
Протокол управления шифрацией, 101, 110
Протокол шифрации DES, версия 2, 101
Протокол шифрования DES, версия 2, ИЗ
Р
Расширяемый протокол
идентификации, 101, 111
Режевски, Мариан, 48
Ресурсная запись ключа, 91
Ривест, Рон, 54, 87
С
Салями, 33
Сборщик/разборщик пакетов, 22
Сдвиговый шифр Цезаря, 41
Секретность, 18
Сертификаты ключей, 65
Симметричное шифрование, 39
Система удаленной авторизации
пользователей..., 23, 118, 122
Настройка, 123
Атрибуты, 126
Пример обмена данными, 128
Пример обмена сообщениями, 124
Проблемы, 130
Формат сообщения, 125
Служба имен доменов, 91, 188
Совершенная прямая секретность, 63
IKE, 217
Соглашение о качестве предоставляемых
услуг, 25
Стандарт шифрации данных США, 113
т
Трансляция сетевых адресов, 184, 271
IKE, 229
IPSec, 184
Обычная, 184
Троянский конь, 31
У —Ф v
Управление брандмауэром, 78
Фильтрация пакетов, 74
282 Алфавитный указатель
X
Хеллман, Мартин, 44, 84
Хэш, 40
Хэш-код, 40
Цифровая подпись, 63
Хэш-фуикция, 40, 45
НМАС, 94
MD5, 88
SHA, 92
Односторонняя, 47
Хэширование ключей, 57
ц-ч
Целостность данных, 18
Центр сертификации, 65, 187
Цифровая подпись, 39, 45, 53
Червь, 30
Ш
Шамир, Ади, 54
Шифрование-дешифрование, 39
Асимметричное, 39
Асимметричный ключ, 51
Обычное, 39
Основные методы, 40
С открытым ключом, 39
Симметричное, 39
э—я
Энигма, шифровальная машина, 41
Язык разметки гипертекста, 34
V. Блэк
Пройди путь
от ученика
до мастера
Интернет
ПРОТОКОЛЫ безопасности Рекомендуем
книги:
Если вы хотите освоить программирование
для Интернета, серия
это то, что вам нужно для быстрого
обучения и продуктивной работы!
ПрОфг<СИ<Л 1ЛЫСЯ
уучлз
ПОС.рОРНИР
нффекгиенсн о
и маминого
коммерч«к;когосай1а
□ель этой книги — объяснить читателю суть термина
«безопасность в сети Интернет» Она посвяшена описанию
проблем безопасности обмена информацией
и обеспечивающих ее протоколов передачи данных
Поскольку понятие беэопасности в Интернете очень
широко, основное внимание в книге уделяется протоколам
передачи данных, применяемым для обмена данными
между узлами — такими как, например, маршрутизаторы
и серверы При этом рассматривается большинство
применяемых в настоящее время протоколов
Книга предназначена для широкого круга читателей,
не являющихся специалистами в данной облас ги
При этом, однако, предполагается, что читатель знаком
с архитектурой Интернета и структурой протокола TCP/IP
PH
PTR
РИМ
biurtttie
NiHiiMitni
Основы
V» О’МЛСШТПМ
Прея 1МММЦХШМ?
ЛЛИИНК’рНГМ
cap мрнными
CptW 1ШМИ
Прекрасный уч(<й 1ЫЙ
курс лля начтоиих
УРОВЕНЬ ПОЛЬЗОВАТЕЛЯ
опыгьам*
КАТЕГОРИЯ КНИГИ
УЧЕБНОЕ ПОСОБИЕ ИНТЕРНЕТ
Посетите наш Weh-магазин' http //www pfter com