Таненбаум Э. Распределенные системы. Принципы и парадигмы

Подождите немного. Документ загружается.

8.4. Управление защитой 511

катов. Вместо этого клиент всегда должен связываться с сертифицирующей ор-

ганизацией и проверять годность открытого ключа. Соответственно, сертифици-

рующая организация должна постоянно быть на связи.

На практике сертификаты обладают ограниченным сроком жизни. В случае

Интернет-приложений время жизни часто составляет один год

[432].

Такой под-

ход требует регулярной публикации CRL и проверки срока действия сертифика-

та. Практика показывает, что приложения клиентов редко заглядывают в CRL,

автоматически считая сертификаты годными до окончания их срока действия.

этом смысле практика обеспечения защиты в Интернете имеет массу возмож-

ностей для совершенствования.

8.4.2. Управление защищенными группами

Множество систем защиты пользуются услугами специальных служб, таких как

центры распространения ключей (KDC) или сертифицирующие организации.

Работа этих служб в распределенных системах вызывает различные проблемы.

Во-первых, им необходимо доверие. Чтобы доверие к службам защиты повыша-

лась,

им необходимо демонстрировать высокую степень защищенности от раз-

личных типов атак. Так, например, как только сертифицирующие организации

оказываются скомпрометированными, становится невозможно проверить пра-

вильность открытого ключа, что лишает смысла всю систему защиты.

С другой стороны, необходимо также, чтобы весь этот набор служб защиты

имел высокую доступность. Так, если рассматривать KDC, всякий раз, когда два

процесса хотят организовать защищенный канал связи, минимум один из них

должен связаться с KDC, чтобы получить общий секретный ключ. Если центр

KDC в этот момент недоступен, без альтернативных методов создания ключа, та-

ких как обмен ключами Диффи—Хеллмана, установить безопасное соединение

невозможно.

Решить проблему высокой доступности помогает репликация. Однако реплика-

ция повышает уязвимость сервера перед лицом атак на защиту. Мы уже обсужда-

ли,

как путем разделения секрета членами группы организуется защищенное груп-

повое взаимодействие. При таком подходе ни один из членов группы не способен

самостоятельно скомпрометировать сертификат, что значительно повышает защи-

ту группы в целом. Остается обсудить только вопрос реального управления груп-

пой реплицируемых серверов. В [377] предлагается для этого следующее решение.

Итак, требуется подтвердить, что процесс, который просит предоставить ему

членство в группе G, не в состоянии нарушить целостность группы. Предполага-

ется, что у группы G имеется закрытый ключ

CKG,

который используется совме-

стно всеми ее членами для шифрования сообщений внутри группы. Кроме того,

они используют также пару открытый/закрытый ключ

(K.G}

KG)

ДЛЯ

связи с про-

цессами, не входящими в число членов группы.

Когда процесс Р хочет войти в число членов группы G, он посылает запрос/Т?

на прием в члены, в котором определяет

Р,

локальное время отправки запро-

са Т по часам Р, общую заготовку ответа RP и сгенерированный закрытый ключ

Kp^G-

RP и

Kp^G

зашифрованы с использованием открытого ключа группы iCc, как

512 Глава 8. Защита

показано в сообщении

на рис. 8.32. ЗапросУР на прием в члены группы подпи-

сывается Р и посылается вместе с сертификатом, содержащим открытый ключ Р.

Для обозначения того, что сообщение М подписано субъектом Л, мы используем

традиционную запись [М]л.

[G.

Р. т. к^ (RP. Кр^)]р. [Р. к:],

PJCA

[Р.М.СК^ФКР.СКд(КС5)]Кд

KpG(N)

Рис. 8.32. Безопасное включение в группу нового члена

Когда член группы Q получает запрос на прием в группу нового члена, он

первым делом идентифицирует Р, после чего связывается с другими членами

группы, чтобы обсудить, следует ли принять Р в группу. Аутентификация Р про-

исходит обычным путем посредством сертификата. Чтобы гарантировать, что

сертификат в момент отправки был действителен, используется отметка времени Г

(отметим, что нам необходима уверенность, что время не фальсифицировано).

