Протоколы аутентификации в Windows

Презентацию к лекции Вы можете скачать здесь.

Цель лекции

В рамках лекции рассматриваются протоколы аутентификации:

• SPNEGO
• NTLM
• Kerberos

Текст лекции

Рассмотрим наиболее распространенные протоколы безопасности, используемые в процессе аутентификации в Windows.

SPNEGO

SPNEGO (сокр. от Simple and Protected GSS-API Negotiation Mechanism - простой и защищенный механизм переговоров по GSS-API ) - механизм, который используется для аутентификации клиентского приложения на удаленном сервере в том случае, когда ни одна из сторон не знает, какой протокол аутентификации поддерживает другая сторона.

GSS-API ( Generic Security Service Application Program Interface - Обобщенный прикладной программный интерфейс службы безопасности) [14.1] предназначен для защиты коммуникаций между компонентами программных систем, построенных в архитектуре клиент/сервер. Он предоставляет услуги по взаимной аутентификации осуществляющих контакт партнеров и по контролю целостности и обеспечению конфиденциальности пересылаемых сообщений.

Пользователями интерфейса безопасности GSS-API являются коммуникационные протоколы (обычно прикладного уровня) или другие программные системы, самостоятельно выполняющие пересылку данных.

Обобщенный интерфейс безопасности GSS-API не зависит от конкретной языковой среды и от механизмов безопасности, обеспечивающих реальную защиту. Последнее обстоятельство позволяет создавать приложения, которые на уровне исходного текста мобильны по отношению к смене механизмов безопасности. Тем самым реализуется открытость прикладных систем и соответствующих средств защиты.

На каждом компьютере, где предполагается применять интерфейс безопасности GSS-API, должно быть установлено клиентское программное обеспечение соответствующего механизма защиты. Приложение, использующее GSS-API, локальным образом вызывает необходимые функции, получая в ответ так называемые " токены безопасности". Токен может содержать зашифрованное удостоверение пользователя, электронную подпись или целое зашифрованное сообщение. Приложения обмениваются токенами безопасности, достигая тем самым аутентификации, целостности и конфиденциальности общения. Поскольку коммуникационные аспекты вынесены за пределы GSS-API, он автоматически оказывается независимым от сетевых протоколов. Сетевая мобильность приложений должна обеспечиваться иными средствами.

SPNEGO - стандартный псевдо-механизм GSS-API. Псевдо-механизм определяет, какие механизмы GSS-API являются доступными, выбирает один из них и передает ему "право" осуществлять в дальнейшем необходимые операции по обеспечению безопасного взаимодействия приложений.

Наиболее известным применением SPNEGO является расширение Microsoft "HTTP Negotiate". Впервые SPNEGO был реализован в Internet Explorer 5.01 и IIS 5.0 с целью реализации возможности SSO ( Single Sign-On, "единый вход", "принцип однократной регистрации"), позже переименованной в Integrated Windows Authentication. SPNEGO мог выбирать между протоколами Kerberos и NTLM. Позднее Firefox и Konqueror также стали поддерживать SPNEGO.

NTLM

Когда Microsoft начала работу над созданием централизованных сетей масштабов предприятия при работе над операционной системой Windows NT, перед разработчиками была поставлена весьма сложная и новая по тем временам задача - реализовать технологии SSO и "One user - one password". "One user - one password" - "один пользователь - один пароль" означает, что у пользователя должен быть единый пароль, используемый для доступа ко всем ресурсам и протоколам сети. Действенные меры защиты не должны затруднять работу пользователей. Например, их следует освободить от необходимости отдельно регистрироваться на каждом ресурсе, используя при этом разные пароли. Кроме того, процесс регистрации не должен сопровождаться длительными задержками при получении доступа. Single sign-on, как отмечалось выше, подразумевает, что этот пароль указывается всего один раз - при входе пользователя в сеть).

Необходимо было разработать такую схему аутентификации, которая позволила бы любому сетевому приложению передавать данные аутентификации независимо от сетевого протокола. Это привело к появлению NTLM и NTLMSSP (NTLM Security Service Provider - подсистемы, позволяющей любому клиент-серверному приложению использовать NTLM, ничего не зная о его внутренней структуре). Протокол NTLM относится к семейству challenge-response (запрос-ответ) протоколов. Это означает, что ни пароль, ни его хеш никогда не передаются "как есть": они используются для генерации ответа ( response ) на случайный запрос ( challenge ). Аутентифицирующая сторона сравнивает полученный ответ с вычисленным локально. Генерация и проверка запроса и ответа осуществляется не приложениями, а провайдером NTLMSSP.

Протокол NTLM имеет много брешей в безопасности. Часть проблем вызвана тем, что Microsoft необходимо было сохранить совместимость с существующими сетями LanManager для MS-DOS и Windows for Workgroups. Другие являются ошибками проектирования, третьи - исключительно криптографические.

