Керберос

From CryptoWiki
Jump to: navigation, search

Kerberos — сетевой протокол аутентификации, позволяющий передавать данные через незащищённые сети для безопасной идентификации. Ориентирован, в первую очередь, на клиент-серверную модель и обеспечивает взаимную аутентификацию — оба пользователя через сервер подтверждают личности друг друга. Данная модель является одним из вариантов протокола аутентификации Нидхема — Шрёдера на основе доверенной третьей стороны.

Contents

Формальное описание протокола

Введем следующие обозначения:

  • A,B - Алиса и Боб, участники протокола
  • Trent - Доверенная сторона
  • L - время жизни ключа
  • K - сеансовый ключ
  • T - метка времени


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

Алиса направляет доверенной стороне (Тренту) свой идентификатор и Боба:

Kerb1.PNG

Трент генерирует два сообщения. Первое включает метку времени T, время жизни ключа <math>L</math>, новый сеансовый ключ для Алисы и Боба K и идентификатор Боба B. Это сообщение шифруется общим ключом Алисы и Трента. Второе сообщение содержит то же самое, кроме идентификатора — он заменён на идентификатор Алисы A. Само сообщение шифруется общим ключом Трента и Боба:

Kerb2.PNG

Алиса генерирует сообщение из собственного идентификатора A и метки времени T, после чего шифрует сообщение сеансовым ключом <math>K</math> и посылает Бобу вместе со вторым сообщением от Трента:

Kerb3.PNG

В целях собственной аутентификации Боб шифрует модифицированную метку времени T + 1 общим сеансовым ключом <math>K</math> и посылает её Алисе: Kerb4.PNG

Важным предположением является синхронизированность часов всех участников протокола. Однако на практике используется синхронизация с точностью до нескольких минут с запоминанием истории передач (с целью обнаружения повтора) в течение некоторого времени.

Принцип работы

Kerberos 4

Kerberos 4 в значительной степени основан на протоколе Нидхема-Шрёдера, но с двумя существенными изменениями:

  • Первое изменение протокола уменьшало количество сообщений пересылаемых между клиентом и сервером аутентификации.
  • Второе, более существенное изменение базового протокола, заключается в ведении TGT (Ticket Granting Ticket — билет для получения билета) концепции, позволяющей пользователям аутентифицироваться на несколько сервисов используя свои доверительные данные только один раз.

Как результат, протокол Kerberos 4 содержит два логических компонента: Сервер аутентификации (СА) и Cервер выдачи билетов (TGS — Ticket Granting Server). Обычно эти компоненты поставляются как единая программа, которая запускается на центре распределения ключей (ЦРК — содержит базу данных логинов/паролей для пользователей и сервисов использующих Kerberos).

Сервер аутентификации выполняет одну функцию: получает запрос, содержащий имя клиента, запрашивающего аутентификацию, и возвращает ему зашифрованный TGT. Затем пользователь может использовать этот TGT для запроса дальнейших билетов на другие сервисы. В большинстве реализаций Kerberos время жизни TGT 8-10 часов. После этого клиент снова должен запросить его у СА.

Первое сообщение, отправляемое центру распределения ключей — запрос к СА, так же известен как AS_REQ. Это сообщение отправляется открытым текстом и содержит идентификационные данные клиента, метку времени клиента и идентификатор сервера предоставляющего билет (TGS).

Когда ЦРК получает AS_REQ сообщение, он проверяет, что клиент, от которого пришел запрос, существует, и его метка времени близка к локальному времени ЦРК (обычно ± 5 минут). Данная проверка производится не для защиты от повторов (сообщение посылается открытым текстом), а для проверки соответствия времени. Если хотя бы одна из проверок не проходит, то клиенту отправляется сообщение об ошибке, и он не аутентифицируется.

В случае удачной проверки СА генерирует случайный сеансовый ключ, который будет совместно использоваться клиентом и TGS (данный ключ защищает дальнейшие запросы билетов у TGS на другие сервисы). ЦРК создает 2 копии сессионного ключа: одну для клиента и одну для TGS.

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

Когда пользователь захочет получить доступ к сервису, он подготовит сообщение для TGS (TGS_REQ) содержащее 3 части: идентификатор сервиса, копию TGT полученную ранее и аутентификатор (Аутентификатор состоит из метки времени зашифрованной сессионным ключом полученным от СА и служит для защиты от повторов).

При получении запроса билета от клиента, ЦРК формирует новый сессионный ключ для взаимодействия клиент/сервис. Затем отправляет ответное сообщение (TGS_REP) зашифрованное сессионным ключом полученным от СА. Это сообщение содержит новый сеансовый ключ, билет сервиса (Service ticket содержит: копию нового сессионного ключа, идентификатор клиента, время жизни билета, локальное время ЦРК, IP клиента) зашифрованный долговременным ключом сервиса, идентификатор сервиса и время жизни билета.

Детали последнего шага — отправки билета службы серверу приложений не стандартизировались Kerberos 4, поэтому его реализация полностью зависит от приложения.

Kerberos 5

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

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

Для решения данной проблемы было решено создать расширяемый протокол с возможностью использования на различных платформах на основе технологии ASN.1. Это позволило использовать в транзакциях различные типы шифрования. Благодаря этому была реализована совместимость с предыдущей версией. Кроме того у ЦРК появляется возможность выбирать наиболее безопасный протокол шифрования поддерживаемый участвующими сторонами.

Кроме того оригинальный протокол Kerberos 4 подвержен перебору по словарю. Данная уязвимость связана с тем, что ЦРК выдает по требованию зашифрованный TGT любому клиенту. Важность данной проблемы так же подчеркивает то, что пользователи обычно выбирают простые пароли.

