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

Криптографические обозначения, используемые в протоколах проверки подлинности и обмена ключами
	Идентифкаторы Алисы (Alice), инициатора сессии
	Идентифкатор Боба (Bob), стороны, с которой устанавливается сессия
	Идентифкатор Трента (Trent), доверенной промежуточной стороны
	Открытые ключи Алисы, Боба и Трента
	Секретные ключи Алисы, Боба и Трента
	Шифрование данных ключом Алисы, либо совместным ключом Алисы и Трента
	Шифрование данных ключом Боба, либо совместным ключом Боба и Трента
	Шифрование данных секретными ключами Алисы, Боба (цифровая подпись)
	Порядковый номер сессии (для предотвращения атаки с повтором)
	Случайный сеансовый ключ, который будет использоваться для симетричного шифрования данных
	Шифрование данных временным сеансовым ключом
	Метки времени, добавляемые в сообщения Алисой и Бобом соответственно
	Случайные числа (nonce), которые были выбраны Алисой и Бобом соответственно

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

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

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

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

В целях собственной аутентификации Боб шифрует модифицированную метку времени   общим сеансовым ключом   и посылает её Алисе:

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

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

Схема работы 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.

Схема работы Kerberos 5

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

1. После получения TGS_REP, у клиента достаточно информации для авторизации на сервисе. Клиент соединяется с ним и посылает сообщение содержащее:

   • Зашифрованный билет сервиса полученный ранее.

   • Новый аутентификатор, зашифрованный на сессионном ключе клиент/сервис, и включающий ID клиента и метку времени.

2. Сервис расшифровывает билет используя свой секретный ключ и получает сессионный ключ клиент/сервис. Используя новый ключ, он расшифровывает аутентификатор и посылает клиенту следующее сообщение для подтверждения готовности обслужить клиента и показать, что сервер действительно является тем, за кого себя выдает:

   • Метку времени, указанную клиентом + 1, зашифрованную на сессионном ключе клиент/сервис.

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

4. Сервер предоставляет клиенту требуемый сервис.

PKINIT

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

1. Пользователь идентифицируется в системе и предъявляет свой закрытый ключ.

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

3. Получив запрос, ЦРК сначала проверяет достоверность сертификата пользователя, а затем электронную подпись (используя полученный открытый ключ пользователя). После этого ЦРК проверяет локальное время, присланное в запросе (для защиты от повторов).

4. Удостоверившись в подлинности клиента, ЦРК формирует ответ (AS_REP), в котором в отличие от стандартной версии, сеансовый ключ зашифровывается открытым ключом пользователя. Кроме того ответ содержит сертификат ЦРК и подписывается его закрытым ключом (аналогично запросу клиента).

5. Получив ответ, пользователь проверяет подпись ЦРК и расшифровывает свой сеансовый ключ (используя свой закрытый)

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

Задание для самостоятельной работы:

Проверить пароли на стойкость с помощью программы LC3.

Критерии по которым необходимо вводить пароли:

• пароль пустой,

• пароль, совпадающий с именем пользователя,

• пароль, состоящий из нескольких символов (простое слово, написанное на русском языке и на русской же раскладке клавиатуры – 4-5 символов),

• пароль, состоящий из нескольких символов (простое слово, написанное на русском языке, но на английской раскладке клавиатуры – 4-5 символов),

• пароль, придуманный вами (более 8 символов),

• пароль, сгенерированный с помощью программы генерации паролей (более 8 символов).

19