В настоящее время Microsoft рекомендует в качестве протокола аутентификации использовать Kerberos (см. следующую главу). Тем не менее, в новых версиях Windows он поддерживается и все еще используется, к примеру, на уровне рабочих групп (при отсутствии домена Active Directory ).

Kerberos

Kerberos - протокол аутентификации, разработанный в 1980-х гг. в Массачусетском технологическом институте ( MIT - Massachusetts Institute of Technology ). Первой операционной системой семейства Windows, реализующей протокол Kerberos [14.2], стала Windows 2000. Сетевая служба Kerberos действует как доверенный посредник, обеспечивая безопасную сетевую проверку подлинности, которая дает пользователю возможность работать на нескольких машинах сети.

Kerberos использует криптографию с секретным ключом: как правило, применяются шифры DES или Triple-DES ( 3DES ), хотя в последней версии, Kerberos v5, описанной в документе RFC 1510 [14.4], поддерживаются и другие алгоритмы: так, Windows Vista была выпущена с улучшенной версией протокола Kerberos, позволяющей использовать криптоалгоритм AES.

Kerberos версии 5 использует режим СВС ( Cipher Block Chaining ). CBC [14.3] - это режим шифрования с обратной связью, при котором перед вычислением очередного шифрованного блока открытый текст складывается побитно по модулю 2 с предыдущим шифртекстом. В режиме СВС над открытым текстом и предыдущим шифртекстом выполняется операция XOR и тем самым каждый предыдущий шифрблок используется для модифицирования очередного блока открытого текста.

Для аутентификации в службе Kerberos используются удостоверения. Различают два вида удостоверений ( credentials ): мандаты ( tickets ) и аутентификаторы ( authenticators ). Подробно структура различных сообщений Kerberos описана в документе RFC 1510 [14.2], мы ограничимся основной информацией.

Мандат используется для безопасной передачи серверу данных о клиенте. Сервер также может проверить, действительно ли мандат был выдан клиенту, который его предъявляет. Мандат Kerberos имеет следующую форму:

где - сервер, - клиент, - сетевой адрес клиента, - начало и окончание времени действия мандата, - секретный ключ сервера, - сеансовый ключ для клиента и сервера, - мандат клиента на пользование сервера. Запись здесь и далее обозначает некоторые данные , зашифрованные ключом . Клиент не может расшифровать мандат, т.к. не знает секретного ключа сервера, но он может предъявлять его серверу неограниченное количество раз в течение промежутка от начала до окончания действия мандата.

Аутентификатор - некий блок информации, зашифрованный с помощью секретного ключа. Аутентификатор предъявляется вместе с мандатом. Клиент создает аутентификатор каждый раз, когда ему нужно воспользоваться службами сервера. Аутентификатор Kerberos имеет следующую форму:

где - сервер, - клиент, - начало и окончание действия мандата, - сеансовый ключ для клиента и сервера, - аутентификатор клиента для сервера. В отличие от мандата, аутентификатор используется только один раз: содержание этого блока данных должно меняться при каждом новом сеансе, иначе злоумышленник может проникнуть в систему, воспользовавшись перехваченным сообщением.

Схема работы протокола Kerberos представлена на рис. 14.1 [14.3]. Выделяется 3 основные стадии:

• Клиент запрашивает у сервера аутентификации мандат на обращение к Серверу выдачи мандатов (Ticket-Granting Server, TGS ). В роли сервера аутентификации выступает центр распределения ключей ( KDC, Key Distribution Center). KDC направляет клиенту мандат, содержащий уникального сеансового ключа (session key) для предстоящего сеанса. Копия сеансового ключа, пересылаемая на сервер, шифруется с помощью долговременного ключа этого сервера (шаги 1-2);
• Для подключения к конкретному серверу клиент запрашивает у TGS мандат на обращение к серверу. В роли TGS также выступает KDC. Если все в порядке, KDC отсылает мандат клиенту (шаги 3-4);
• Клиент предъявляет серверу полученный мандат вместе с аутентификатором. Если удостоверение клиента правильно, сервер предоставляет клиенту доступ к службе (шаги 5-6*).

Рис. 14.1. Схема работы протокола Kerberos

1. Запрос мандата на выделение мандата сервера
2. Мандат на выделение мандата сервера
3. Запрос мандата сервера
4. Мандат сервера
5. Запрос услуги
6. Метка времени, зашифрованная сеансовым ключом*

*Шаг 6 выполняется, если требуется взаимная аутентификация. Посылая клиенту метку времени, зашифрованную сеансовым ключом, сервер доказывает, что ему известен правильный секретный ключ, и он может расшифровать мандат и аутентификатор.

Краткие итоги

Были рассмотрены протоколы аутентификации, используемые в ОС Windows: SPNEGO, NTLM, Kerberos. Описаны принципы работы и области применения протоколов. Особое внимание уделено используемым криптографическим механизмам.