Надо сохронить, так как этот полезный текст остался только в Веб Архиве.
Copyright 1988, 1997 Массачусетский технологический институт. Все права защищены.
Билл Брант (Bill Bryant), февраль 1988.
Отредактировал и подготовил HTML вариант — Теодор Тсо (Theodore Ts’o), Февраль, 1997. Также добавлено приложение описывающие изменения 5-й версии протокола Kerberos.
От переводчика
Перевод некоторых терминов требует отдельного пояснения:
Аутентификация (Authentication). Подтверждение того, что некая личность является именно той, за которую себя выдаёт. Очень часто аутентификацию путают или смешивают с авторизацией — определением того имеет ли право определённый пользователь выполнять те или иные операции. Аутентификация всегда предшествует авторизации, так как последняя не имеет никакого смысла без предшествующей проверки подлинности пользователя. Чтобы избежать этой путаницы я, по возможности, старался избегать употребления этого слова и заменял его сочетаниями “удостоверение личности”, “подтверждение личности” и другими.
Система разделения времени (Timesharing system). Мощный компьютер с большим количеством подключённых пользовательских терминалов — недорогих приборов, состоящих из клавиатуры, монитора и устройства связи с компьютером. Такие системы были единственными представителям компьютерного мира до появления персональных компьютеров.
Рабочая станция (Workstation). Общее название для компьютеров предназначенных для работы только одного человека, но несовместимых с IBM PC. Как правило на таких компьютерах установлена одна из версий ОС UNIX. Есть большой соблазн перевести этот термин просто, как “персональный компьютер”, но из уважения к старому доброму слову “workstation” я всё таки оставил непривычное для уха русскоязычного пользователя словосочетание “рабочая станция”, время от времени заменяя его там, где это не мешает пониманию, словами “рабочее место”.
Сервер (Server) и сервис (service). Слово “сервер” имеет в компьютерной литературе два смысла. С одной стороны это некий компьютер, который предоставляет свои ресурсы (процессор, память, другие устройства) другим компьютерам сети, а с другой часто сервером называют программу, которая выполняется на этом сервере. Так, часто можно услышать “веб-сервер”, “почтовый сервер” и тому подобные выражения. Очевидно, что на одном сервере может выполняться несколько программ, каждая из которых предоставляет какую-то определённую услугу. Например на одном единственном компьютере могут быть (и часто так оно и есть) запущены одновременно и почтовый сервер и веб-сервер и сервер передачи файлов ftp. Поэтому чтобы чётко понимать, когда речь идёт о компьютере, я употребляю слово “сервер”, а когда о запущенной на нём программе — “сервис” (service, услуга). Надеюсь, что несколько корявое предложение “обратиться к почтовому сервису” не вызовет нареканий со стороны придирчивых читателей.
Сергей Долин (dsa@glug.org)
Предисловие
Эта небольшая пьеса представляет вымышленную историю и причины разработки системы аутентификации в открытых сетях, названную “Харон”. По мере развития, её главные герои — Афина и Еврепид постепенно раскрывают проблемы безопасности возникающие в открытом сетевом окружении. Каждая проблема должна тем или иным способом решаться с помощью Харона, и поэтому проект также изменяется в течении всего действия пьесы. Афина и Еврепид не прекращают свою работу до завершения пьесы.
Когда они заканчивают проектирование, Афина изменяет её имя на “Kerberos,” — имя, довольно случайно, выбранное для системы аутентификации, разработанной и реализованной в МИТ. Система “Kerberos”, описанная в пьесе чрезвычано напоминает систему Kerberos: An Authentication Service for Open Network Systems представленную на USENIX зимой 1988, в Далласе, штат Техас.
Содержание
Действующие лица
Действие I
Действие II
Действие III
Действие IV
Действующие лица
Афина — начинающий и перспективный системный программист.
Еврепид — опытный разработчик, который постоянно во всём видит только плохое.
Действие I
Небольшой кабинет без окон. Афина и Еврепид работают за соседними терминалами.
Афина: Да, что ты будешь делать! Эта наша система разделения времени совсем перестала шевелиться. Из-за того, что с ней сейчас работают все, кто только имеет к ней доступ я совсем не могу заниматься своим делом.
Еврепид: Ничем не могу помочь. Я только делаю свою работу.
Афина: А знаешь, что нужно сделать? Нам следует дать каждому собственную рабочую станцию, так, что бы не нужно было заботиться о разделении компьютерных тактов. А для соединения этих рабочих станций мы будем использовать сеть, так, чтобы люди могли общаться друг с другом.
Еврепид: Чудесно. Так, что всё, что нам нужно – пара тысяч рабочих станций?
Афина: Ну… около того.
Еврепид: Ты когда нибудь видела размер обычного жёсткого диска рабочей станции? Где ты найдешь столько места, чтобы разместить все программное обеспечение, которое ты имеешь на нашей системе с разделением времени?
Афина: Я уже придумала. Это очень просто. Мы можем хранить копии программ на нескольких машинах-серверах. В момент начала работы на рабочей станции она получит доступ к программам выполнив подключение к одному из серверов. Это позволит многим машинам использовать единственную копию программного обеспечения, и также решит проблему обновления программного обеспечения. Тебе не прийдётся устанавливать копию новой версии на каждую машиной. Достаточно просто изменить програмное обеспечение на сервере.
Еврепид: Не плохо. А что ты собираешься делать с личными файлами? В системах с разделяемым временем я могу получить доступ к моим файлам с любого терминала, который подключен к системе. Смогу ли я подойти к любой рабочей станции и автоматически получить свои файлы? Или мне прийдётся подобно пользователям ПК хранить свои файлы на дискете? Хочется надеться, что нет.
Афина: Мне кажется, ничто не мешает использовать какой нибудь компьютер в качестве хранилища для файлов. Да. Ты можешь воспользоваться любой рабочей станцией и получить свои файлы.
Еврепид: А как насчёт печати? Каждая машина должна иметь свой принтер? Признайся, чьи деньги ты решила растранжирить? А что будет с электронной почтой? Как ты собираешься доставлять почту к каждой из этих машин?
Афина: Ээээ… Ну, очевидно, нам не прийдётся давать каждому собственный принтер, мы могли бы иметь несколько машиных предназначенных для обслуживания печати. Ты посылаешь задание на этот сервер печати, и он его выполняет. Примерно также можно поступить и с почтой. Достаточно одной машины выделенной для пересылки почты. Если ты захочешь свою почту, ты просто подключаешься к почтовому серверу и от туда её забираешь.
Еврепид: Да, Тина, твоя система с персональными рабочими станциям выглядит неплохо. Знаешь, что я собираюсь сделать, как только получу подобную? Первым делом я узнаю твоё имя для входа в систему и сделаю, так, что моя машина думала, что я — это ты. Затем я подключусь к почтовому серверу и прочитаю твою почту. Потом я подключусь к твоему файловому серверу и удалю твои файлы, и …
Афина: Ты это сделаешь?
Еврепид: Без сомнения! Как все эти сетевые серверы смогут убедиться, что я — это не ты?
Афина: Хех.. Я не знаю. Кажется, мне надо ещё подумать.
Еврепид: Да, похоже на то. Сообщи мне, когда что нибудь придумаешь.
Действие II
Кабинет Еврепида на утро следующего дня. Еврепид сидит за своим столом и читает почту. В дверь стучится Афина.
Афина: Ну, я сообразила как обезопасить открытое сетевое окружение так, чтобы такие бессовестные парни, как ты не могли использовать услуги сетевых серверов от имени других людей.
Еврепид: Ну и как? Присаживайся.
Афина садится.
Афина: Перед тем, как я начну, можно первым делом оговорить одно правило для нашего обсуждения?
Еврепид: Что за правило?
Афина: Будем полагать, что, когда я произношу нечто вроде “я хочу мою электронную почту и поэтому связываюсь с почтовым сервисом и прошу его переслать почту на мой компьютер” то на самом деле я не устанавливаю непосредственно контакт с сервисом. Для этого я пользуюсь программой для подключения к почтовому сервису и получения своей почты, Эта программа явяется КЛИЕНТОМ программы почтового сервиса.
Просто мне не хочется повторять “клиент делает то-то и то-то” каждый раз, когда я описываю обмен сообщениями между пользователем и сервисом. Я могу в этом случае просто сказать “я делаю то-то и то-то”, помня, конечно что все эти вещи за меня делает клиентская программа. Устраивает ли это тебя?
Еврепид: Будь уверен. Не вижу проблемы.
Афина: Хорошо. Если так, я начну с описания проблемы, которую я собираюсь решить. В условиях открытого сетевого окружения машины, которые пердоставляют услуги должны иметь возможность проверить что, люди которые запрашивают у них услуги являются именно теми за кого они себя выдают. Если я связываюсь с почтовым сервисом и прошу у него свою почту, программа должна иметь возможность проверить, что я являюсь именно Афиной, правильно?
Еврепид: Да.
Афина: Ты бы мог решить проблему самым простым способом, потребовав, чтобы почтовый сервис запрашивал пароль перед тем, как я смогу им пользоваться. Я докажу, что я тот, кем являюсь введя свой пароль.
Еврепид: Это, коненчно же, неуклюжое решение. В системе, подобной этой, каждый сервис должен знать твой пароль. Если в сети тысяча сервисов, то каждому сервису прийдётся знать тысячу паролей. Если ты пожелаешь изменить свой пароль, ты будешь вынужден установить контакт со всеми сервисами и уведомить их об этом изменении. Мне представляется, что твоя система не столь тупа.
Афина: Да моя система не такая дурацкая. Она работает примерно так: Не только люди имеют пароли, сервисы имеют пароли тоже. Каждый пользователь знает свой пароль и каждая сервисная программа знает свой пароль. И кроме того существует сервис аутентификации, который знает ВСЕ пароли — каждый пользовательский пароль, и пароль каждого сервиса. Сервер аутентификации хранит все пароли в единственной, централизованной базе данных.
Еврепид: Ты придумал имя для этого сервиса аутентификации?
Афина: Я об этом ещё не думал. А у тебя есть какие-то идеи?
Еврепид: Как звали того парня который преправлял души умерших через Стикс?
Афина: Харон?
Еврепид: А! Я про него. От отказывался первозить через реку если ты не сможешь подтвердить свою личность.
Афина: Ты можешь далеко зайти, переписывая по новой греческую мифологию. Харона совсем не интереовала твоя личность. Ему было достаточно убедиться, что ты мёртв.
Еврепид: У тебя есть имя получше?
Пауза.
Афина: Нет, в самом деле.
Еврепид: Ну тогда давай назовём систему аутентификации “Харон”
Афина:
Ну ладно. Хотя мне кажется, что следует заняться описанием самой системы, да?
Предположим, что ты хочешь использовать почтовый сервис. В моей системе ты не сможешь использовать сервис если только… эээ… Харон сообщит ему, что ты именно тот, кем себя объявляешь. И ты не получишь разрешения использовать сервис пока не аутентифицируешь себя у Харона. В свою очередь, когда ты запрашиваешь аутентификацию у Харона, ты толжен сообщить ему имя сервиса, для которого просишь разрешения. Если ты хочешь разговаривать с почтовым сервисом, ты прежде должен договориться с Хароном.
Харон требует от тебя подтвердить свою личность. Ты делаешь это, предоставляя свой секретный пароль. Харон принимает твой пароль и сравнивает его с одним из тем, что зарегистрирован для тебя в его базе данных. Если эти два пароля совпадают, Харон считает твою личность достоверной.
Теперь Харон должен убедить почтовый сервис, что ты являешься тем, за кого себя выдаёшь. Так как Харон знает пароли всех сервисов, он знает и пароль почтового сервиса. Нетрудно догадаться, что Харон мог бы дать тебе пароль, которые ты перешлёшь почтовому сервису, чтобы доказать, что ты уже удостоверил свою личность у Харона.
Но проблема в том, что Харон не может дать тебе пароль напрямую, потому, что тогда бы ты узнал его. В следующий раз, когда ты захочешь почту, у тебя будет возможность обмануть Харона и использовать почтовый сервис без подтверждения своей личности. Ты можешь даже претвориться кем нибудь ещё и получить услуги сервиса от имени этого пользователя.
Поэтому, вместо того, чтобы давать тебе пароль, Харон даёт тебе БИЛЕТ сервиса. Этот билет включает твоё пользовательское имени, которое ЗАШИФРОВАНО ИСПОЛЬЗУЯ ПАРОЛЬ ПОЧТОВОГО СЕРВИСА.
С билетом в руках, ты можешь теперь просить у почтового сервиса свою почту. Ты выполняешь запрос, сообщая сервису кто ты такой и предоставляя вместе с ним билет, который должен доказать что ты тот, за кого себя выдаёшь.
Сервис использует свой пароль, чтобы расшифровать билет и, если он будет расшифрован правильно, то сервис получит имя того пользователя, который Харон поместил в билет.
Сервис сравнивает это имя с именем, которое ты выслал вместе с билетом. Если имена совпадают, почтовый сервис считает, что твоя личность подтверждена и можно продолжать работу, передавая тебе почту.
Что ты думаешь насчёт всего этого?
Еврепид: У меня осталось несколько вопросов.
Афина: Я так и думала. Ну-ну, давай.
Еврепид: Когда сервис расшифрует пароль, как он узнает, что сделал это правильно?
Афина: Я не знаю.
Еврепид: Вохможно, тебе следует включить в билет и имя сервиса? Тогда, после того, как билет будет расшифрован, отсутствие ошибок может быть проверено по тому оказалось ли внутри него это имя.
Афина:
По моему это неплохо. Итак билет выглядит примерно так:
(Она наспех черкает на клочке бумаги:)
БИЛЕТ – {имя пользователя:имя сервиса}
Еврепид: То есть билет включает только имя пользователя и сервиса?
Афина: …зашифрованные паролем сервиса.
Еврепид: Я не думаю, что этой информации достаточно, чтобы сделать билет надёжным с точки зрения безопасности.
Афина: Что ты имеешь в виду?
Еврепид: Предположим, что ты запрашиваешь у Харона билет для почтового сервиса. Харон изготавливает такой билет и пишет на нём твоё имя “Тина”. Предположим, что я копирую твой билет в то время, как он перемещался мимо меня по пути через сеть от Харона до тебя. Предположим я зайду на свою незащищённую рабочую станцию, под твоим именем “Тина”. Программа почтового клиента на моей рабочей станции считает, что я это ты. От твоего имени она переправляет украденный билет почтовому сервису — тот расшифровывает билет и видит, что он правильный, так как имя пользователя в билете совпадает с именем пользователя, который послал билет. Почтовый сервис даёт мне твою почту…
Афина: Ого! В этом нет ничего хорошего.
Еврепид:
Но мне кажется я знаю, как решить эту задачу. Или хотя бы найти частичное решение. Я думаю Харону следует включать несколько больше информации в билеты, которые он изготавливает: в добавок к имени пользователя, билет должен содержать СЕТЕВОЙ АДРЕС с которого пользователь запросил билет. Это даст тебе ещё один уровень безопасности.
Я проиллюстрирую. Предположим я украл твой билет теперь. Этот билет содержит твой сетевой адрес и этот адрес не совпадает с адресом моей машины. От твоего имени я отправляю похищенный билет почтовому сервису. Программа сервиса извлекает имя пользователя и сетевой адрес из билета и пытается сопоставить их с пользовательским именем и сетевым адресом того пользователя, который послала билет. Хотя имя и совпадает, но сетевой адрес – нет, и сервис отказывается принять билет, потому, что он, очевидно, был украден.
Афина: Браво! Браво! Хотела бы я додуматься до этого сама.
Еврепид: Ну для этого я здесь и работаю.
Афина:
Итак после пересмотра эскиз билета выглядит так:
Она делает набросок мелом на демонстрационной доске:
БИЛЕТ – {имя пользователя:сетевой адрес:имя сервиса}
Афина: Ну теперь я просто в восторге. Давай быстрей сделаем такую систему и посмотрим, как она работает!
Еврепид: Не так быстро. У меня есть ещё несколько замечаний по твоему предложению.
Афина: Хорошо. ( Афина наклоняется вперёд в своём кресле. ) Давай… Выбрасывай свои козыри.
Еврепид: Пока, что всё выглядит так, как будто мне придётся получать новый билет каждый раз когда я хочу получить доступ к сервису. Если у меня восьмичасовой рабочий день, я скорее всего захочу проверять свою почту более одного раза, и что же я буду запрашивать билет и вводить пароль каждый раз, когда я хочу это сделать? Если я прав, то мне твоя система не нравится.
Афина: Ээээ… Ну… я не вижу причин почему бы билеты не могут бытьь повторно использованы. Если ты получил билет для почтового сервиса, то логично ожидать, что ты будешь иметь возможность использовать их вновь и вновь. Например когда почтовая программа пользователя делает запрос сервису от твоего имени она может посылать копию твоего, ранее полученного, билета.
Еврепид: Это уже лучше. Но я всё ещё вижу проблемы. По-видимому, ты предполагаешь, что я должен общаться с Хароном каждый раз, когда я хочу использовать сервис для которого у меня нет билета. Я вошёл в систему и хочу получить доступ к своим файлам. Я отправляю запрос к Харону для правильного билета и это значит, что я должен ввести свой пароль. Затем я хочу прочитать свою почту. Ещё одно обращение к Харону — и я должен вновь вводить свой пароль. Теперь предположим я хочу послать своё почтовое сообщение на печать. Опять запрос Харону и… Ну, ты представил себе как будет выглядеть работа?
Афина: Ууу… Да, представила.
Еврепид: И, если это для тебя недостаточно, рассмотри и такой случай: мне кажется, что когда ты представляешь себя Харону, ты посылаешь твой секретный пароль по сети открытым текстом. Умные люди вроде тебя могут легко отследить трафик в сети и украсть копии паролей всех пользователей. Если я получу пароль, я могу использовать любой сервис от твоего имени. Афина вздыхает.
Афина: Это серьёзные проблемы. Кажется мне нужно ещё раз вернуться на своё рабочее место.
Действие III
На следующее утро Афина встречает Еврепида в буфете и похлопывает его по плечу в то время, как он наливает чашку кофе.
Оба поворачиваются к кофеварке.
Афина: У меня появилась новая версия Харона, которая решает нашу задачу.
Еврепид: Действительно? Быстро ты.
Афина: Ты знаешь, эти размышления над на проблемами не давали мне покоя всю ночь.
Еврепид: Должно быть это была твоя совесть. Тебе не кажется, что нам лучше продолжить беседу в кабинете?
Афина: Почему бы и нет?
Оба идут в рабочий кабинет.
Афина: Я вновь начну с условий задачи, но теперь я переиначу их так, чтобы они превратились в требования предъявляемые к системе.
Афина откашливается.
Афина: Первое требование: пользователи должны вводить свои пароли только однажды, в начале работы на рабочей станции. Это требование подразумевает, что тебе нет необходимости вводить пароль каждый раз, когда ты нуждаешься в новом билете для доступа к сервису. Второе требование: пароли не следует посылать по сети в открытом незашифрованном виде.
Еврепид: Всё так.
Афина:
Я начну с первого требования — тебе придётся вводить пароль только один раз. Я удовлетворила это требование изобретением нового сервиса. Он называется “сервис предоставления билетов” (ticket-granting service,TGS), сервис, который предоставляет Хароновские билеты пользователям которые уже однажды аутентифицировались (доказали, что являются теми за кого себя выдают) у Харона. Этот сервис можно использовать имея билет только для него.
На самом деле это почти настоящий Харон, посколько он имеет доступ к его базе данных. Он является частью Харона в том смысле, что позволяет тебе выполнить аутентификацию для любого сервиса, используя ранее полученный билет для TGS вместо пароля.
Система аутентификации сейчас работает следующим образом: ты включаешь свою рабочую станцию и используешь программу названную kinit, чтобы установить контакт с сервисом Харона. Затем удостоверяешь свою личность и kinit получает билет, позволяющий получать другие билеты (ticket-granting ticket — TGT).
Теперь, скажем, ты хочешь получить свою почту от почтового сервиса. Ты не обязан получать его билет, вновь указывая свой пароль, потому, что можно запросить его у TGS используя TGT.
Еврепид: Должен ли я получать новый TGT каждый раз, когда мне нужен новый сетевой сервис?
Афина: Нет. Вспомни, что в прошлый раз мы сошлись на том, что билеты могут использоваться повторно. Получив однажды TGT тебк не нужно делать это ещё раз. Ты используешь один и тот же TGT, чтобы получать другие нужные тебе билеты.
Еврепид: Ладно, это всё имеет смысл. И с того момента, как ты можешь использовать билеты повторно, однажды полученный с помощью TGT билет для какого-то определённого сервиса, позволяет тебе больше не запрашивать билет для этого же сервиса.
Афина: Элегантно? Не правда ли?
Еврепид: Да. Я бы не отказался от подобной штуки. Сразу, после того, как только тебе станет не нужно посылать твой пароль отрытым текстом по сети, для получения TGT.
Афина:
Как я и говорила, я решила и эту проблему тоже. Дело в том, что когда я говорю — “запросить у Харона TGT”, мои слова звучат так как будто-бы ты должен посылать свой пароль открытым текстом по сети сервису Харона. Но это совершенно не обязательно.
Вот, что происходит на самом деле. Когда ты используешь программу kinit чтобы получить TGT, то она не отправляет твой пароль сервису Харона, а посылает только твоё имя.
Еврепид: Хорошо.
Афина:
Харон использует имя пользователя, чтобы найти его пароль в своей базе данных, а затем подготавливает пакет данных, который включает и TGT. Перед тем, как послать этот пакет тебе, Харон использует твой пароль, чтобы зашифровать содержимое пакета.
Только после того, как твоя машина получит пакет, ты вводишь пароль, с помощью которого Kinit пытается его расшифровать и извлечь билет. Если это удалось, ты успешно подтвердил свою личность и теперь владеешь TGT, с помощью которого можно получать другие билеты.
Как это для твоего изощрённого ума?
Еврепид: Я не знаю… Теперь моя очередь задуматься. Честно говоря, я думаю, что система, которую ты только что описала будет работать более, чем хорошо. Твоя система требует от меня аутентифицироваться только однажды. После этого Харон может отправлять мне билеты для разных сервисов. без вмешательства с моей стороны. Безупречно. Безупречно в этом отношении. Но есть что-то в проекте, что беспокоит меня. И это “что-то” связано с тем фактом, что билеты могут повторно использоваться. Я осознаю, что они должны быть такими, но по своей природе, это свойство таит опасность.
Афина: Что ты имеешь в виду?
Еврепид:
Посмотри с такой точки зрения. Предположим ты используешь компьютер, к которому имеют доступ другие пользователи. Во время своей работы ты получил билет почтового сервиса, сервиса печати и билет для файлового сервиса. Предположим ты неосторожно оставила эти билеты на компьютере после того, как покинула своё рабочее место.
А теперь предположим я сяду за этот же компьютер и найду эти билеты. Я стремлюсь причинять неприятности, так, что я заставлю машину считать, что я — это ты. Так как билет был получен от твоего имени, я могу использовать почтовую программу для доступа к твоей почте, могу читать и удалять твои файлы, могу отправить на печать такие задания, что тебе будет очень трудно заплатить по счету. И всё только потому, что твои билеты случайно остались лежать доступными кому угодно.
И, кстати, ничто не мешает мне скопировать эти билеты куда нибудь себе. Я могу продолжать их использовать в течении любого времени.
Афина:
Но это легко исправить. Мы просто напишем программу, которая будет разрушать билеты после каждого окончания работы. Ты не сможешь использовать билеты, которые были разрушены.
Еврепид:
Ну это было очевидно, что в твоей системы должна была быть программа для уничтожения билетов, но глупо заставлять пользователей надеяться на неё. Ты не можешь полагаться на то, что пользователи не будут забывать уничтожать свои билеты каждый раз когда они заканчивают работу. И даже если ты надеешься на своих пользователей рассмотри такой сценарий.
У меня есть программа, которая отслеживает весь траффик в сети и копирует билеты в то время, пока они передаются по сети. Предположим я выбрал жертвой тебя. Я жду когда ты начнешь работу на своей машине, запускаю свою программу и копирую все твои билеты.
Я дожидаюсь пока ты покинешь своё рабочее место и выключисшь компьютер. Затем изменяю сетевой адрес так, чтобы он совпадал с адресом твоей машины, за которой ты работал, когда получал скопированные мной билеты. Затем я заставляю мою машину поверить, что я — это ты. У меня есть твои билеты, твое пользовательское имя и правильный сетевой адрес. Я могу вновь посылать эти билеты и использовать сетевые сервисы под твоим именем.
Не имеет, значения — уничтожил ли ты билеты в конце своего рабочего дня. Билеты, которые я украл остаются действующими настолько долго, насколько я хочу их использовать, потому, что в настоящее время твой проект не имеет возможность ограничить количество раз которое ты можешь использовать билеты, или в течении какого времени они остаются действующими.
Афина: Я поняла что ты хочешь сказать! Билеты не могут быть действующими бесконечно, потому, что тогда они представляют огромный риск для безопасности. Мы должны ограничить время в течении, которого билета может использоваться, например дать каждому билету срок, после которого он устаревает.
Еврепид: Именно. Я думаю, что каждый билет нуждается в двух дополнительных информационных полях: времени жизни, которое указывает период в течении, которого билет остаётся действующим и время в которое Харон его выслал. Поэтому билет будет выглядеть примерно так:
Еврепид подходит к демонстрационной доске и чертит такой рисунок:
БИЛЕТ {имя пользователя:адрес:имя сервиса:время жизни:время получения}
Еврепид: Теперь, когда сервис расшифровывает билет, он сравнивает пользовательское имя и адрес в билете с пользовательским именем и сетевым адресом того, кто послал билет, затем проверяет не устарел ли этот билет используя информацию о времени получения и времени действия.
Афина: Всё правильно. И какое же время жизни должен иметь типичный билет для сервиса?
Еврепид: Я не знаю. Возможно длина типичного рабочего дня. Скажем, восемь часов.
Афина: Тогда, если я нахожусь на рабочем месте более, чем восемь часов, все билеты устареют. Включая TGT. Поэтому мне прийдётся удостоверять свою личность у Харона каждые восемь часов.
Еврепид: Но это же не безпричинно, не так ли?
Афина: Понимаю, что нет. Итак мы договрились — билеты устаревают через восемь часов. Теперь у меня есть вопрос для тебя. Предположим я скопировал ТВОИ билеты из сети —
Еврепид: ( с весёлой ухмылкой ) Ах, Тина! Ты ведь не стала бы делать этого, не так ли?
Афина:
Это только в качестве аргумента. Я скопировала твои билеты. Теперь я жду когда ты выйдешь из системы. Ну, например, тебе назначен визит к врачу, и поэтому ты закончил свой сеанс после пары часов работы. Ты тёртый калач и уничтожил копии билетов перед отключением.
Но я похитила твои билеты и они действуют ещё на протяжении шести часов. Это даст мне достаточное количство времени для грабежа твоих файлов и печати тысячи копий чего угодно под твоим именем.
Как видишь, отметка о времени жизни работает хорошо в том случае когда похититель билета решает использовать билет после того он устарел. Если же использовать билет до того, как это произойдёт…
Еврепид: Ну,… Конечно, ты права.
Афина: Мне кажется, что у нас большие проблемы. (Вздыхает.)
Пауза.
Еврепид: Похоже на то, что у тебя опять будет бессоная ночь. Хочешь ещё кофе?
Афина: Почему бы нет.
Действие IV
Следующее утро в кабинете Еврепида. Афина стучится в дверь.
Еврепид: У тебя круги под глазами.
Афина: Ну, понимаешь. Опять не спала всю ночь.
Еврепид: Решила ли ты проблему повторного использования билетов?
Афина: Я думаю, да.
Еврепид: Ну, присаживайся.
Она садится.
Афина: Как обычно, я чувствую, что должна вновь сформулировать проблему. Билеты могут повторно использоваться в течении определённого времени, скажем восемь часов. Если кто нибудь украдёт твои билеты и и решит использовать их перед тем, как они устареют мы не можем сделать ничего, что бы остановить злоумышленника.
Еврепид: Да. Проблема в этом.
Афина: Мы можем её решить, если разработаем систему с билетами, которые не могут быть использованы повторно.
Еврепид: Но ведь тогда тебе прийдётся получить новый билет каждый раз когда ты захочешь использвать сетевой сервис.
Афина:
Правильно. Это неуклюжое решение. (Пауза.) Э… Я могу продолжать? Да? (Она ненадолго задумалась.)
Итак, я собираюсь вновь сформулировать проблему, в этот раз в форме набора условий. Сетевой сервис должен иметь возможность удостовериться, что личность, использующая билет, та же самая, для которой это билет был создан.
Я прослежу весь процесс аутентификации вновь и постараюсь найти правильный способ проиллюстрировать мое решение этой проблемы.
Я хочу использовать определённый сервис. Я получаю к нему доступ запуская программу на моей машине. Программа-клиент посылает на сервер три вещи — моё имя, сетевой адрес моей машины, и билет для этого сервиса.
Билет, в свою очередь, включает имя того пользователя, который его запросил и сетевой адрес той машины, которую он или она использовал во время получения. Также билет включает дату после которой он устаревает в виде времени жизни и времени получения. Вся эта информация зашифрована паролем сервиса, который хранится в базе данных Харона.
Наша система аутентификации в настоящий момент основывается на следующих проверках:
Может ли сервис расшифровать пароль?
Истекло ли время жизни?
Совпадает ли имя и сетевой адрес рабочей станции указанной в билете с именем и сетевым адресом того человека, который послал билет?
Что гарантируют эти проверки? Первая проверка подтверждает, что билет был получен именно от Харона. Если билет не может быть расшифрован, он не был получен от Харона, который зашифровал бы билет паролем сервиса, так как Харон и сервис — единственные, кто знают пароль сервиса. Если билет расшифровывается удачно, сервис точно знает, что он получен от Харона. Эта проверка защищает от возможности подделать билет.
Вторая проверка проверяет время жизни билета и время его получения. Если он устарел, сервис отказываетс использовать билет. Эта проверка не позволяет людям использовать старые билеты, которые возможно были украдены.
Третья проверка сравнивает имя и сетевой адрес билета с именем и сетевым адресом указанным в билете. Если проверка не удалась, билет был получен (возможно тайком) от имени другого человека. Такой билет, конечно же, тоже будет признан неправильным.
Если имя и адрес всё таки совпадают, что доказывает эта проверка? Ничего. Прохвост может украсть билеты из сети, изменить свой адрес и имя пользователя, и использовать ресурсы других пользователей. Как я сказала вчера, билеты могут повторно использоваться пока не устареют. Они могут это делать потому, что сервис не может определить, что пользователь пославший билет действительно законный его владелец.
Сервис не может определить это потому, что сам он не обменивается никаким секретным паролем непосредственно с пользователем. Посмотрим на это с другой стороны. Если я стою на страже в Эльсиноре, ну, ты помнишь та крепость в Гамлете, и ожидаю, что ты сменишь меня, я не должен позволять тебе занять своё место, если только ты не предоставишь правильный пароль. Это как раз тот момент, где мы обмениваемся паролем. При этом ничто не исключает возможности, что это пароль выдумал и сообщил каждому часовому, кто-то другой.
Поэтому я думала всю прошлую ночь, почему бы Харону не изготовить пароль для законного владельца билета, которым он может обменяться с сервисом? Харон даёт копию этого ключа сессии сервису, и копию пользователю. Когда сервис получает билет от пользователя, он может использовать ключ чтобы провереть подлинность личности пользователя.
Еврепид: Секунду. Как Харон собирается передать обоим сторонам ключ сессии?
Афина: Владелец билета получает ключ сессии, как часть ответа от Харона. Примерно так:
Она рисует следующую схему на доске:
ОТВЕТ ХАРОНА – [ключ сессии|билет]
Свою копию сессионного ключа сервис получает внутри билета; после того, как расшифрует его. Поэтому билет выглядит так:
БИЛЕТ – {ключ сессии:имя пользователя:адрес:имя сервиса:время жизни:время
получения}
Когда ты хочешь получить услуги от сервиса, клиентская программа начинает создавать то, что я решила называю АУТЕНТИФИКАТОР. Аутентификатор включает твоё имя и сетевой адрес твоей рабочей станции. Клиент шифрует эту информацию с помощью ключа сессии — копии сессионного ключа, который он получил во то время, когда запросил билет.
АУТЕНТИФИКАТОР – {имя пользователя:адрес} зашифровванные с
помощью ключа сессии.
После создания аутентификатора, клиент посылает его и билет сервису. Однако сервис не может расшифровать аутентификатор, потому, что он не имеет сессинного ключа. Этот ключ находится внутри билета, поэтому сервис вначале расшифровывает его.
После расшифровки билета, сервис наконец получает следующую информацию:
Время жизни и время получения;
Имя владельца билета;
сетевой адрес владельца билета;
ключ сессии.
Сервис, так же как и раньше, проверяет, не истёк ли срок действия билета. И, если всё в порядке, вслед за этим получает ключ сессии, чтобы расшифровать аутентификатор. Если процесс дешифрования аутентификатора не вызывает проблем, сервис заканчивает работу проверкой, того, что имя и адрес, содержащиеся внутри билета совпадают с именем и адресом пользователя, которые содержатся внутри аутентификатора. Если всё совпадает, сервис определил, что отправитель билета является его законным владельцем.
Афина замолкает, прокашливается, отпивает немножко кофе.
Мне кажется сессионный ключ и аутентификатор хорошо справляется с проблемой повторного использования.
Еврепид: Возможно. Но я не понимаю… То есть, чтобы взломать систему я должен иметь правильный аутентификатор для сервиса?
Афина: Нет. Ты должен иметь аутентификатор И билет для сервиса. Аутентификатор не имеет смысла без билета, потому, что сервис не сможет расшифровать аутентификатор без того, чтобы вначале получить соответствующий ключ сессии, а его он не сможет получить без расшифровки билета.
Еврепид: Хорошо. Я это понял. Но не хочешь ли ты сказать, что когда клиентская программа общается с сервисом, она посылает одновременно с билетом, соответствующий аутентификатор?
Афина: Да. Именно это я пыталась сказать.
Еврепид: Если так происходит в действительности, то, что мешает мне похитить билет и аутентификатор одновременно? Я уверен, что смогу написать программу, которая легко справится с этой работой. Если я получу билет и его аутентификатор, нет сомнений в том, что смогу использовать их обои так долго, как долго не устареет билет. Мне нужно только изменить адрес рабочей станции и имя пользователя. Так?
Афина: ( Кусая свои губы) Так. Как безнадёжно.
Еврепид: Стоп, стоп, стоп! Это не такая уж большая проблема. Билеты могут повторно использоваться пока они не устареют, но это не значит, что такой же способностью должны обладать аутентификаторы. Предположим мы разработаем систему так, что аутентификаторы могут использоваться только однажды. Поможет ли это нам хоть чем нибудь?
Афина:
Ну, возможно. Давай посмотрим: клиентская программ создаёт аутентификатор, затем посылает его вместе с билетом сервису. Ты копируешь их в то время пока они проносятся мимо твоей рабочей станции на сервер. Но оригинальные билет аутентефикатор достигнут сервер до того, как ты сможешь послать свои копии. Если аутентификатор может быть использован, только один раз твоя копия больше не годится, и попытка повторно использовать билет окончится нечем.
Так, что это поможет. Поэтому всё, что мы должны придумать, так это способ сделать аутентификатор одноразовым.
Еврепид:
Не вижу проблемы. Достаточно добавить продолжительность жизни и отметку о времени получения. Предположим каждый аутентификатор имеет продолжительность жизни в несколько минут. Когда ты хочешь использовать сервис твоя клиентсая программа создаёт аутентификатор, отмечает текущее время, затем посылает его и билет сервису.
Сервис получает билет и аутентификатор и начинает заниматься своими обычными делами. После расшифровки аутентификатора он проверяет его время жизни и отметку о времени получения. Если аутентфикатор ещё не устарел и всё остальное в порядке, сервис считает, что ты подтвердил свою личность.
Leave a Reply