Файл: Основыинформационнойбезопасности.pdf

58
)
4
(
255
)
4
(
0
)
3
(
255
)
3
(
0
)
2
(
255
)
2
(
0
)
1
(
255
)
1
(
0
Q
Q
Q
Q
Q
Q
Q
Q
Q





(2.10)
Данная матрица используется для задания нелинейной функции шифрующего преобразования F(X), где X — 32-битный аргумент. X представляется в виде сцепления
4-х
8-битных слов
0 1
2 3
|
|
|
X
X
X
X
X

, а сама функция задается формулой (+ здесь обо- значает сложение по модулю 2 32
,

— сложение по модулю 2):
)
4
(
)
3
(
)
2
(
)
1
(
0 1
2 3
)
)
((
)
(
X
X
X
X
Q
Q
Q
Q
X
F




(2.11)
Рис. 2.13. Шифр Blowfish
Схема шифрующего преобразования приведена на рис. 2.13.
Расширение секретного ключа KS производится следующим образом.
F
+
Входной блок (сообщение)
Выходной блок (криптограмма)
K
1
+
K
16
…
…
+
F
+
+
+
K
18
K
17

59 1) Начальный массив раундовых ключей K
i
и элементов Q ини- циализируется фиксированными значениями. Например, в шестна- дцатеричном представлении K
1
= 243F6A88 и т. д.
2) K
1
суммируется по модулю 2 с первыми 32-мя битами секрет- ного ключа KS, K
2
— со следующими 32-мя битами и т. д. Когда ключ
KS заканчивается, его начинают использовать сначала. Суммируются только K
i
(без Q).
3) 64-битный блок нулей 0 = (0…0) зашифровывают с помощью
Blowfish на ключах, полученных на шагах 1 и 2: C
0
= Blowfish(0).
4) Раундовые подключи K
1
и K
2
заменяют полученным на шаге 3 значением C
0 5) C
0
шифруют на модифицированных ключах C
1
= Blowfish(C
0
).
6) Раундовые ключи K
3
и K
4
заменяют значением C
1 7) Процесс продолжается, пока не будут получены сначала все пары раундовых ключей (9 пар), а затем все пары элементов матрицы
Q (512 пар).
Таким образом, расширение ключа требует шифрования 521 блока данных. Эта процедура дополнительно осложняет атаку путем перебора ключевого множества, т. к. нарушитель будет вынужден проводить процедуру расширения для каждого возможного ключа.
2.3. УПРАВЛЕНИЕ КРИПТОГРАФИЧЕСКИМИ КЛЮЧАМИ
ДЛЯ СИММЕТРИЧНЫХ ШИФРОВ
Под ключевой информацией понимают совокупность всех клю- чей, действующих в системе. Если не обеспечено достаточно надеж- ное и безопасное управление ключевой информацией, то эффект от применения криптографической защиты данных может быть сведен к нулю: завладев ключами нарушитель сможет получить доступ и к за- щищаемой информации. Процесс управления ключами включает в себя реализацию трех основных функций:
- генерация ключей;
- хранение ключей;
- распределение ключей.

60
Генерация ключей должна производиться таким образом, чтобы предугадать значение ключа (даже зная, как он будет генерироваться) было практически невозможно. В идеальном случае, вероятность вы- бора конкретного ключа из множества допустимых равна 1/N, где N
— мощность ключевого множества (число его элементов).
Для получения ключей используют аппаратные и программные средства генерации случайных значений. Для систем с высокими тре- бованиями к уровню безопасности более предпочтительными счита- ются аппаратные датчики, основанные на случайных физических процессах. В то же время, из-за дешевизны и возможности неограни- ченного тиражирования наиболее распространенными являются про- граммные реализации. Но надо учитывать, что получаемая в этом случае последовательность будет псевдослучайной — если про- граммный генератор повторно запустить с такими же начальными значениями, он выдаст ту же последовательность.
В программных генераторах ключей нередко используют алго- ритмы шифрования и ключи, специально резервируемые для задач генерации. В качестве начальных значений могут браться, например, значения таймера вычислительной системы.
Рекомендуется регулярно проводить замену ключей, используе- мых в системе. В некоторых случаях вместо замены допустимо ис- пользовать процедуру модификации. Модификация ключа — генера- ция нового ключа из предыдущего значения с помощью односторон- ней функции (т. е. такой функции, для которой обратное преобразо- вание вычислить практически невозможно, более подробно см. раздел
2.5). Но в этом случае надо учитывать, что новый ключ безопасен в той же мере, что и прежний, т. к. противник может повторить всю це- почку модификаций.
При организации хранения ключей симметричного шифрования необходимо обеспечить такие условия работы, чтобы секретные клю- чи никогда были записаны в явном виде на носителе, к которому мо- жет получить доступ нарушитель. Например, это требование можно

