В операционных системах 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)
Полезная информация.
// KDC сначала пытается проверить достоверность сертификата пользователя сертификат должен быть выпущен УЦ, известным KDC, иначе он не будет принят
Леонид, что значит “должен быть выпущен УЦ, известным KDC”?
// КDС ищет в службе каталога Microsoft Active Directory Domain Services учетную запись пользователя по значению имени UPN
А любой ли сертификат “подходит”, или EKU какой должен присутствовать для проверки подлинности с помощью PKCA? Для чего может потребоваться контейнер, содержащийся в атрибуте userCertificate?
Есть ли отличия регистрации по сети от интерактивной регистрации?
Ну и расскажите уже про PAC, о том, в частности, как клиенту передаются его хеши/пароли…
> Леонид, что значит «должен быть выпущен УЦ, известным KDC»?
очевидно, что сертификат издающего CA находится в контейнере NTAuthCertificates.
> А любой ли сертификат «подходит», или EKU какой должен присутствовать для проверки подлинности с помощью PKCA?
вот что вы пристали? Если я правильно понимаю, в данном случае это можно охарактеризовать общими словами как «проверить пригодность сертификата для логона». Эти детали здесь, имхо, излишни.
> Для чего может потребоваться контейнер, содержащийся в атрибуте userCertificate?
и опять. Эти вещи (implicit/explicit certificate mapping) на данном этапе не нужны. Про них надо говорить в процессе реализации технологии. Учитвая, что общий акцент установлен на смарт-картах, этот пункт вообще лишён смысла, потому что интерактивный логон (о котором в статье идёт речь) не поддерживает explicit certificate mapping, следовательно о разделе userCertificates речи быть не может.
Леонид, извините, не ставил своей целью к Вам “приставать”. Но, я уверен, что формулировки “сертификат должен быть выпущен УЦ, ИЗВЕСТНЫМ KDC” и “сертификат МОЖЕТ быть использован для ИНТЕРАКТИВНОГО доступа в систему” – это неточно. По поводу NTAuth разъяснили все же, ок. По поводу EKU позволю Вас дополнить: расширение EKU должно содержать “Smart Card Logon” (для NT 5.x), а PK должен быть предназначен для KeyExchange, для NT 6.x. EKU может ыбть пустым.
Я понимаю, что Вы рассказываете не о Windows-реализации, а о PKINIT вообще, но при этом Вы почему-то упираете на “интерактивный логон”! PKINIT ведь не только для интерактивного логона пригоден… Мне кажется, читателям интересна прежде всего контретная реализация, а не “концепция”. Так что если речь идет о том, что “позволяет усилить функции безопасности ОС семейства Microsoft Windows”, то надо рассказывать об “особенностях реализации”.
В продолжении очень рекомендую рассказать читателям про PAC и прочие “связанные” с PKCA вещи. 😉
>В продолжении очень рекомендую рассказать читателям про PAC
А может вместе рекомендаций личным примером?)))
> EKU может ыбть пустым.
а не может, потому что это равносильно All application policies. А о последствиях вы, очевидно, не подумали. И я не вижу никаких причин, почему следует использовать эти возможности NT6.x, даже если у вас вся сеть на них. Вобщем, я против.
> читателям интересна прежде всего контретная реализация, а не «концепция»
вот вам конкретная реализация: http://msdn.microsoft.com/en-us/library/cc238455(PROT.13).aspx
Только я не считаю, что это стоит отдельного рассмотрения.