Член группы Q проверяет подпись сертифицирующей организации, после чего

извлекает открытый ключ Р из сертификата для проверки подлинности

J/?.

Для

проверки того, все ли члены группы готовы принять в нее Р, используется внут-

ренний протокол группы.

Если члены группы согласны принять Р в группу, Q возвращает сообщение с

согласием группы СЛ, показанное на рис. 8.32 как сообщение 2, которое иденти-

фицирует Р и содержит одноразовый запрос N. Для шифрования коммуникаци-

онного ключа группы

CKQ

используется заготовка ответа RP. Кроме того, Р ну-

жен также закрытый ключ группы

К'су

который зашифрован при помощи СКс.

Сообщение GA подписывается Q при помощи ключа

Кр^с-

Процесс Р может теперь идентифицировать Q, поскольку только истинный

член группы может знать секретный ключ

Кр^с-

Случайное число

Л^

этом прото-

коле для обеспечения защиты не используется, просто когда Р посылает назад

число

Л^,

зашифрованное ключом

Кр^с

(сообщение 3),

узнает, что процесс Р

по-

лучил все необходимые ключи и действительно вошел в группу.

Отметим, что вместо использования заготовки ответа RP процессы Р и

так-

же могут зашифровать СКс открытым ключом Р. Однако поскольку заготовка

RP требуется только один раз, а именно для шифрования коммуникационного

ключа группы в сообщении GA, вариант с заготовкой более безопасен. Если за-

крытый ключ Р будет перехвачен, это может привести и к расшифровке

СКс

что нарушит секретность всего группового взаимодействия.

8.4.3. Управление авторизацией

Управление защитой в распределенных системах также включает в себя и управ-

ление правами доступа. Ранее мы старались избежать разговора о том, каким об-

8.4. Управление защитой 513

разом пользователям

или

группам пользователей назначаются права доступа

каким образом затем осуществляется поддержка прав доступа, исключающая

их

фальсификацию. Настало время заполнить эти пробелы.

В нераспределенных системах управлять правами доступа относительно

не-

сложно. Когда

системе добавляется новый пользователь,

он

получает базовый

набор прав, например,

на

создание файлов

вложенных каталогов

определен-

ном каталоге, создание процессов, использование процессорного времени

и т. д.

Другими словами,

на

одной конкретной машине создается учетная запись поль-

зователя,

все

права

для

которой заранее расписаны системным администрато-

ром.

В распределенных системах задача усложняется тем фактом, что ресурсы раз-

бросаны

по

нескольким машинам. Если следовать подходу, принятому

нерас-

пределенных системах, необходимо создавать учетные записи всех пользовате-

лях

на

всех машинах.

сущности, именно такой подход используется

сетевых

операционных системах. Задачу можно немного упростить, создав одну учетную

запись

на

центральном сервере.

этим сервером можно будет консультировать-

ся всякий

раз,

когда пользователь запросит доступ

определенным ресурсам

или машинам.

Мандаты

сертификаты атрибутов

Наилучший подход, чаще всего применяемый

распределенных системах,

—

это

использование мандатов. Как мы уже говорили раньше,

мандат {capability) —

это

нефальсифицируемая структура данных, относящаяся

некоторому ресурсу

точно определяющая права доступа владельца мандата

этому ресурсу. Сущест-

вуют различные реализации мандатов. Здесь мы кратко обсудим реализацию, ис-

пользуемую

операционной системе Amoeba

[448].

Система Amoeba

это одна

из

первых объектно-ориентированных распреде-

ленных систем. Распределенные объекты

ней являются удаленными. Другими

словами, объект располагается на сервере,

клиентам разрешен прозрачный дос-

туп

этому объекту через заместителя.

Для

обращения

операциям объекта

клиент посылает мандат локальной операционной системе, которая находит сер-

вер,

содержащий объект,

посылает этому серверу вызов RPC.

Мандат

—

это

128-битный идентификатор, внутренняя структура которого

показана на рис. 8.33. Первые 48 бит инициализируются сервером объекта, когда

этот объект создается,

содержат машинно-независимый идентификатор серве-

ра, известный под названртем

