О новом подходе к распределению ключей было рассказано в [68], в одной статье говорилось о телефонах, "перепрограммируемых раз в год по безопасному телефонному каналу", что весьма вероятно предполагает использование протокола проверки сертификатов, аналогичного описанному [в разделе 24.3], который минимизирует для телефонов необх о-димость общаться с центром управления ключами . Последние известия были более информативными , в них рассказывалось о системе управления ключами, названной FIREFLY, которая [1341] "разработана на базе технологии открытых ключей и используется для распределения ключей шифрования попарного трафика". И это описание, и свидетельские показания, данные Конгрессу США Ли Ньювиртом (Lee Neuwirth) из Cylink [1164] предполагают использование комбинации обмена ключами и сертификатами, аналогичного используемому в безопасных телефонах ISDN. Весьма вероятно, что FIREFLY также основана на возведении в степень.

STU-III производятся AT&T и GE. За 1994 год было выпущено 300000-400000 штук. Новая версия, Secure Terminal Equipment (STE, Безопасный терминал), будет работать по линиям ISDN.

24.5 KERBEROS

Kerberos представляет собой разработанный для сетей TCP/IP протокол проверки подлинности с доверенной третьей стороной. Служба Kerberos, работающая в сети, действует как доверенный посредник, обеспечивая безопасную сетевую проверку подлинности, дающую пользователю возможность работать на нескольких маш и-нах сети. Kerberos на симметричной криптографии (реализован DES, но вместо него можно использовать и другие алгоритмы). При общении с каждым объектом сети Kerberos использует отличный общий секретный ключ, и знание этого секретного ключа равносильно идентификации объекта .

Kerberos был первоначально разработан в МТИ для проекта Афина . Модель Kerberos основана на протоколе Needham-Schroeder с доверенной третьей стороной (см. раздел 3.3) [1159]. Оригинальная версия Kerberos, Версия 4, определена в [1094, 1499]. (Версии с 1 по 3 б1ли внутренними рабочими версиями.) Версия 5, модификация Версии 4, определена в [876, 877, 878]. Лучшим обзором по Kerberos является [1163]. Другие обзорные статьи - [1384, 1493], использование Kerberos в реальном мире хорошо описано в [781, 782].

Модель Kerberos

Базовый протокол Kerberos был схематично описан в разделе 3.3. В модели Kerberos существуют расположенные в сети объекты - клиенты и серверы. Клиентами могут быть пользователи, но могут и независимые пр о-граммы, выполняющие следующие действия: загрузку файлов, передачу сообщений, доступ к базам данных, доступ к принерам, получение административных привилегий, и т.п.

Kerberos хранит базу данных клиентов и их секретных ключей . Для пользователей-людей секретный ключ является зашифрованным паролем. Сетевые службы, требующие проверки подлинности, и клиенты, которые хотят использовать эти службы, регистрируют в Kerberos свои секретные ключи.

Так как Kerberos знает все секретные ключи, он может создавать сообщения, убеждающие один объект в подлинности другого. Kerberos также создает сеансовые ключи, которые выдаются клиенту и серверу (или двум клиентам) и никому больше. Сеансовый ключ используется для шифрования сообщений, которыми обменив а-ются две стороны, и уничтожается после окончания сеанса .

Для шифрования Kerberos использует DES. Kerberos версии 4 обеспечивал нестандартный, слабый режим проверки подлинности - он не мог определить определенный изменения шифротекста (см. раздел 9.10). Kerberos версии 5 использует режим CBC.

1. Запрос мандата на выделение мандата

2. Мандат выделения мандата

3. Запрос мандата сервера

4. Мандат сервера

5. Запрос услуги

Рис. 24-1. Этапы проверки подлинности Kerberos

Как работает Kerberos

В этом разделе рассматривается Kerberos версии 5. Ниже я обрисую различия между версиями 4 и 5 . Протокол Kerberos прост (см. 23rd). Клиент запрашивает у Kerberos мандат на обращение к Службе выделения мандатов (Ticket-Granting Service, TGS). Этот мандат, зашифрованный секретным ключом клиента, посылается