61 выполнить, создавая иерархии ключей. Трехуровневая иерархия под- разумевает деление ключей на:
- главный ключ;
- ключ шифрования ключей;
- ключ шифрования данных (сеансовый ключ).
Сеансовые ключи — нижний уровень иерархии — используются для шифрования данных и аутентификации сообщений. Для защиты этих ключей при передаче или хранении используются ключи шифро-
вания ключей, которые никогда не должны использоваться как сеан- совые. На верхнем уровне иерархии располагается главный ключ (или мастер-ключ). Его применяют для защиты ключей второго уровня.
Для защиты главного ключа в системах, использующих только сим- метричные шифры, приходится применять не криптографические средства, а, например, средства физической защиты данных (ключ за- писывается на съемный носитель, который после окончания работы изымается из системы и хранится в сейфе, и т. п.). В относительно не- больших информационных системах может использоваться двух- уровневая иерархия ключей (главный и сеансовые ключи).
При распределении ключей необходимо выполнить следующие требования:
- обеспечить оперативность и точность распределения ключей;
- обеспечить секретность распределения ключей.
Распределение ключей может производиться:
- с использованием одного или нескольких центров распределе- ния ключей (централизованное распределение);
- прямым обменом сеансовыми ключами между пользователями сети (децентрализованное распределение ключей).
Децентрализованное распределение ключей симметричного шифрования требует наличия у каждого пользователя большого ко- личества ключей (для связи с каждым из абонентов системы), кото- рые необходимо сначала безопасно распределить, а потом обеспечи- вать их секретность в процессе хранения.

62
Централизованное распределение ключей симметричного шиф- рования подразумевает, что у каждого пользователя есть только один основной ключ для взаимодействия с центром распределения ключей.
Для обмена данными с другим абонентом, пользователь обращается к серверу ключей, который назначает этому пользователю и соответ- ствующему абоненту сеансовый симметричный ключ. Одной из са- мых известных систем централизованного распределения ключей яв- ляется Kerberos.
Протокол Kerberos был разработан в Массачусетском техноло- гическом институте в середине 1980-х годов и сейчас является факти- ческим стандартом системы централизованной аутентификации и распределения ключей симметричного шифрования. Поддерживается операционными системами семейства Unix, Windows (начиная с Win- dows’2000), есть реализации для Mac OS.
Протокол Kerberos обеспечивает распределение ключей сим- метричного шифрования и проверку подлинности пользователей, ра- ботающих в незащищенной сети. Реализация Kerberos — это про- граммная система, построенная по архитектуре «клиент-сервер».
Клиентская часть устанавливается на все компьютеры защищаемой сети, кроме тех, на которые устанавливаются компоненты сервера
Kerberos. В роли клиентов Kerberos могут, в частности, выступать и сетевые серверы (файловые серверы, серверы печати и т. д.).
Серверная часть Kerberos называется центром распределения ключей (англ. «Key Distribution Center», сокр. KDC) и состоит из двух компонент:
- сервер аутентификации (англ. «Authentication Server», сокр.
AS);
- сервер выдачи разрешений (англ. «Ticket Granting Server», сокр. TGS).
Каждому субъекту сети сервер Kerberos назначает разделяемый с ним ключ симметричного шифрования и поддерживает базу данных