Чтобы усложнить проведение данной атаки, в Kerberos 5 было введено предварительное установление подлинности. На данном этапе ЦРК требует, чтобы пользователь удостоверил свою личность прежде, чем ему будет выдан билет.

За предварительную аутентификацию отвечает политика ЦРК, если она требуется, то пользователь при первом запросе к СА получит сообщение KRB_ERROR. Это сообщение скажет клиенту, что необходимо отправлять AS_REQ запрос со своими данными для установления подлинности. Если ЦРК не опознает их, то пользователь получит другое сообщение KRB_ERROR, сообщающее об ошибке и TGT не будет выдан.

Подробное описание

Схема работы Kerberos 5 в настоящее время происходит следующим образом:

Вход пользователя в систему:

  1. Пользователь вводит имя и пароль на клиентской машине.
  2. Клиентская машина выполняет над паролем одностороннюю функцию (обычно хэш), и результат становится секретным ключом клиента/пользователя.

Аутентификация клиента:

  1. Клиент отсылает запрос (AS_REQ) на СА для получения аутентификационных верительных данных и последующего их предоставления TGS серверу (впоследствии он будет их использовать для получения билетов без дополнительных запросов на применение секретного ключа пользователя.) Данный запрос содержит:
    • Идентификатор клиента, его метка времени и идентификатор сервера.
  2. Если политика ЦРК требует предварительной аутентификации, то пользователь получает сообщение KRB_ERROR, в ответ на которое посылает повторный запрос, но с уже данными для установления подлинности.
  3. СА проверяет, есть ли такой клиент в базе. Если есть, то назад СА отправляет сообщение (AS_REP) включающее:
    • Сессионный ключ клиент/TGS, идентификатор TGS и время жизни билета зашифрованные секретным ключом клиента.
    • TGT (который включает идентификатор и сетевой адрес клиента, метку времени ЦРК, период действия билета и сессионный ключ Клиент/TGS), зашифрованный секретным ключом TGS.
  1. Если же нет, то клиент получает новое сообщение, говорящее о произошедшей ошибке.
  2. Получив сообщение, клиент расшифровывает свою часть для получения Сессионного Ключа Клиент/TGS. Этот сессионный ключ используется для дальнейшего обмена с сервером TGS. (Важно: Клиент не может расшифровать TGT, так как оно зашифровано секретным ключом TGS) В этот момент у пользователя достаточно данных, чтобы авторизоваться на TGS.

Авторизация клиента на TGS:

  1. Для запроса сервиса клиент формирует запрос на TGS (TGS_REQ) содержащий следующие данные:
    • TGT, полученный ранее и идентификатор сервиса.
    • Аутентификатор (составленный из ID клиента и временного штампа), зашифрованный на Сессионном Ключе Клиент/TGS.
  2. После получения TGS_REQ, TGS извлекает из него TGT и расшифровывает его используя секретный ключ TGS. Это дает ему Сессионный Ключ Клиент/TGS. Им он расшифровывает аутентификатор. Затем он генерирует сессионный ключ клиент/сервис и посылает ответ (TGS_REP) включающий:
    • Билет сервиса (который содержит ID клиента, сетевой адрес клиента, метку времени ЦРК, время действия билета и Сессионный Ключ клиент/сервис) зашифрованный секретным ключом сервиса.
    • Сессионный ключ клиент/сервис, идентификатор сервиса и время жизни билета, зашифрованные на Сессионном Ключе Client/TGS.

Запрос сервиса клиентом:

  1. После получения TGS_REP, у клиента достаточно информации для авторизации на сервисе. Клиент соединяется с ним и посылает сообщение содержащее:
    • Зашифрованный билет сервиса полученный ранее.
    • Новый аутентификатор, зашифрованный на сессионном ключе клиент/сервис, и включающий ID клиента и метку времени.
  2. Сервис расшифровывает билет используя свой секретный ключ и получает сессионный ключ клиент/сервис. Используя новый ключ, он расшифровывает аутентификатор и посылает клиенту следующее сообщение для подтверждения готовности обслужить клиента и показать, что сервер действительно является тем, за кого себя выдает:
    • Метку времени, указанную клиентом + 1, зашифрованную на сессионном ключе клиент/сервис.
  3. Клиент расшифровывает подтверждение, используя сессионный ключ клиент/сервис и проверяет, действительно ли метка времени корректно обновлена. Если это так, то клиент может доверять серверу и может начать посылать запросы на сервер.
  4. Сервер предоставляет клиенту требуемый сервис.

PKINIT

Расширение PKINIT затронуло этап предварительной аутентификации клиента. После чего она стала происходить следующим образом:

  1. Пользователь идентифицируется в системе и предъявляет свой закрытый ключ.
  2. Клиентская машина формирует запрос на СА (AS_REQ), в котором указывает, что будет использоваться асимметричное шифрование. Отличие данного запроса заключается в том, что он подписывается (с помощью закрытого ключа клиента) и кроме стандартной информации содержит сертификат открытого ключа пользователя.
  3. Получив запрос, ЦРК сначала проверяет достоверность сертификата пользователя, а затем электронную подпись (используя полученный открытый ключ пользователя). После этого ЦРК проверяет локальное время, присланное в запросе (для защиты от повторов).
  4. Удостоверившись в подлинности клиента, ЦРК формирует ответ (AS_REP), в котором в отличие от стандартной версии, сеансовый ключ зашифровывается открытым ключом пользователя. Кроме того ответ содержит сертификат ЦРК и подписывается его закрытым ключом (аналогично запросу клиента).
  5. Получив ответ, пользователь проверяет подпись ЦРК и расшифровывает свой сеансовый ключ (используя свой закрытый)

Дальнейшие этапы происходят согласно стандартному описанию Kerberos V5.