порта сервера

{serverport). Для поиска машины,

на

которой

настоящее время размещен сервер. Amoeba использует широковеща-

тельную рассылку.

Порт сервера

(48

бит) Объект

(24

бит)

Права

бит)

Проверка

(48

бит)

Рис. 8.33. Мандат системы Amoeba

Следующие

бита используются

для

идентификации объекта

на

данном

сервере. Отметим, что порт сервера вместе с идентификатором объекта образуют

514 Глава 8. Защита

72-битный уникальный глобальный идентификатор каждого объекта Amoeba.

Следующие 8 бит идентифицируют права доступа владельца мандата. И нако-

нец, 48-битное поле проверки, как мы покажем далее, требуется для того, чтобы

сделать подделку мандата невозможной.

Когда создается объект, его сервер выбирает случайное поле проверки и запи-

сывает его как в мандат, так и в собственную внутреннюю таблицу. Все биты

прав доступа в мандате исходно выставлены в единицу, и это тот мандат вла-

дельца

{owner

capability),

который возвращается клиенту. Когда мандат пересы-

лается обратно на сервер в составе запроса на совершение операции, поле про-

верки проверяется на соответствие его значению, хранящемуся на сервере.

Для создания ограниченного мандата клиент должен передать мандат серверу

с указанием новой битовой маски в соответствии с новыми правами доступа.

Сервер берет исходное поле проверки из своих таблиц, производит операцию ис-

ключающего ИЛИ (XOR) над мандатом и новыми правами (которые представ-

ляют собой подмножество прав мандата владельца) и пропускает результат че-

рез одностороннюю функцию.

Затем сервер создает новый мандат с тем же значением поля объекта, новыми

битами прав в поле прав и результатом односторонней функции в поле провер-

ки.

Новый мандат возвращается тому клиенту, который захотел его получить.

Клиент, если пожелает, может переслать новый мандат другому процессу.

Метод создания ограниченных мандатов иллюстрирует рис. 8.34. В этом при-

мере владелец отключает все права, кроме одного. Такой ограниченный мандат,

например, может разрешать чтение объекта и ничего более. Значения поля прав

для разных типов объектов могут быть разные, поскольку набор разрешенных

операций сам может различаться от одного типа объекта к другому.

Мандат

Порт Объект

11111111

Предоставление

новых прав

00000001

Исключающее ИЛИ

Ограниченный мандат

Порт

Объект 00000001 f(С 000000001)

Однонаправленная

функция

Рис, 8.34. Создание ограниченного мандата из мандата владельца

Когда ограниченный мандат приходр1Т на сервер, сервер по полю прав обнару-

живает, что перед ним не мандат владельца, поскольку хотя бы один из битов

сброшен. После этого сервер считывает из таблицы исходное случайное число,

производит операцию исключающего ИЛИ (XOR) над ним и полем прав ман-

8.4. Управление защитой 515

дата, после чего пропускает результат через одностороннюю функцию. Если ре-

зультат соответствует полю проверки, мандат считается действительным.

Из алгоритма должно быть ясно, что пользователь, попытавшись добавить се-

бе права, которых он не имеет, просто испортит мандат. Инвертировать поле

проверки ограниченного мандата для получения исходного аргумента (С XOR

00000001,

как показано на рис. 8.34) невозможно, поскольку функция / односто-

ронняя. Посредством подобной криптографической техники мандаты защи-

щаются от подделки. Отметим, что действие функции /, по существу, аналогично

вычислению дайджеста сообщений, о котором мы говорили ранее. Любое из-

менение исходного сообщения, такое как инверсия битов, будет немедленно

замечено.

Более обобщенный вариант мандата, который используется в современных

распределенных системах, — это сертификат атрибута {attribute certificate),

отличие от ранее обсуждавшихся сертификатов, которые требуются для под-

тверждения открытых ключей, сертификаты атрибутов служат для хранения пар

{атрибут,

значение), относящихся к определенным элементам. В частности, сер-

тификаты атрибутов могут использоваться для хранения прав доступа к опреде-

ленным ресурсам, которыми обладает владелец сертификата.