63 субъектов и их секретных ключей. Схема функционирования прото- кола Kerberos представлена на рис. 2.14.
Рис. 2.14. Протокол Kerberos
Пусть клиент C собирается начать взаимодействие с сервером
SS (от англ. «Service Server» — сервер, предоставляющий сетевые сервисы). В несколько упрощенном виде протокол предполагает сле- дующие шаги [10,11].
1). C->AS: {c}.
Клиент C посылает серверу аутентификации AS свой идентифи- катор c (идентификатор передается открытым текстом).
2). AS->C: {{TGT}K
AS_TGS
, K
C_TGS
}K
C
,
где K
C
— основной ключ C;
K
C_TGS
— ключ, выдаваемый C для доступа к серверу выдачи разре- шений TGS;
{TGT} —— билет на доступ к серверу выдачи разрешений (англ.
«Ticket Granting Ticket»); {TGT}={c, tgs, t
1
, p
1
, K
C_TGS
}, где tgs — иден- тификатор сервера выдачи разрешений, t
1
— отметка времени, p
1
— период действия билета. Запись {…}K
X
здесь и далее означает, что со- держимое фигурных скобок зашифровано на ключе K
X
5
Kerberos-сервер
(KDC)
Сервер аутентиф.
AS
Сервер выдачи разрешений
TGS
клиент
C
1 2
3 4
Сервер
SS
6
Выполняется 1 раз в момент начала сеанса работы

64
На этом шаге сервер аутентификации AS, проверив, что клиент
C имеется в его базе, возвращает ему билет для доступа к серверу вы- дачи разрешений и ключ для взаимодействия с сервером выдачи раз- решений. Вся посылка зашифрована на ключе клиента C. Таким обра- зом, даже если на первом шаге взаимодействия идентификатор с по- слал не клиент С, а нарушитель X, то полученную от AS посылку X расшифровать не сможет.
Получить доступ к содержимому билета TGT не может не толь- ко нарушитель, но и клиент C, так как билет зашифрован на ключе, который распределили между собой сервер аутентификации и сервер выдачи разрешений.
3). C->TGS: {TGT}K
AS_TGS
, {Aut
1
} K
C_TGS
, {ID},
где {Aut
1
} — аутентификационный блок — Aut
1
= {с,t
2
}, t
2
— метка времени; ID — идентификатор запрашиваемого сервиса (в частности, это может быть идентификатор сервера SS).
Клиент C на этот раз обращается к серверу выдачи разрешений
ТGS. Он пересылает полученный от AS билет, зашифрованный на ключе K
AS_TGS
, и аутентификационный блок, содержащий идентифика- тор c и метку времени, показывающую, когда была сформирована по- сылка.
Сервер выдачи разрешений расшифровывает билет TGT и полу- чает из него информацию о том, кому был выдан билет, когда и на ка- кой срок, ключ шифрования, сгенерированный сервером AS для взаи- модействия между клиентом C и сервером TGS. С помощью этого ключа расшифровывается аутентификационный блок. Если метка в блоке совпадает с меткой в билете, это доказывает, что посылку сге- нерировал на самом деле С (ведь только он знал ключ K
C_TGS
и мог правильно зашифровать свой идентификатор). Далее делается про- верка времени действия билета и времени оправления посылки 3. Ес- ли проверка проходит, и действующая в системе политика позволяет клиенту С обращаться к клиенту SS, тогда выполняется шаг 4.
4). TGS->C: {{TGS}K
TGS_SS
,K
C_SS
}K
C_TGS
,

