Московский государственный институт электроники и математики
(Технический университет)
Лабораторная работа № 3
по теме
«Симметричные и асимметричные современные криптосистемы»
ОТЧЕТ
(по дисциплине «Методы и средства защиты информации»)
Выполнил:
студент группы С-84
Проверила:
Москва 2008 г.
Содержание
Содержание.. 2
Задание.. 3
Формальное описание.. 4
Алгоритм работы.. 4
Исходный текст.. 5
Пример выполнения.. 6
Литература.. 7
Задание
1. Рассмотреть алгоритм аутентификации на основе протокола “Kerberos”.
2. Реализовать программно на любом языке.
3. Протестировать.
Описание и алгоритм работы
Kerberos 5 - это последняя на текущий момент версия протокола Kerberos. Она была разработана в Массачусетском Институте Технологий (Massachusetts Institute of Technology, MIT) в 1993 году и стандартизована в RFC 1510.
Основные принципы
Сервер аутентификации
В протоколе Kerberos в процессе установления соединения, кроме двух соединяющихся сторон (один из которых является сервером, предоставляющим некоторый сервис, и второй - клиентом, которых хочет соединиться с этим сервером и получить доступ к этому сервису) участвует так же так называемый сервер аутентификации (Athentification Server, AS). Иногда сервер аутентификации называют центром распределения ключей (Key Distributing Center). Считается, что как клиенты, так и серверы доверяют серверу аутентификации. Для каждого сервера на сервере аутентификации хранится секретный ключ известный только самому серверу и серверу аутентификации. Для установления соединения между сервером аутентификации и клиентом используется разделяемый секретный ключ, соответствующие каждому конкретному клиенту. Как правило, секретный ключ клиента является значением некоторой односторонней хеш-функции от пароля этого клиента (т. е. пользователя).
Мандат и билет
Клиент, желающий получить доступ к определенному сервису, посылает запрос к серверу аутентификации на получение мандата (credentials), после чего сервер отправляет назад мандат зашифрованный секретным ключом клиента. Мандат состоит из так называемого билета (ticket) и временного ключа. Билет содержит тот же временный ключ и имя клиента зашифрованные секретным ключом сервера, для которого этот билет предназначен. Каждый билет содержит в себе так же поле называемое временем жизни (lifetime), которое ограничивает временной интервал, когда этот билет может быть использован. После того, как время жизни истекло, клиент должен получить новый билет.
Кроме билетов предназначенных для получения доступа к сервису, существуют ``билеты для получения билетов'' называемые TGT (ticket-granting ticket). Билет TGT может используется для аутентификации на TGS сервере (ticket-granting service) и получения от него билетов для других серверов. В частности TGT используется для аутентификации клиента из одной области на сервере аутентификации, который относится к другой области.
Аутентификатор
После того как билет получен клиентом, он может использовать его для подключения к серверу более одного раза. Так как при подключении к серверу билет передается в не зашифрованном виде, то сторона перехватившая сообщение содержащее билет могла бы использовать этот билет для аутентификации на сервере. Для предотвращения подобной ситуации, на сервер кроме билета передается дополнительная информация называемая аутентификатором (authenticator). Аутентификатор шифруется сессионным ключом и содержит метку времени, для предотвращения повторного использования билета злоумышленником. Таким образом производится доказательство того, что клиент знает секретный ключ, и поэтому действительно является тем, за кого себя выдает.
Подпротокол "Обмен данными со службой аутентификация" 1. При первой регистрации клиента (пользователя) требуется ввод пароля, который преобразуется в ключ шифрования (стандартный метод преобразования - DES-CBC-MD5, но могут быть использованы и другие алгоритмы). Этот ключ, который считается постоянным или долговременным (до следующей смены пароля пользователем), сохраняется в кэш памяти. 2. Клиент формирует запрос на аутентификацию (KRB_AS_REQ-Kerberos uthentication Service Request), в который включаются идентификатор пользователя (для поиска его ключа), имя службы выдачи билетов, а также предварительные аутентификационные данные, которые могут предотвратить обращение злоумышленника за билетом от имени клиента (например, зашифрованная ключом клиента временная метка). 3. Клиент отсылает ЦРК запрос KRB_AS_REQ. 4. Доверенный сервер, получив запрос, ищет в своей базе соответствующий клиенту ключ и проверяет предварительные аутентификационные данные. 5. После успешной проверки ЦРК формирует сессионный ключ и готовит ответ на запрос клиента (KRB_AS_REP — Kerberos Authentication Service Reply), куда включает копию сессионного ключа, зашифрованного ключом клиента, и билет TGT, зашифрованный своим постоянным ключом, содержащий еще одну копию сессионного ключа для себя и авторизационные данные клиента. 6. Доверенный сервер отсылает клиенту ответ KRB_AS_REP. 7. Клиент, получив ответ, дешифрует сессионный ключ, сохраняет его и TGT-билет в кэш - памяти, откуда удаляет свой постоянный ключ. Теперь общаться с ЦРК он будет, используя сессионный ключ. Подпротокол "Обмен билетами на получение сервиса" 1. Клиент решает поработать с сервером ресурсов. Для этого клиент формирует запрос KRBTGSREQ — Kerberos Ticket-Granting-Service Request, куда включаются имя пользователя и аутентификационные данные, зашифрованные сессионным ключом для ЦРК, билет TGT, на именование сервера ресурсов. 2. Клиент отсылает запрос KRB_TGS_REQ доверенному серверу. 3. ЦРК, получив запрос, извлекает с помощью своего постоянного ключа сессионный ключ из TGT, а с помощью этого сессионного ключа проверяет аутентификационные данные клиента. 4. ЦРК генерирует второй сессионный ключ для работы клиента и сервера ресурсов. 5. ЦРК формирует ответ KRB_TGS_REP — Kerberos Ticket-Granting-Service Reply, куда помещает новый сессионный ключ, зашифрованный сессионным ключом клиента, и TGS, который состоит из того же нового сессионного ключа, а также данные о клиенте, необходимые для авторизации его на сервере ресурсов, — все это зашифровано постоянным ключом сервера ресурсов. 6. Доверенный сервер отсылает ответ KRB_TGS_REP клиенту. 7. Клиент, получив ответ, с помощью своего сессионного ключа извлекает новый сессионный ключ для работы с сервером ресурсов и сохраняет его в кэш-памяти вместе с TGS для сервера ресурсов. Теперь у клиента есть сессионный ключ и TGT для доверенного сервера и сессионный ключ и TGS для сервера ресурсов. |
Подпротокол "Обмен данными между клиентом и сервером" 1. Клиент формирует запрос KRB_AP_REQ — Kerberos Application Request, в который он включает свои аутентификационные данные, зашифрованные сессионным ключом для работы с сервером ресурсов, TGS для данного сервера, а также (опционально) требование произвести взаимную аутентификацию. 2. Клиент отправляет запрос KRBAPREQ серверу ресурсов. 3. Сервер ресурсов с помощью своего постоянного ключа извлекает авторизацонные данные для определения прав клиента и сессионный ключ для клиента из TGS, с помощью этого сеансового ключа дешифрует ау-тентификационные данные клиента и проверяет требование взаимной аутентификации. Если такое требование присутствует, он включает в ответ KRB_AP_REP (Kerberos Application Reply) временную метку, зашифрованную сессионным ключом для клиента. 4. Сервер отсылает ответ KRB_AP_REP клиенту. 5. Клиент, получив ответ (и проверив метку времени), убеждается в готовности сервера к работе (и его подлинности) и может начать работу с сервером. При этом данные могут шифроваться сессионным ключом, либо клиент и сервер могут договориться о другом ключе. |
Исходный текст
Пример выполнения
Литература
1. Лекции по «Методы и средства защиты информации»
2. , «Язык программирования Си»