Как и другие сертификаты, сертификаты атрибутов выдаются специальными

сертифицирующими организациями, которые называются

организациями

серти-

фикации атрибутов {attribute certification

authorities).

Как и в ситуации с мандата-

ми системы Amoeba, эти организации соответствуют серверам объектов. Обычно,

однако, организация сертификации атрибутов и сервер, содержащий сущность,

для которой создается сертификат, не совпадают. Права доступа, перечисленные

в сертификате, подписываются организацией сертификации атрибутов.

Делегирование

Обсудим теперь следующую проблему. Пользователь хочет напечатать большой

файл, к которому имеет доступ только на чтение. Чтобы не затруднять жизнь ок-

ружающим, пользователь посылает запрос на сервер печати, требуя начать печать

не раньше двух часов ночи. Вместо того чтобы посылать на принтер сам файл,

пользователь передает принтеру имя файла, с тем чтобы он мог сам скопировать

этот файл в свой каталог спулинга, когда ему это понадобится.

Хотя эта схема кажется великолепной, в ней имеется одна серьезная пробле-

ма: принтер обычно не имеет необходимых привилегий на доступ к указанному

файлу. Другими словами, если не предусмотреть никакого специального меха-

низма, то как только сервер печати захочет считать файл, чтобы напечатать его,

система откажет серверу в доступе к этому файлу. Проблему можно решить, ес-

ли пользователь сможет временно

делегировать

{delegated) серверу печати свои

права доступа к файлу.

Делегирование прав доступа

—

это один из весьма важных приемов реализа-

ции защиты в компьютерных системах, и в частности в распределенных систе-

мах. Основная идея делегирования проста: если иметь возможность передавать

определенные права доступа от одного процесса к другому, то проще будет рас-

пределять работу между несколькими процессами без ослабления защиты ресур-

516 Глава 8. Защита

сов.

В случае распределенных систем процессы могут запускаться на разных

машинах и даже в разных административных доменах (о них мы говорили, обсу-

ждая систему Globus). Делегирование позволяет избежать излишней затраты ре-

сурсов, поскольку защиту часто удается реализовать локально.

Существует несколько способов реализации делегирования. Традиционный

подход, описанный в

[315],

предполагает наличие заместителя. Заместитель

{proxy) в контексте защиты компьютерных систем представляет собой маркер,

который позволяет своему владельцу работать с теми же самыми ограниченны-

ми правами и привилегиями, которые имел субъект, выдавший этот маркер. (От-

метим, что данный заместитель отличается от заместителя

—

синонима заглуш-

ки на стороне клиента\ Хотя мы стараемся избегать переопределения терминов,

для «заместителя» мы в данном случае делаем исключение, поскольку этот тер-

мин слишком активно используется, чтобы это можно было игнорировать.) Про-

цесс может создать заместителя, в лучшем случае с такими же правами доступа

и привилегиями, какие имеет он сам. Если процесс создает нового заместителя

на основе одного из тех, которыми он владеет в данный момент, порожденный

заместитель получает как минимум такие же ограничения, как оригинальный,

а возможно и большие.

До обсуждения общей схемы делегирования рассмотрим два частных случая.

Во-первых, делегирование

—

относительно простое дело, если Алиса всех знает.

Если она хочет делегировать права Бобу, ей достаточно создать сертификат о