65 где K
C_SS
— ключ для взаимодействия C и SS, {TGS} — от англ. «Tick- et Granting Service» — билет для доступа к SS (обратите внимание, что такой же аббревиатурой в описании протокола обозначается и сервер выдачи разрешений). {TGS} ={с,ss,t
3
,p
2
, K
C_SS
}.
Сейчас сервер выдачи разрешений TGS посылает клиенту C ключ шифрования и билет, необходимые для доступа к серверу SS.
Структура билета такая же, как на шаге 2: идентификатор того, кому выдали билет; идентификатор того, для кого выдали билет; отметка времени; период действия; ключ шифрования.
5). C->SS: {TGS}K
TGS_SS
, {Aut
2
} K
C_SS
,
где Aut
2
={c,t
4
}.
Клиент C посылает билет, полученный от сервера выдачи раз- решений, и свой аутентификационный блок серверу SS, с которым хочет установить сеанс защищенного взаимодействия. Предполагает- ся, что SS уже зарегистрировался в системе и распределил с сервером
TGS ключ шифрования K
TGS_SS
. Имея этот ключ, он может расшифро- вать билет, получить ключ шифрования K
C_SS
и проверить подлин- ность отправителя сообщения.
6). SS->C: {t
4
+1}K
C_SS
Смысл последнего шага заключается в том, что теперь уже SS должен доказать C свою подлинность. Он может сделать это, показав, что правильно расшифровал предыдущее сообщение. Вот поэтому SS берет отметку времени из аутентификационного блока C, изменяет ее заранее определенным образом (увеличивает на 1), шифрует на ключе
K
C_SS
и возвращает C.
Если все шаги выполнены правильно, и все проверки прошли успешно, то стороны взаимодействия C и SS, во-первых, удостовери- лись в подлинности друг друга, а во-вторых, получили ключ шифро- вания для защиты сеанса связи — ключ K
C_SS
Нужно отметить, что в процессе сеанса работы клиент проходит шаги 1 и 2 только один раз. Когда нужно получить билет на доступ к другому серверу (назовем его SS1), клиент С обращается к серверу

66 выдачи разрешений TGS с уже имеющимся у него билетом, т. е. про- токол выполняется начиная с шага 3.
При использовании протокола Kerberos компьютерная сеть ло- гически делится на области действия серверов Kerberos. Kerberos-
область — это участок сети, пользователи и серверы которого заре- гистрированы в базе данных одного сервера Kerberos (или в одной ба- зе, разделяемой несколькими серверами). Одна область может охва- тывать сегмент локальной сети, всю локальную сеть или объединять несколько связанных локальных сетей. Схема взаимодействия между
Kerberos-областями представлена на рис. 2.15.
Рис. 2.15. Взаимодействие между Kerberos-областями
Для взаимодействия между областями должна быть осуществ- лена взаимная регистрация серверов Kerberos, в процессе которой сервер выдачи разрешений одной области регистрируется в качестве клиента в другой области (т. е. заносится в базу сервера аутентифика- ции и разделяет с ним ключ).
После установки взаимных соглашений, клиент из области 1
(пусть это будет K
11
) может установить сеанс взаимодействия с кли- ентом из области 2 (например, К
21
). Для этого K
11
должен получить у
Сервер аутентиф.
Сервер выдачи разрешений
KDC1
Клиент
K
11
Сервер выдачи разрешений
Сервер аутентиф.
Клиент
KDC2
Клиент
K
21
Область действия
KDC1
Область дей- ствия KDC2
Клиент
KDC1
KDC2

67 своего сервера выдачи разрешений билет на доступ к Kerberos- серверу, с клиентом которого он хочет установить взаимодействие (на рис. 2.15 это сервер KDC2). Полученный билет содержит отметку о том, в какой области зарегистрирован владелец билета. Билет шифру- ется на ключе, разделенном между серверами KDC1 и KDC2. При успешной расшифровке билета удаленный Kerberos-сервер может быть уверен, что билет выдан клиенту Kerberos-области, с которой установлены доверительные отношения. Далее протокол работает, как обычно.
Кроме рассмотренных, Kerberos предоставляет еще ряд допол- нительных возможностей. Например, указанный в структуре билета параметр p (период времени) задается парой значений «время начала действия» — «время окончания действия», что позволяет получать билеты отложенного действия.
Имеется тип билета «с правом передачи», что позволяет, напри- мер, серверу выполнять действия от имени обратившегося к нему клиента.