клиенту. Для использования конкретного сервера клиент запрашивает у TGS мандат на обращение к серверу. Если все в порядке, TGS посылает мандат клиенту. Затем клиент предъявляет серверу этот мандат вместе с уд о-стоверением. И снова, если атрибуты клиента правильны, сервер предоставляет клиенту доступ к услуге.

Табл. 24-1. Таблица сокращений Kerberos

Kerberos использует два типа атрибутов: мандаты и удостоверения. (В дальнейшем в этом разделе будет использоваться нотация, используемая в документах Kerberos - см. 23-й.) Мандат используется для безопасной передачи серверу личности клиента, которому выдан этот мандат . В нем также содержится информация, которую сервер может использовать для проверки того, что клиент, использующий мандат, - это именно тот клиент, которому этот мандат был выдан. Удостоверение - это дополнительный атрибут, предъявляемый вместе с ма н-датом. Мандат Kerberos имеет следующую форму:

Tc,s = s, {с, a, v, Kc,s}Ks.

Мандат хорош для одного сервера и одного клиента. Он содержит имя клиента, его сетевой адрес, имя се р-вера, метку времени и сеансовый ключ. Эта информация шифруется секретным ключом сервера. Если клиент получил мандат, он может использовать его для доступа к серверу много раз - пока не истечет срок действия мандата. Не может расшифровать мандат (он не знает секретного ключа сервера), но он может предъявить его серверу в зашифрованной форме. Прочитать или изменить мандат при передаче его по сети невозможно . Удостоверение Kerberos имеет следующую форму:

Ac,s = {с, t, 4W4}Kc s

Клиент создает его каждый раз, когда ему нужно воспользоваться услугами сервера . Удостоверение содержит имя клиента, метку времени и необязательный дополнительный сеансовый ключ, все эти данные шифруются сеансовым ключом, общим для клиента и сервера. В отличие от мандата удостоверение используется только один раз. Однако это не проблема, так как клиент может генерировать удостоверения по мере надобности (ему известен общий секретные ключ).

Использование удостоверения преследует две цели . Во первых, оно содержит некоторый открытый текст, зашифрованный сеансовым ключом. Это доказывает, что клиенту известен ключ. Что не менее важно, зашифрованный открытый текст включает метку времени . Злоумышленник, которому удалось записать и мандат, и удостоверение, не сможет использовать их спустя два дня.

Сообщения Kerberos версии 5

В Kerberos версии 5 используется пять сообщений (см. 23-й):

1. Клиент-Kerberos: c,tgs

2. Kerberos-клиент: {Kc,tgs}Kc, {Tc tgs}Ktgs

3. Клиент-TGS: {Ac,s}Kc,tgs{Tc,tgs} Ktgs,s

4. TGS-иент: {Kc,s}Kc,tgs{Tc,s}Ks

5. Клиент-сервер: {Ac s}Kc s {Tc s}Ks

Теперь рассмотрим использование этих сообщений подробно .

Получение первоначального мандата

У клиента есть часть информации, доказывающей его личность - его пароль . Понятно, что не хочется заставлять клиента передавать пароль по сети . Протокол Kerberos минимизирует вероятность компрометации п а-роля, но при этом не позволяет пользователю правильно идентифицировать себя, если он не знает пароля .

Клиент посылает сообщение, содержащее его имя и имя его сервера TGS на сервер проверки подлинности Kerberos. (может быть несколько серверов TGS.) На практике пользователь, скорее всего, просто вводит свое имя и программа входа в систему посылает запрос .

