Главная Security, Без рубрики, Новое Принципы аутентификации по протоколу Kerberos. Kerberos и PKINIT. Часть 2.
  • Принципы аутентификации по протоколу Kerberos. Kerberos и PKINIT. Часть 2.

    logo В операционных системах Windows 2000/2003/2008 используются расширения протокола Kerberos, повышающие уровень безопасности процедуры аутентификацию клиентов. Расширение PKINIT предоставляет возможность использовать асимметричные криптографические алгоритмы, появилась возможность интерактивной регистрации пользователя с помощью микропроцессорных карточек (смарт карты, USB-ключи и т. п.).

    В основу расширений, обеспечивающих аутентификацию с открытым ключом, положена спецификация PKINIT. Существуют способы интеграции шифрования на основе открытого ключа в протокол Kerberos. В сущности, эти методы не преобразовывают среду Kerberos в архитектуру с с полностью автономной аутентификацией (процесс всегда будет зависеть от присутствия KDC), однако они исключают необходимость в коллективно используемом секрете, основанном на пароле многократного применения.

    Рассмотрим методику, называемую PKINIT (Public Key Initialization – инициализация открытого ключа). PKINIT использует пару открытого ключа пользователя в специальной версии процесса предаутентификации. Пользователь регистрируется в своей рабочей станции и предъявляет свой закрытый ключ. Рабочая станция связывается с KDC, посылая предаутентификационный запрос на получение TGT. В запросе содержится обычная информация и копия сертификата открытого ключа пользователя. Запрос подписывается цифровой подписью, получаемой с использованием закрытого ключа пользователя.

    Получив запрос, KDC сначала пытается проверить достоверность сертификата пользователя:

        • может ли сертификат быть использован для интерактивного доступа в систему;

        • сертификат не был отозван;

        • проверяется вся иерархия удостоверяющих центров;

        • сертификат должен быть выпущен УЦ, известным KDC, иначе он не будет принят.

    После успешной проверки сертификата пользователя КDС проверяет цифровую подпись запроса. Проверка подписи осуществляется с использованием открытого ключа из сертификата пользователя с целью подтверждения того, что запрос действительно исходит от владельца открытого ключа. После проверки цифровой подписи служба КDС проверяет маркер времени в запросе, чтобы убедится в том, что запрос не является атакой, использующей данные, ранее перехваченные в сети.

    Проверив достоверность предуатентификационных данных, КDС ищет в службе каталога Microsoft Active Directory Domain Services учетную запись пользователя по значению имени UPN (User Principal Name) пользователя, которое указано в поле Subject Alternative Name (альтернативное имя владельца) сертификата. На основании информации, хранящейся в найденной учетной записи, KDC формирует билет ТGТ таким же образом, как при стандартном режиме аутентификации Kerberos, который мы рассмотрели в первой части.

    Однако для защиты сгенерированного сеансового ключа KDC использует открытый ключ пользователя, подписывает ответ, используя свой закрытый ключ, а также включает в ответ свой сертификат.

    Получив ответ от Kerberos KDC, клиент сначала проверяет подпись KDC, и затем с использованием своего закрытого ключа (хранящегося на смарт карте) расшифровывает сеансовый ключ.

    Использование полученного билета ТGТ и все дальнейшее взаимодействие клиента с KDC происходят по стандартному протоколу Kerberos.

    Смарт карта, закрытый ключ и сертификат открытого ключа не используются до следующей регистрации пользователя в системе.

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

    Закрытый ключ ей не понадобится до следующей регистрации в системе.

    Методика PKINIT позволяет реализовать двухфакторную аутентификацию пользователя на этапе предаутентификации протокола Kerberos – пользователь должен иметь смарт карту (с хранящимися в памяти карты сертификатом и закрытым ключом), и знать ее PIN-код (чтобы иметь возможность использовать закрытый ключ для формирования цифровой подписи). Следует отметить, что закрытый ключ и сертификат обычно хранятся в разных областях памяти смарт карты.

    Таким образом, использование смарт карт и цифровых сертификатов стандарта Х.509 позволяет усилить функции безопасности ОС семейства Microsoft Windows за счет:

        • Перехода от однофакторной к двухфакторной аутентификации – пользователь должен иметь смарт карту и знать ее PIN-код (факторы: обладание чем либо, знание чего либо).

        • Устранения возможности «тиражирования» аутентификационных данных пользователя – за счет аппаратной генерации, неизвлекаемого хранения и безопасного использования закрытых ключей.

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

    Продолжение следует…

    Леонид Шапиро

    Список литературы:

    RFC4120 – The Kerberos Network Authentication Service (V5)

    RFC4556 – Public Key Cryptography for Initial Authentication in Kerberos (PKINIT)

