***** 1 - Lukovsky server

Администрирование информационных систем
Лекция 7
Идентификация - установление личности
субъекта (лат. identifico - отождествлять)
Аутентификация - подтверждение подлинности
субъекта (англ. authentication)
Авторизация - проверка прав доступа субъекта
к ресурсам (англ. authorization)
Идентификация — процесс распознавания субъекта в компьютерной системе или на
веб-ресурсе при помощи анализа его идентификатора (имени и/или пароля либо любой
другой информации о пользователе, которая воспринимается системой или ресурсом).
Идентификация является начальной стадией процедуры предоставления доступа к
информационным
ресурсам
системы.
После
идентификации
происходит
аутентификация, а затем авторизация.
В качестве субъектов идентификации могут выступать пользователи, процессы,
которые выполняются от имени пользователя, а также другие аппаратно-программные
компоненты.
Объектами идентификации являются информация и любые другие информационные
ресурсы системы.
В процессе идентификации субъект сообщает свое имя посредством предоставления
уникального параметра, который называется идентификатором. Идентификатором
может быть логин и пароль (или другие данные), известные обеим сторонам процесса.
Далее идет сравнение идентификатора на соответствие информации, которая известна
системе. В случае успешной идентификации происходит аутентификация.
Аутентификация (англ. authentication, от греч. — реальный, истинный) — процесс проверки
принадлежности субъекту прав доступа к информационным ресурсам системы или веб-сайта
в соответствии с предъявленным им идентификатором; подтверждение (установление)
подлинности субъекта.
Процедура аутентификации включает в себя определенный набор элементов:

субъект, который проходит аутентификацию (авторизированный пользователь);

характеристика субъекта (идентификатор, который он предъявляет для проверки
подлинности);

владелец системы аутентификации (хозяин информационного ресурса или веб-сайта);

механизм аутентификации (ПО, которое проверяет подлинность предъявленного
идентификатора);

механизм авторизации (предоставление или лишение субъекта прав доступа после
успешной или безуспешной аутентификации).
Методы аутентификации делятся на четыре основные группы в зависимости от используемых в
процессе проверки подлинности средств. Так, различают методы, основанные на:

Знаниях, которыми владеет субъект (парольные методы).

Предметах, которые принадлежат субъекту (комбинированные).

Свойствах данных субъекта (биометрические).

Информации, которая имеет непосредственное отношение к субъекту.
Парольные методы
Наиболее распространенные методы аутентификации, основанные на секретных характеристиках субъектов —
паролях. В процессе проверки подлинности система сравнивает указный пользователем пароль с эталонным
паролем, который хранится в ее БД в зашифрованном виде. Для аутентификации посредством данного метода
могут использоваться постоянные (многоразовые, неизменные для каждой сессии) или динамические
(одноразовые, постоянно меняющиеся для каждой сессии) пароли.
Комбинированные методы
Сущность данного метода заключается в использовании для подтверждения подлинности субъекта помимо
пароля дополнительных предметов (мобильных телефонов, смарт-карт, токенов) или атрибутов
(криптографических сертификатов). Авторизация при помощи предметов и атрибутов субъекта происходит
только при наличии специального устройства, которое может считывать информацию с перечисленных
идентификаторов.
Биометрические методы
Для аутентификации посредством биометрического метода субъекты должны пройти сканирование и анализ
одного или нескольких физиологических (отпечатки пальцев, радужная оболочка глаза, сетчатка глаза, кисть
руки, черты лица) или поведенческих характеристик (подпись, тембр голоса, клавиатурный почерк). Данный
метод, как правило, используется только на особо важных объектах и системах, так как требует наличия
специальной дорогостоящей техники и оборудования.
Методы, основанные на информации о субъекте
Данная группа методов относится к новейшим механизмам аутентификации: в основе лежит использование
спутниковой системы навигации GPS. Основным идентификатором подлинности субъекта является его
местонахождение.
В основе классификации механизмов аутентификации лежит ряд определенных критериев. Так, по степени
доверия и направленности процесса различают следующие виды:

Односторонняя проверка подлинности (субъект доказывает владельцу системы свои права доступа к
информационным ресурсам или интернет-сайту).

Двусторонняя аутентификация (обоюдная проверка и установление подлинности как субъекта, так и
владельца системы).
В зависимости от возможностей средств аутентификации и уровня информационной безопасности можно
выделить такие виды:

Статическая аутентификация (защищает от несанкционированного доступа злоумышленников, которые
могут завладеть данными об идентификаторе пользователя во время его работы с информационным
ресурсом или сайтом). Как правило, в основе статической аутентификации лежит парольный метод.

Устойчивая (служит для предотвращения перехвата идентификатора с целью использования его в
следующих сеансах работы, но не защищает от активных атак, во время которых злоумышленник успевает
быстро завладеть идентификатором и модифицировать его). Механизм устойчивой аутентификации основан
на использовании динамических идентификаторов, которые меняются перед каждым сеансом.

Постоянная (защищает субъекта от несанкционированной кражи и модификации его идентификатора на
любом этапе работы с информацией).
По количеству методов, которые используются в процессе аутентификации, различают следующие виды:

Однофакторная или слабая проверка доступа (например, применение только парольного или только
биометрического метода).

Многофакторная или сильная аутентификация (использование двух или более методов).
Процедура проверки подлинности требует использования
специальных криптографических протоколов аутентификации,
которые служат для защиты субъекта и владельца системы от
несанкционированных действий злоумышленников.
В зависимости от принципа работы все протоколы можно
условно разделить на три типа:
 Протоколы доступа к паролю (например PAP — Password
Authentication Protocol). Самые простые протоколы.
 Протоколы, которые работают по принципу «вызовответ» (например CHAP — Challenge-Handshake Authentication
Protocol).
 Протоколы взаимной аутентификации (например Kerberos).
