Помимо надежных алгоритмов аутентификации и обучения пользователей созданию надежных паролей используются средства контроля над аутентификацией, способствующие соблюдению политики паролей. Примеры рассмотрены в главе 3 в политиках безопасности.
Kerberos
Протокол Kerberos был создан более в Массачусетском технологическом институте в рамках проекта Athena. Однако общедоступным этот протокол стал, начиная с версии 4. После того, как специалисты изучили новый протокол, авторы разработали и предложили очередную версию — Kerberos 5, которая была принята в качестве стандарта IETF.
Протокол Kerberos предлагает механизм взаимной аутентификации клиента и сервера перед установлением связи между ними, причём в протоколе учтён тот факт, что начальный обмен информацией между клиентом и сервером происходит в незащищённой среде, а передаваемые пакеты могут быть перехвачены и модифицированы. Другими словами, протокол идеально подходит для применения в Интернет и аналогичных сетях.
Основная концепция протокола Kerberos очень проста — если есть секрет, известный только двоим, то любой из его хранителей может с лёгкостью удостовериться, что имеет дело со своим напарником. Для этого ему достаточно проверить, знает ли его собеседник общий секрет.
Рассмотрим простой пример. Допустим, Ольга часто посылает сообщения Стасу, который использует содержащуюся в них информацию только тогда, когда абсолютно уверен в том, что она поступила именно от Ольги. Чтобы никто не смог подделать письма, они договорились между собой о пароле, который знают только они вдвоём. Если из сообщения можно будет заключить, что отправитель знает пароль, то Стас может с уверенностью сказать, что сообщение пришло от Ольги.
Теперь Стасу и Ольге осталось только решить, каким образом показать знание пароля. Можно просто включить его в текст сообщения, например, после подписи: "Ольга, нашПароль". Это было бы просто, удобно и надёжно, если бы Ольга и Стас были уверены, что никто другой не читает их письма. К сожалению, в реальном мире об этом можно только мечтать. Почта передаётся по сети, в которой работают и другие пользователи, а среди них есть Женя, который очень любит выведывать чужие секреты, и постоянно подключает к сети свой анализатор пакетов. Совершенно ясно, что Ольга не может просто указать пароль в теле письма. Чтобы пароль оставался секретом, о нём нельзя говорить открыто, нужно лишь дать собеседнику знать, что пароль известен отправителю.
Протокол Kerberos решает эту проблему средствами криптографии с секретным ключом. Вместо того, чтобы сообщать друг другу пароль, участники сеанса связи обмениваются криптографическим ключом, знание которого подтверждает личность собеседника. Но чтобы такая технология оказалась работоспособной, необходимо, чтобы общий ключ был симметричным, т.е., он должен обеспечивать как шифрование, так и дешифрование информации. Тогда один из участников использует его для шифрования данных, а другой с помощью этого ключа извлекает их.
Простой протокол аутентификации с секретным ключом вступает в действие, когда кто-то стучится в сетевую дверь и просит впустить его. Чтобы доказать своё право на вход, пользователь предъявляет аутентификатор в виде набора данных, зашифрованного секретным ключом. Получив аутенитификатор, привратник расшифровывает его и проверяет полученную информацию, чтобы убедиться в успешности дешифрования. Разумеется, содержание набора данных должно постоянно меняться, иначе злоумышленник может просто перехватить пакет и воспользоваться его содержимым для входа в систему. Если проверка прошла успешно, то это значит, что посетителю известен секретный код, а так как этот код знает только он и привратник, следовательно, пришелец на самом деле тот, за кого себя выдаёт.
Может случиться и так, что посетитель захочет провести взаимную аутентификацию. В этом случае используется тот же самый протокол, но с некоторыми изменениями и в обратном порядке. Теперь привратник извлекает из исходного аутентификатора часть информации, а затем шифрует её, превращая в новый аутентификатор, и передаёт обратно посетителю. Тот, в свою очередь, расшифровывает информацию и сравнивает её с исходной. Если всё совпадает — значит, привратник знает секретный ключ.
Теперь вернёмся обратно к нашему примеру. Допустим, что Ольга и Стас договорились: перед тем, как пересылать информацию между своими компьютерами, они с помощью известного только им двоим секретного ключа будут проверять, кто находится на другом конце линии. Вот как это будет выглядеть:
Ольга посылает Стасу сообщение, содержащее её имя в открытом виде и аутентификатор, зашифрованный с помощью секретного ключа. В протоколе аутентификации такое сообщение представляет собой структуру данных с двумя полями. Первое поле содержит имя, второе поле — текущее время на рабочей станции Ольги.
Стас получает сообщение и видит, что оно пришло от кого-то, кто называет себя Ольгой. Он использует секретный ключ и дешифрует время отправления сообщения. Задача Стаса сильно упрощается, если его компьютер работает синхронно с компьютером Ольги, поэтому предположим, что часы на компьютерах Стаса и Ольги никогда не расходятся больше, чем на пять минут. В этом случае Стас может сравнить расшифрованное время со временем на своих часах, и, если разница составит более пяти минут, он откажется признавать подлинность аутентификатора. Если же время оказывается в пределах допустимого отклонения, то можно с большой долей уверенности предположить, что аутентификатор поступил именно от Ольги.
Стас шифрует время из сообщения Ольги и включает его в собственное сообщение, которое отправляет Ольге.
Обратите внимание, что Стас возвращает Ольге не всю информацию из её аутентификатора, а только время. Если бы он отправил всё сртазу, то у Ольги могло бы зародиться подозрение, что кто-то, притворившись Стасом, просто скопировал аутентификатор из её исходного сообщения и без изменений отправил его назад.
Ольга получает ответ Стаса, дешифрует его, и сравнивает полученное время со временем, которое было указано в исходном аутентификаторе. Если оно совпадает, то человек на другом конце смог расшифровать её сообщение, а значит, он знает секретный ключ. А так как ключ знает только Ольга и Стас, то это означает, что именно Стас получил сообщение Ольги и ответил на него.
При использовании простых протоколов, типа описанного выше, возникает одна важная проблема. В случае со Стасом и Ольгой мы ни слова не сказали о том, как и где они договаривались о секретном ключе для своей переписки. Конечно, люди могут просто встретиться в парке и обсудить все детали, но ведь в сетевых переговорах участвуют машины. Если под Ольгой понимать клиентскую программу, установленную на рабочей станции, а под Стасом — службу на сетевом сервере, то встретиться они никак не могут. Проблема ещё более осложняется в тех случаях, когда Ольге-клиенту нужно посылать сообщения на несколько серверов, в этом случае для каждого сервера её придётся обзавестись отдельным ключом. Да и службе по имени Стас потребуется столько секретных ключей, сколько у него клиентов. Если каждому клиенту для поддержания связи с каждой службой требуется индивидуальный ключ, и такой же ключ нужен каждой службе для каждого клиента, то проблема обмена ключами быстро приобретает предельную остроту. Необходимость хранения и защиты такого множества ключей на огромном количестве компьютеров создаёт невероятный риск для всей системы безопасности.
Само название протокола Kerberos говорит о том, как здесь решена проблема управления ключами. Кербер (или Цербер) — персонаж классической греческой мифологии. Этот свирепый пёс о трёх головах, по поверьям греков, охраняет врата подземного царства мёртвых. Трём головам Кербера в протоколе Kerberos соответствуют три участника безопасной связи: клиент, сервер и доверенный посредник между ними. Роль посредника здесь играет так называемый центр распределения ключей Key Distribution Center, KDC.
KDC представляет собой службу, работающую на физически защищённом сервере. Она ведёт базу данных с информацией об учётных записях всех главных абонентов безопасности своей области. Вместе с информацией о каждом абоненте безопасности в базе данных KDC сохраняется криптографический ключ, известный только этому абоненту и службе KDC. Этот ключ, который называют долговременным, используется для связи пользователя системы безопасности с центром распределения ключей. В большинстве практических реализаций протокола Kerberos долговременные ключи генерируются на основе пароля пользователя, указываемого при входе в систему.
Когда клиенту нужно обратиться к серверу, он прежде всего направляет запрос в центр KDC, который в ответ направляет каждому участнику предстоящего сеанса копии уникального сеансового ключа (session key), действующие в течение короткого времени. Назначение этих ключей – проведение аутентификации клиента и сервера. Копия сеансового ключа, пересылаемая на сервер, шифруется с помощью долговременного ключа этого сервера, а направляемая клиенту – долговременного ключа данного клиента.
Сеансовые мандаты
В ответ на запрос клиента, который намерен подключиться к серверу, служба KDC направляет обе копии сеансового ключа клиенту. Сообщение, предназначенное клиенту, шифруется посредством долговременного ключа, общего для данного клиента и KDC, а сеансовый ключ для сервера вместе с информацией о клиенте вкладывается в блок данных, получивший название сеансового мандата (session ticket). Затем сеансовый мандат целиком шифруется с помощью долговременного ключа, который знают только служба KDC и данный сервер. После этого вся ответственность за обработку мандата, несущего в себе шифрованный сеансовый ключ, возлагается на клиента, который должен доставить его на сервер.
Получив ответ KDC, клиент извлекает из него мандат и свою копию сеансового ключа, которые помещает в безопасное хранилище (оно располагается не на диске, а в оперативной памяти). Когда возникает необходимость связаться с сервером, клиент посылает ему сообщение, состоящее из мандата, который по-прежнему зашифрован с применением долговременного ключа этого сервера, и собственного аутентификатора, зашифрованного посредством сеансового ключа. Этот мандат в комбинации с аутентификатором как раз и составляет удостоверение, по которому сервер определяет «личность» клиента.
Сервер, получив «удостоверение личности» клиента, прежде всего с помощью своего секретного ключа расшифровывает сеансовый мандат и извлекает из него сеансовый ключ, который затем использует для дешифрования аутентификатора клиента. Если все проходит нормально, делается заключение, что удостоверение клиента выдано доверенным посредником, то есть, службой KDC. Клиент может потребовать у сервера проведения взаимной аутентификации. В этом случае сервер с помощью своей копии сеансового ключа шифрует метку времени из аутентификатора клиента и в таком виде пересылает ее клиенту в качестве собственного аутентификатора.
Одно из достоинств применения сеансовых мандатов состоит в том, что серверу не нужно хранить сеансовые ключи для связи с клиентами. Они сохраняются в кэш-памяти удостоверений (credentials cache) клиента, который направляет мандат на сервер каждый раз, когда хочет связаться с ним. Сервер, со своей стороны, получив от клиента мандат, дешифрует его и извлекает сеансовый ключ. Когда надобность в этом ключе исчезает, сервер может просто стереть его из своей памяти.
Такой метод дает и еще одно преимущество: у клиента исчезает необходимость обращаться к центру KDC перед каждым сеансом связи с конкретным сервером. Сеансовые мандаты можно использовать многократно. На случай же их хищения устанавливается срок годности мандата, который KDC указывает в самой структуре данных. Это время определяется политикой Kerberos для конкретной области. Обычно срок годности мандатов не превышает восьми часов, то есть, стандартной продолжительности одного сеанса работы в сети. Когда пользователь отключается от нее, кэш-память удостоверений обнуляется и все сеансовые мандаты вместе с сеансовыми ключами уничтожаются.
Как уже отмечалось, долговременный ключ пользователя генерируется на основе его пароля. Чтобы лучше понять это, вернемся к нашему примеру. Когда Ольга проходит регистрацию, клиент Kerberos, установленный на ее рабочей станции, пропускает указанный пользователем пароль через функцию одностороннего хеширования (все реализации протокола Kerberos 5 должны обязательно поддерживать алгоритм DES-CBC-MD5, хотя могут применяться и другие алгоритмы). В результате генерируется криптографический ключ.
В центре KDC долговременные ключи Ольги хранятся в базе данных с учетными записями пользователей. Получив запрос от клиента Kerberos, установленного на рабочей станции Ольги, KDC обращается в свою базу данных, находит в ней учетную запись нужного пользователя и извлекает из соответствующего ее поля долговременный ключ Ольги.
Такой процесс – вычисление одной копии ключа по паролю и извлечение другой его копии из базы данных – выполняется всего лишь один раз за сеанс, когда пользователь входит в сеть впервые. Сразу же после получения пользовательского пароля и вычисления долговременного ключа клиент Kerberos рабочей станции запрашивает сеансовый мандат и сеансовый ключ, которые используются во всех последующих транзакциях с KDC на протяжении текущего сеанса работы в сети.
На запрос пользователя KDC отвечает специальным сеансовым мандатом для самого себя, так называемый мандат на выдачу мандатов (ticket-granting ticket), или мандат TGT. Как и обычный сеансовый мандат, мандат TGT содержит копию сеансового ключа для связи службы (в данном случае – центра KDC) с клиентом. В сообщение с мандатом TGT также включается копия сеансового ключа, с помощью которой клиент может связаться с KDC. Мандат TGT шифруется посредством долговременного ключа службы KDC, а клиентская копия сеансового ключа – с помощью долговременного ключа пользователя.
Получив ответ службы KDC на свой первоначальный запрос, клиент дешифрует свою копию сеансового ключа, используя для этого копию долговременного ключа пользователя из своей кэш-памяти. После этого долговременный ключ, полученный из пользовательского пароля, можно удалить из памяти, поскольку он больше не понадобится: вся последующая связь с KDC будет шифроваться с помощью полученного сеансового ключа.
С точки зрения клиента мандат TGT почти ничем не отличается от обычного. Перед подключением к любой службе, клиент прежде всего обращается в кэш-память удостоверений и достает оттуда сеансовый мандат нужной службы. Если его нет, он начинает искать в этой же кэш-памяти мандат TGT. Найдя его, клиент извлекает оттуда же соответствующий сеансовый ключ регистрации и готовит с его помощью аутентификатор, который вместе с мандатом TGT высылает в центр KDC. Одновременно туда направляется запрос на сеансовый мандат для требуемой службы. Другими словами, организация безопасного доступа к KDC ничем не отличается от организации такого доступа к любой другой службе домена – она требует сеансового ключа, аутентификатора и мандата (в данном случае мандата TGT).
Системы с одноразовыми паролями
Проблема паролей, по сути, содержит в себе два основных момента. Во-первых, в большинстве случаев, пароли создаются людьми. Пользователей необходимо обучать созданию надежных паролей - многие их них не используют соответствующие навыки и правила. Кроме того, пароли должны четко запоминаться и не должны записываться на бумаге или где-то еще, поэтому, как правило, невозможно требовать от пользователей создания длинных паролей. Во-вторых, пароли выясняются другими пользователями, не являющимися их владельцами. Записанный на бумаге пароль доступен для постороннего лица. Люди также обмениваются пароля ми друг с другом.
Пароли подвержены различным атакам. Они могут быть перехвачены и взломаны или, возможно, использованы для проведения атаки воспроизведения. Например, можно захватить строку ответа аутентификации Windows LM или получить хэш из базы данных учетных записей и использовать его для входа в систему. (Данный тип атаки подразумевает написание кода для запроса аутентификации, после чего ответ должен возвращаться с использованием захваченного хэша, а не хэша введенного пароля. Этот подход называется «передачей хэша»).
Одним из методов противостояния подобным атакам является использование системы, требующей указания нового пароля при каждой аутентификации. В системах, не являющихся вычислительными машинами, данный подход был реализован посредством использования одноразового блокнота. Когда двум лицам требуется передать зашифрованное сообщение, имея копию одноразового блокнота, каждый из них может использовать пароль текущего дня или иной метод определения того, какой пароль следует использовать в данный момент. Несомненно, преимущество данной системы в том, что, даже если ключ взломан или и выявлен дедуктивным методом, то он будет пригоден только для текущего сообщения. Для передачи следующего сообщения будет использоваться уже другой ключ.[20]
Данный процесс состоит из следующих шагов.
1. Пользователь вводит идентификационную фразу.
2. Клиент выполняет запрос аутентификации.
3. Сервер генерирует вопрос.
4. Генератор на клиенте и генератор на сервере генерирует один и тот же одноразовый пароль.
5. Сгенерируемый пароль отображается пользователю для ввода или вводится напрямую системой. Пароль используется для шифрования ответа.
6. Ответ передается на сервер.
7. Сервер создает свой собственный шифр вопроса с использованием своего собственного сгенерированного пароля, который идентичен паролю клиента. Происходит оценка ответа.
8. Если наблюдается совпадение, пользователь успешно проходит аутентификацию.[21]
Данные шаги показаны на рис. 4.1.
Рис.4.1 Система аутентификации с одноразовыми паролями