Комментарии

  1. Полезная информация.

  2. // KDC сначала пытается проверить достоверность сертификата пользователя сертификат должен быть выпущен УЦ, известным KDC, иначе он не будет принят
    Леонид, что значит “должен быть выпущен УЦ, известным KDC”?

    // КDС ищет в службе каталога Microsoft Active Directory Domain Services учетную запись пользователя по значению имени UPN
    А любой ли сертификат “подходит”, или EKU какой должен присутствовать для проверки подлинности с помощью PKCA? Для чего может потребоваться контейнер, содержащийся в атрибуте userCertificate?
    Есть ли отличия регистрации по сети от интерактивной регистрации?
    Ну и расскажите уже про PAC, о том, в частности, как клиенту передаются его хеши/пароли…

  3. > Леонид, что значит «должен быть выпущен УЦ, известным KDC»?

    очевидно, что сертификат издающего CA находится в контейнере NTAuthCertificates.

    > А любой ли сертификат «подходит», или EKU какой должен присутствовать для проверки подлинности с помощью PKCA?

    вот что вы пристали? Если я правильно понимаю, в данном случае это можно охарактеризовать общими словами как «проверить пригодность сертификата для логона». Эти детали здесь, имхо, излишни.

    > Для чего может потребоваться контейнер, содержащийся в атрибуте userCertificate?

    и опять. Эти вещи (implicit/explicit certificate mapping) на данном этапе не нужны. Про них надо говорить в процессе реализации технологии. Учитвая, что общий акцент установлен на смарт-картах, этот пункт вообще лишён смысла, потому что интерактивный логон (о котором в статье идёт речь) не поддерживает explicit certificate mapping, следовательно о разделе userCertificates речи быть не может.

  4. Леонид, извините, не ставил своей целью к Вам “приставать”. Но, я уверен, что формулировки “сертификат должен быть выпущен УЦ, ИЗВЕСТНЫМ KDC” и “сертификат МОЖЕТ быть использован для ИНТЕРАКТИВНОГО доступа в систему” – это неточно. По поводу NTAuth разъяснили все же, ок. По поводу EKU позволю Вас дополнить: расширение EKU должно содержать “Smart Card Logon” (для NT 5.x), а PK должен быть предназначен для KeyExchange, для NT 6.x. EKU может ыбть пустым.
    Я понимаю, что Вы рассказываете не о Windows-реализации, а о PKINIT вообще, но при этом Вы почему-то упираете на “интерактивный логон”! PKINIT ведь не только для интерактивного логона пригоден… Мне кажется, читателям интересна прежде всего контретная реализация, а не “концепция”. Так что если речь идет о том, что “позволяет усилить функции безопасности ОС семейства Microsoft Windows”, то надо рассказывать об “особенностях реализации”.

    В продолжении очень рекомендую рассказать читателям про PAC и прочие “связанные” с PKCA вещи. 😉

  5. >В продолжении очень рекомендую рассказать читателям про PAC

    А может вместе рекомендаций личным примером?)))

  6. > EKU может ыбть пустым.
    а не может, потому что это равносильно All application policies. А о последствиях вы, очевидно, не подумали. И я не вижу никаких причин, почему следует использовать эти возможности NT6.x, даже если у вас вся сеть на них. Вобщем, я против.

    > читателям интересна прежде всего контретная реализация, а не «концепция»
    вот вам конкретная реализация: http://msdn.microsoft.com/en-us/library/cc238455(PROT.13).aspx
    Только я не считаю, что это стоит отдельного рассмотрения.