PAP (англ. Password Authentication Protocol) — протокол
простой проверки подлинности, предусматривающий
отправку имени пользователя и пароля на сервер
удалённого
доступа
открытым
текстом
(без
шифрования). Протокол PAP крайне ненадёжен,
поскольку пересылаемые пароли можно легко читать в
пакетах PPP (англ. Point-to-Point Protocol), которыми
обмениваются стороны в ходе проверки подлинности.
Обычно PAP используется только при подключении к
старым серверам удалённого доступа на базе UNIX,
которые не поддерживают никакие другие протоколы
проверки подлинности.
CHAP (англ. Challenge Handshake Authentication Protocol) — широко
распространённый
алгоритм
проверки
подлинности,
предусматривающий передачу не самого пароля пользователя, а
косвенных сведений о нём. При использовании CHAP сервер удалённого
доступа отправляет клиенту строку запроса. На основе этой строки и
пароля пользователя клиент вычисляет хеш-код MD5 (англ. Message
Digest-5) и передаёт его серверу. Хеш-функция является алгоритмом
одностороннего (необратимого) шифрования (преобразования),
поскольку значение хеш-функции для блока данных вычислить легко, а
определить исходный блок по хеш-коду с математической точки зрения
невозможно за приемлемое время. Сервер, которому доступен пароль
пользователя, выполняет те же самые вычисления и сравнивает
результат с хеш-кодом, полученным от клиента. В случае совпадения
учётные данные клиента удалённого доступа считаются подлинными.
Наиболее важной особенностью алгоритма CHAP-аутентификации
является то, что пароль никогда не пересылается по каналу.
Kerberos — сетевой протокол аутентификации, позволяющий передавать данные
через незащищённые сети для безопасной идентификации. Он ориентирован в первую
очередь на клиент-серверную модель и обеспечивает взаимную аутентификацию — оба
пользователя через сервер подтверждают личности друг друга. Данная модель является
одним из вариантов Нидхем-Шрёдер-протокола аутентификации на основе доверенной
третьей стороны и его модификациях, предложенных Denning и Sacco.
В 1983 году при поддержке консорциума производителей компьютеров был
создан проект «Афина». Его основной целью являлась разработка плана по внедрению
компьютеров в учебный процесс MIT и сопутствующего этому ПО. Хотя проект был
образовательным, конечный результат включал несколько программных продуктов,
которые широко используются и сегодня (например, X Window System).
Стандартные протоколы удаленного входа того времени отправляли свои
доверительные данные по сети в открытом виде. Кроме того, ПО сервера, такое как Rlogin
вслепую доверяло идентификационным данным. Таким образом, недобросовестные
пользователи могли без проблем получить доступ к чужой информации. Очевидно, что
возможность потери своего пароля или кражи научной работы была недопустима для
академической среды.
Для решения этих проблем проектом Афина и был разработан специальный
протокол — Kerberos. По аналогии с древнегреческой мифологией, этот протокол был
назван в честь трёхголового пса, который защищал вход в царство Аида, — Цербера, или
более точно Кербера.
Ранние версии Kerberos (c 1 по 3) были созданы внутри МIT и использовались в целях
тестирования. Эти реализации содержали существенные ограничения и были полезны только для
изучения новых идей и выявления проблем, которые могли возникнуть во время разработки.
Kerberos 4
Kerberos 4 впервые была опубликована 24 января 1989 года. Она стала первой версией
распространяемой за пределами MIT, подготовленной для нескольких производителей, которые
включили её в свои операционные системы. Кроме того, другие крупные проекты по
распределенным системам (например AFS) использовали идеи Kerberos 4 для своих систем
аутентификации. Основными разработчиками данной версии были Стив Миллер (Steve Miller)
и Клиффорд Ньюман (Clifford Neuman).
Основы того, что должно было стать Kerberos 4 были описаны в техническом плане Афина, а
окончательный вариант был закреплен в исходном коде эталонной реализации опубликованной
MIT.
Однако, из-за ограничений на экспорт программного обеспечения использующего
шифрование, наложенное американским правительством, Kerberos 4 не мог быть распространен
за пределами Соединенных Штатов. Так как Kerberos 4 использовал DES шифрование,
организации за пределами США не могли по закону использовать данное программное
обеспечение. В ответ на это, команда разработчиков из MIT создала специальную версию Kerberos
4, исключив из нее весь код касающийся шифрования. Данные меры позволили обойти
ограничение на экспорт.
В 2006 году было объявлено о прекращении поддержки Kerberos 4
С целью преодоления проблем безопасности предыдущей версии Джоном Коулом
(John Kohl) и Клиффордом Ньюманом (Clifford Neuman) была разработана 5 версия
протокола, которая в 1993 году была опубликована в RFC 1510. По прошествии времени, в
2005 спецификацией начала заниматься IETF Kerberos work group. Опубликованные ими
документы включают в себя:
 Характеристики шифрования и контрольной суммы (RFC 3961)
 Продвинутый стандарт шифрования Advanced Encryption Standard (AES) (RFC 3962)
 Kerberos 5 «The Kerberos Network Authentication Service (V5)» (RFC 4120), уточняет
некоторые аспекты RFC 1510, и намерен использоваться для более подробного и
четкого описания.
 Новое издание GSS-API спецификации «The Kerberos Version 5 Generic Security Service
Application Program Interface (GSS-API) Mechanism: Version 2.» (RFC 4121)
В июне 2006 года был представлен RFC 4556 описывающий расширение для пятой версии
под названием PKINIT (Public Key Cryptography for Initial Authentication in Kerberos).
Данный RFC описывал, как использовать асимметричное шифрование на этапе
аутентификации клиента.
На следующий год (2007) MIT сформировали Kerberos Консорциум (Kerberos Consortium)
по содействию дальнейшему развитию.
Kerberos 4 в значительной степени основан на протоколе Нидхема-Шредера, но с
двумя существенными изменениями:

Первое изменение протокола уменьшало количество
пересылаемых между клиентом и сервером аутентификации.
сообщений

Второе, более существенное изменение базового протокола заключается в
ведении TGT (Ticket Granting Ticket — билет для получения билета)
концепции, позволяющей пользователям аутентифицироваться на несколько
сервисов используя свои верительные данные только один раз.
Как
результат,
протокол
Kerberos
4
содержит
два
логических
компонента: Сервер аутентификации (СА) и сервер выдачи билетов (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 является абсолютно новым протоколом.
Основной причиной появления пятой версии являлась невозможность расширения. Со временем, атака полным
перебором на DES используемом в Kerberos 4 стала актуальна, но используемые поля в сообщениях имели
фиксированный размер и использовать более стойкий алгоритм шифрования не представлялось возможным.
Для решения данной проблемы было решено создать расширяемый протокол с возможностью использования на
различных платформах на основе технологии ASN.1. Это позволило использовать в транзакциях различные типы
шифрования. Благодаря этому была реализована совместимость с предыдущей версией. Кроме того у ЦРК
появляется возможность выбирать наиболее безопасный протокол шифрования поддерживаемый участвующими
сторонами.
Кроме того оригинальный протокол Kerberos 4 подвержен перебору по словарю. Данная уязвимость связана с тем,
что ЦРК выдает по требованию зашифрованный TGT любому клиенту. Важность данной проблемы так же
подчеркивает то, что пользователи обычно выбирают простые пароли.
Чтобы усложнить проведение данной атаки, в Kerberos 5 было введено предварительное установление
подлинности. На данном этапе ЦРК требует, чтобы пользователь удостоверил свою личность прежде, чем ему
будет выдан билет.
За предварительную аутентификацию отвечает политика ЦРК, если она требуется, то пользователь при первом
запросе к СА получит сообщение KRB_ERROR. Это сообщение скажет клиенту, что необходимо отправлять AS_REQ
запрос со своими данными для установления подлинности. Если ЦРК не опознает их, то пользователь получит
другое сообщение KRB_ERROR, сообщающее об ошибке и TGT не будет выдан.
Схема работы Kerberos 5 в настоящее время
происходит следующим образом:
Вход пользователя в систему:
 Пользователь вводит имя и пароль на
клиентской машине.
 Клиентская машина выполняет над паролем
одностороннюю функцию (обычно хэш), и
результат становится секретным ключом
клиента/пользователя.
Аутентификация клиента:

Клиент отсылает запрос (AS_REQ) на СА для получения аутентификационных верительных данных и
последующего их предоставления TGS серверу (впоследствии он будет их использовать для
получения билетов без дополнительных запросов на применение секретного ключа пользователя.)
Данный запрос содержит:
◦
Идентификатор клиента, его метка времени и идентификатор сервера.

Если политика ЦРК требует предварительной аутентификации, то пользователь получает сообщение
KRB_ERROR, в ответ на которое посылает повторный запрос, но с уже данными для установления
подлинности.

СА проверяет, есть ли такой клиент в базе. Если есть, то назад СА отправляет сообщение (AS_REP)
включающее:
◦
Сессионный ключ клиент/TGS, идентификатор TGS и время жизни билета зашифрованные секретным ключом
клиента.
◦
TGT (который включает идентификатор и сетевой адрес клиента, метку времени ЦРК, период действия билета и
сессионный ключ Клиент/TGS), зашифрованный секретным ключом TGS.

Если же нет, то клиент получает новое сообщение, говорящее о произошедшей ошибке.

Получив сообщение, клиент расшифровывает свою часть для получения Сессионного Ключа
Клиент/TGS. Этот сессионный ключ используется для дальнейшего обмена с сервером TGS. (Важно:
Клиент не может расшифровать TGT, так как оно зашифровано секретным ключом TGS) В этот
момент у пользователя достаточно данных, чтобы авторизоваться на TGS.
Авторизация клиента на TGS:

Для запроса сервиса клиент формирует запрос на TGS (TGS_REQ) содержащий
следующие данные:
◦ TGT, полученный ранее и идентификатор сервиса.
◦ Аутентификатор (составленный из ID клиента и временного штампа), зашифрованный
на Сессионном Ключе Клиент/TGS.

После получения TGS_REQ, TGS извлекает из него TGT и расшифровывает его
используя секретный ключ TGS. Это дает ему Сессионный Ключ Клиент/TGS.
Им он расшифровывает аутентификатор. Затем он генерирует сессионный
ключ клиент/сервис и посылает ответ (TGS_REP) включающий:
◦ Билет сервиса (который содержит ID клиента, сетевой адрес клиента, метку времени ЦРК,
время действия билета и Сессионный Ключ клиент/сервис) зашифрованный секретным
ключом сервиса.
◦ Сессионный ключ клиент/сервис, идентификатор сервиса и время жизни билета,
зашифрованные на Сессионном Ключе Client/TGS.
Запрос сервиса клиентом:


После получения TGS_REP, у клиента достаточно информации для авторизации на
сервисе. Клиент соединяется с ним и посылает сообщение содержащее:
◦
Зашифрованный билет сервиса полученный ранее.
◦
Новый аутентификатор, зашифрованный на сессионном ключе клиент/сервис, и включающий
ID клиента и метку времени.
Сервис расшифровывает билет используя свой секретный ключ и получает сессионный
ключ клиент/сервис. Используя новый ключ, он расшифровывает аутентификатор и
посылает клиенту следующее сообщение для подтверждения готовности обслужить
клиента и показать, что сервер действительно является тем, за кого себя выдает:
◦
Метку времени, указанную клиентом + 1, зашифрованную на сессионном ключе клиент/сервис.

Клиент расшифровывает подтверждение, используя сессионный ключ клиент/сервис и
проверяет, действительно ли метка времени корректно обновлена. Если это так, то
клиент может доверять серверу и может начать посылать запросы на сервер.

Сервер предоставляет клиенту требуемый сервис.
PKINIT
Расширение PKINIT затронуло этап предварительной аутентификации клиента. После чего она стала
происходить следующим образом:

Пользователь идентифицируется в системе и предъявляет свой закрытый ключ.

Клиентская машина формирует запрос на СА (AS_REQ), в котором указывает, что будет
использоваться асимметричное шифрование. Отличие данного запроса заключается в том, что он
подписывается (с помощью закрытого ключа клиента) и кроме стандартной информации содержит
сертификат открытого ключа пользователя.

Получив запрос, ЦРК сначала проверяет достоверность сертификата пользователя, а затем
электронную подпись (используя полученный открытый ключ пользователя). После этого ЦРК
проверяет локальное время, присланное в запросе (для защиты от повторов).

Удостоверившись в подлинности клиента, ЦРК формирует ответ (AS_REP), в котором в отличие от
стандартной версии, сеансовый ключ зашифровывается открытым ключом пользователя. Кроме
того ответ содержит сертификат ЦРК и подписывается его закрытым ключом (аналогично запросу
клиента).

Получив ответ, пользователь проверяет подпись ЦРК и расшифровывает свой сеансовый
ключ (используя свой закрытый)

Дальнейшие этапы происходят согласно стандартному описанию Kerberos V5.
Авторизация — процесс проверки прав пользователя на осуществление
определенных действий в компьютерной системе или на веб-ресурсе,
результатом которого может быть разрешение или отказ в проведении
запрашиваемых операций; предоставление пользователю возможностей
в соответствии с правами, которые гарантированы ему компьютерной
системой или веб-ресурсом.
Авторизация проходит в два последовательных этапа:

определение возможности доступа пользователя в компьютерную
систему посредством идентификации и аутентификации;

одобрение или отклонение запроса на доступ.
Главным образом авторизация необходима для сохранения
конфиденциальности и целостности информации в системе.