присвоении Бобу прав R, приблизительно такой: [Л, 5, ЩА- ЕСЛИ Боб хочет пере-

дать часть этих прав Чарли, он должен предложить Чарли войти в контакт с Али-

сой и запросить соответствующий сертификат у нее.

Во-вторых, Алиса может просто создать сертификат, гласящий, что его предъ-

явитель обладает правами R. Однако в этом случае придется защитить этот серти-

фикат от несанкционированного копирования, как мы это делали при защищенной

передаче мандатов от процесса к процессу. Схема Ньюмана (Neuman) в состоя-

нии справиться с подобными задачами, кроме того, эта схема снимает для Алисы

обязательное требование знать каждого, кому она захочет делегировать права.

По схеме Ньюмана заместитель, как показано на рис. 8.35, состоит из двух

частей. Пусть А

—

процесс, который создает заместителя. Первая часть замести-

теля

—

это множество

С =

{R,

Sp,-oxy}y

состоящее из набора прав доступа R, кото-

рые делегируются Л вместе с общеизвестной частью секрета, необходимого для

аутентификации держателя сертификата. Ниже мы рассмотрим, как использует-

ся

Sproxy

Сертификат имеет от процесса А подпись sig(A, С) для защиты от изме-

нений. Вторая часть заместителя содержит вторую часть секрета, обозначенную

как

Sp,rjxy

Важно отметить, что часть

Sproxy

защищена от вскрытия в случае деле-

гирования прав другому процессу.

Другой взгляд на заместителя состоит в следующем. Если Алиса хочет деле-

гировать часть своих прав Бобу, она создает список прав (R), которыми должен

Отметим также, что в данном случае термин

заместитель

(proxy) не имеет отношения к термину

прокси

(proxy), который используется для определения

прокси-гилюза

(proxy

gateway),

или

прокси-

сервера

(proxy

server).

—

Примеч.

ред.

8.4. Управление защитой 517

обладать Боб. Подписывая список, она защищает его от взлома Бобом. Однако

подписанного списка прав часто бывает недостаточно. Если Боб захочет реали-

зовать свои права, ему может понадобиться доказать, что он действительно полу-

чил этот список от Алисы, а не своровал его где-нибудь. Поэтому Алиса задает

весьма неприятный вопрос

Sproxyy

ответ на который знает только она

(Sproxy)-

Каж-

дый может легко проверить правильность ответа, задав вопрос. Вопрос добавля-

ется к списку еще до того, как Алиса поставит на нем свою подпись.

Сертификат

'-'proxy

sig(A. {R. Sjroxy}) 1

1 ^ proxy

Права доступа Открытая часть

секрета

Подпись

Скрытая часть

секрета

Рис. 8.35. Обобщенная структура заместителя, используемого

при делегировании прав

При делегировании части своих прав Алиса предоставляет подписанный спи-

сок этих прав вместе с вопросом Бобу. Также она отправляет Бобу ответ, уверив-

шись предварительно, что никто не сможет его перехватить. Теперь у Боба есть

подписанный Алисой список прав, который он может передать при необходимо-

сти,

скажем, Чарли. Чарли задаст ему вопрос из конца списка. Если Боб сможет

ему ответить, Чарли будет уверен, что Алиса действительно делегировала ему

свои права.

Важное свойство этой схемы состоит в том, что Алисе ни с кем не нужно кон-

сультироваться. На деле Боб может решить передать права или их часть Дейву.

Делая это, он также сообщит Дейву ответ на вопрос, чтобы Дейв мог подтвер-

дить,

что список прав был передан ему кем-то из законных владельцев. Алисе

про Дейва ничего знать не понадобится.

Протокол делегирования и реализации прав иллюстрирует рис. 8.36. Допус-

тим, что Алиса и Боб совместно используют секретный ключ

КА,В,

которым шиф-

руют отправляемые друг другу сообщения. Так, Алиса первой отправляет Бобу

сертификат С= {/?,

Sp^xyji

подписанный sig(A, С) и обозначаемый далее как [i?,

Slroxy]A-

Шифровать это сообщение нет необходимости, его вполне можно отпра-

вить и простым текстом. Шифруется только закрытая часть секрета, обозначен-

ная на рисунке как

K/[,B(Spwxy)

в сообщенрш 1.

[R. SproxylA. КА,в(Зргоху)

[К, SproxyJA

y(N)

Рис. 8.36. Использование заместителя для делегирования прав и их подтверждения

518 Глава 8. Защита

Теперь допустим, что Боб хочет выполнить операцию над объектом, располо-

женным на определенном сервере. Считаем, что Алиса имеет право на проведе-

ние подобной операции и делегировала это право Бобу. Таким образом. Боб пе-

редает серверу свои верительные грамоты в виде подписанного сертификата [R,

'^ proxy \Л\

В этот момент сервер может проверить, не был ли сертификат С сфальсифи-

цирован: любые изменения списка прав или секретного вопроса будут обнаруже-

ны,

поскольку и тот и другой подписаны Алисой. Однако сервер пока еще не

знает, является ли Боб законным владельцем сертификата. Чтобы проверить это,

сервер должен использовать секрет, который попал к Бобу вместе с С. Существу-

ет несколько способов реализации

Sproxy

Sp^xy.

Предположим, например, что

S^wxy

— открытый, а

Sprox-y

— соответствующий закрытый ключ. Сервер может

проверить Боба, послав ему случайное число Л^, зашифрованное ключом

Spmxy

Расшифровав

Sp,oxy

(А^) и вернув N, Боб докажет, что знает секрет, а значит, яв-

ляется законным владельцем сертификата. Существуют и другие способы реали-

зации безопасного делегирования прав, но основная идея всегда одна и та же:

нужно показать, что вы знаете секрет.

8.5. Пример

—

Kerberos

Теперь уже должно быть понятно, что обеспечение защиты в распределенных

системах

—

задача не из простых. Проблемы возникают из-за того, что защита

должна быть всеобъемлющей, если в ней встретятся слабые места, то легко пре-

одолимой становится защита всей системы. Чтобы помочь разработчику распре-

деленных систем поддерживать мириады правил защиты, было создано несколь-

ко систем поддержки защиты, которые можно использовать в качестве базы для

дальнейших разработок. Одной из часто применяемых систем подобного рода яв-

ляется Kerberos [239, 433].

Система Kerberos была разработан в M.I.T. и основывается на протоколе

аутентификации Нидхема—Шредера (Needham—Schroeder), который мы ранее

рассматривали. В настоящее время используются две версии Kerberos, версия 4

и версия 5. Обе версии концептуально одинаковы, но версия 4 проще для пони-

мания. Версия 5 по сравнению с версией 4 содержит множество дополнительных

возможностей и поэтому на практике обычно предпочтительнее. Мы сосредото-

чимся исключительно на проблемах аутентификации.

Kerberos можно рассматривать как безопасную систему, которая помогает

клиентам создавать защищенный канал связи с сервером. Защита реализуется

при помощи общих секретных ключей. В системе имеются два компонента. Сер-

вер аутентификации (Authentication

Server,

AS) отвечает за обработку запросов

на организацию соединения, присылаемых пользователями. AS идентифицирует

пользователей и предоставляет им ключи, которые можно использовать для ор-

ганизации защищенных каналов связи с сервером. Создание защищенных кана-

лов производится

службой предоставления талонов

(Ticket

Granting

Service,

TGS),

TGS рассылает специальные сообщения, известные под названием

талонов

(tickets),

8.5. Пример — Kerberos 519

которые используются, чтобы сообщить серверу, что клиент — действительно

тот, за кого он себя выдает. Ниже мы приведем конкретные примеры талонов.

Давайте рассмотрим, как Алиса входит в распределенную систему, защищен-

ную системой Kerberos, и устанавливает защищенный канал связи с сервером

Боба. Для входа в систему Алиса может использовать любую свободную рабо-

чую станцию. Рабочая станция отсылает ее имя серверу AS, который возвращает

сеансовый ключ KAJGS И талон, который она должна будет передать службе TGS.

Талон, возвращенный AS, содержит идентификатор Алисы и созданный сек-

ретный ключ, который Алрюа и TGS могут использовать для связи между собой.

Сам талон будет передан Алисой службе TGS, поэтому важно, чтобы никто, кро-

ме TGS, не мог его прочитать. Для этого талон шифруется секретным ключом

KASJGS, которым совместно пользуются AS и TGS.

Эта часть процедуры входа в систему соответствует сообщениям 1, 2 и 3 на

рис.

8.37. Сообщение 1 на самом деле не является сообщением, оно соответству-

ет вводу Алисой на рабочей станции своего входного имени {login). Сообщение 2

содержит это имя и посылается AS. Сообщение 3 содержит сеансовый ключ

J^AjGs

талон KASJGS{A, KAJGS)- ДЛЯ обеспечения защиты сообщение 3 шифрует-

ся секретным ключом KAAS^ совместно используемым Алисой и AS.

Входное1

имя 1

Введите

пароль

л Пароль [

го

а.

^ 31

^ 7

KA,AS(^^A.TGS' ^AS.TGS (А. KAJGS))

Кдз TGS (А-

KA.TGS)'

^« Кд T(3s(t)

к Ш к ^ ^^ /А w \

'^A.TGSV'^' '^А.В

л '^в ,TGSV^' '^А.В^ 1

со

Рис. 8.37. Аутентификация

системе Kerberos

После того как рабочая станция получает ответ от AS, она предлагает Алисе

ввестР! пароль (сообщение 4), который будет использован для последующей гене-

рации секретного ключа KA^S (относительно несложно взять строку символов,

применить к ней криптографическое хэширование и использовать первые 56 бит

хэша в качестве секретного ключа). Отметим, что подобный подход имеет не толь-

ко то преимущество, что пароль Алисы никогда не передается по сети в откры-

том виде; он даже временно не сохраняется на рабочей станции. Более того, сразу

после создания общего ключа KA,AS рабочая станция получает сеансовый ключ

KAJGS И может забыть о пароле Алисы, пользуясь только секретным общим клю-

чом KA,AS-

После этой части аутентификации Алиса может считать себя вошедшей в

систему. Теперь она может связываться с другими пользователями и серверами.

Если она хочет пообщаться с Бобом, она запрашивает у TSG сеансовый ключ

для работы с Бобом (сообщение 6 на рис. 8.37). Тот факт, что Алиса обладает та-

520

Глава

Защита

лоном KAS,TGS(A, KAJGS), подтверждает, что это Алиса. TGS возвращает ей сеансо-

вый ключ

KA,BI

ВНОВЬ упакованный в талон, который Алиса позже перешлет Бобу.

Сообщение 6 также содержит отметку времени t, зашифрованную секретным

ключом, который совместно используется Алисой и TGS. Эта отметка времени

требуется для того, чтобы Чак не смог злонамеренно послать сообщение 6 еще

раз и попытаться организовать защищенный канал с Бобом. TGS проверяет от-

метку времени, прежде чем возвращать Алисе талон. Если указанное в отметке

время отличается от текущего времени более чем на несколько минут, запрос на

талон будет оставлен без ответа.

Как показано на рис. 8.38, организация защищенного канала связи с Бобом

теперь проста и не вызывает никаких сложностей. Сначала Алиса вместе с за-

шифрованной отметкой времени посылает Бобу сообщение, содержащее талон,

который она получила от TGS. Расшифровав талон. Боб узнает, что с ним обща-

ется Алиса, поскольку создать талон могла только служба TGS. Кроме того, он

получает секретный ключ

iC^.s,

который позволяет ему проверить отметку време-

ни.

После этого Боб понимает, что общается с именно Алисой. Ответив посыл-

кой сообщения

КА,В{^^

О» Боб убеждает Алису, что это действительно он.

^B.TGS (А. Кдз), Кдз (t)

КА.В(*+Ч)

Рис.

8.38.

Создание защищенного канала

в системе Kerberos

8.6. Пример

—

SESAME

Давайте теперь рассмотрим другую систему защиты, которая похожа на Kerberos,

но в ней используется комбинация криптографии с открытым ключом и общих

секретных ключей. Проект SESAME был начат по совместной инициативе не-

скольких крупных европейских компаний с целью разработки стандартов защи-

ты открытых систем. SESAME

—

это акроним слов Secure

European

System for

Application

in a

Multi-vendor Environment {Европейская система защиты

приложе-

ний,

работающих в разнородной

среде).

Первая реализация SESAME была созда-

на в 1991 году, четвертая и наиболее известная существует с 1995 года и известна

также под названием SESAME V4. Мы начнем с обзора основных компонентов,

затем обсудим процесс авторизации, выполняемый при помощи сертификатов

атрибутов. Вместо того чтобы рассматривать в деталях все алгоритмы, мы сосре-

доточим наше внимание на общих вопросах взаимодействия между компонента-

ми,

которые иллюстрируют архитектуру защищенных систем. Обзор системы

SESAME можно найти в

[342].