Сервер проверки подлинности Kerberos ищет данные о клиенте в своей базе данных. Если информация о клиенте есть в базе данных, Kerberos генерирует сеансовый ключ, который будет использоваться для обмена данными между клиентом и TGS. Он называется Мандатом на выделение мандата (Ticket Granting Ticket, TGT). Kerberos шифрует этот сеансовый ключ секретным ключом клиента. Затем он создает для клиента TGT, доказывающий подлинность клиента TGS, и шифрует его секретным ключом TGS. Сервер проверки подлинности посылает эти два зашифрованных сообщения клиенту .

Теперь клиент расшифровывает первое сообщение и получает сеансовый ключ . Секретный ключ является однонаправленной хэш-функцией клиентского пароля , поэтому у законного пользователя не будет никаких пр о-блем. Самозванец не знает правильного пароля и, следовательно, не может расшифровать ответ сервера пр о-верки подлинности. Доступ запрещается, и самозванный клиент не может получить мандат или сеансовый ключ.

Клиент сохраняет TGT и сеансовый ключ, стирая пароль и хэш-значение . Эта информация уничтожается для уменьшения вероятности компрометации. Если враг попытается скопировать память клиента, он получит только TGT и сеансовый ключ. Эти данные важны, но только на время жизни TGT. Когда срок действия TGT истечет, эти сведения станут бессмысленными. Теперь в течение времени жизни TGT клиент может доказывать TGS свою подлинность.

Получение серверных мандатов

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

Когда клиенту нужен мандат, которого у него пока нет, он посылает запрос к TGS. (На практике программа, скорее всего, делает это автоматически и незаметно для пользователя .)

TGS, получив запрос, расшифровывает TGT своим секретным ключом. Затем TGS использует включенный в TGT сеансовый ключ, чтобы расшифровать удостоверение . Наконец TGS сравнивает информацию удостоверения с информацией мандата, сетевой адрес клиента с адресом отправителя запроса и метку времени с текущим временем. Если все совпадает, TGS разрешает выполнение запроса.

Проверка меток времени предполагает, что часы всех компьютеров синхронизированы, по крайней мере с точностью до нескольких минут. Если время, указанное в запросе, отстоит от текущего момента слишком дал е-ко в прошлое или в будущее, TGS считает запрос попыткой повторения предыдущего запроса . TGS должна также отслеживать правильность сроков действия удостоверений , так как услуги сервера могут запрашиваться несколько раз последовательно с одним мандатом, но разными удостоверениями . Другой запрос с тем же мандатом и уже использованной меткой времени удостовер ения будет отвергнут.

В ответ на правильный запрос TGS возвращает правильный мандат, который клиент может предъявить се р-веру. TGS также создает новый сеансовый ключ для клиента и сервера , зашифрованный сеансовым ключом, общим для клиента и TGS. Оба этих сообщения отправляются клиенту. Клиент расшифровывает сообщение и извлекает сеансовый ключ.

Запрос услуги

Теперь клиент может доказать свою подлинность серверу. Он создает сообщение, очень похожее на то, которое посылалось TGS (и это понятно, так как TGS - тоже услуга).

Клиент создает удостоверение, состоящее из его имени, сетевого адреса и метки времени, зашифрованное сеансовым ключом, который был генерирован TGS для сеанса клиента и сервера. Запрос состоит из мандата, полученного от Kerberos (уже зашифрованного секретным ключом сервера) и зашифрованного идентификатора.

Сервер расшифровывает и проверяет мандат и удостоверение, как уже обсуждалось, а также проверяет адрес клиента и метку времени. Если все в порядке, то сервер уверен, что, согласно Kerberos, клиент - именно тот, за кого он себя выдает.

Если приложение требует взаимной проверки подлинности, сервер посылает клиенту сообщение, состоящее из метки времени, зашифрованной сеансовым ключом . Это доказывает, что серверу известен правильный се к-ретный ключ, и он может расшифровать мандат и удостоверение .

При необходимости клиент и сервер могут шифровать дальнейшие сообщения общим ключом . Так как этот ключ известен только им, они оба могут быть уверены, что последнее сообщение, зашифрованное этим ключом, отправлено другой стороной.