Аутентификация представляет собой процедуру проверки подлинности объекта или субъекта.

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

Что значит аутентификация

Аутентификация - эффективный способ удостовериться в подлинности и достоверности важных сообщений. Один из «исторических» примеров системы аутентификации - речевой пароль «Сим-сим, откройся!» в сказке про Али-Бабу и сорок разбойников.

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

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

Аутентификация на основе сертификата

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

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

Аутентификацию на основе сертификатов можно сравнить с системой проверки на проходной большого предприятия: вахтер пропустит только тех, кто покажет ему пропуск с фотографией, подписью и печатью.

Единая система аутентификации

ЕСИА, единая система идентификации и аутентификации, представляет собой информационную систему РФ, которая дает санкционированный доступ субъектам к информации, содержащейся в информационных государственных системах. Среди основных функциональных возможностей ЕСИА можно выделить:

• аутентификацию и идентификацию пользователей;
• авторизацию уполномоченных лиц при доступе к функциям ЕСИА;
• управление идентификационными данными пользователей;
• ведение информации о полномочии пользователей.

Ошибка аутентификации

Учитывая тот факт, что аутентификация подразумевает под собой введение пароля, можно сделать вывод, что ошибка аутентификации с большой долей вероятности заключается в неправильно введенном пароле. Если система вам сообщает об ошибке аутентификации, проверьте правильность пароля, в частности, убедитесь в том, что используете нужный язык и раскладку.

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

Сертификат клиентской аутентификации

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

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

Изготовление и обслуживание клиентских сертификатов осуществляется на платной основе.

Остальные материалы цикла:

• Аутентификация клиентов в сетевых службах при помощи цифровых сертификатов — подведение итогов

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

Общая схема аутентификации по сертификатам

Когда пользователь аутентифицируется при помощи сертификата на веб-сайте, происходит примерно следующий процесс:

1. Пользователь запрашивает доступ к некоторой сетевой службе;
2. По запросу сервер посылает клиенту свой серверный сертификат (сертификат SSL). Клиент проверяет его на валидность. Если проверка провалилась, на этом всё заканчивается;
3. Если проверка прошла успешно, клиент запрашивает доступ к ресурсам службы;
4. Служба сконфигурирована на обязательную аутентификацию пользователя и отправляет клиенту доступные (на сервере) методы аутентификации. В нашем случае это требование клиентского сертификата;
5. Клиент посылает на сервер публичную часть своего сертификата и некоторый объём подписанных клиентским сертификатом данных. Сервер проверяет клиентский сертификат на валидность. Если сертификат не прошёл проверку — разговор клиента и сервера на этом завершается. Если сертификат прошёл проверку, сервер пытается сопоставить (или ассоциировать) сертификат с учётной записью пользователя. Если сопоставление не удалось — разговор завершается.
6. Если учётная запись найдена и сертификат удалось сопоставить с ней, сервер начинает установку защищённого канала. После установки этого канала, сервер предоставляет пользователю ресурсы в том объёме, в котором это позволяют списки доступа (ACL, например).

Я посчитал нужным немного развернуть последний пункт, чтобы вы понимали общее устройство этого канала (поскольку, у людей есть некоторые заблуждения на этот счёт):

1. Клиент запрашивает установку безопасного канала;
2. Сервер отвечает согласием и пересылает клиенту список поддерживаемых симметричных протоколов шифрования;
3. Клиент посылает на сервер свой список протоколов симметричного шифрования;
4. Клиент и сервер договариваются и выбирают наиболее подходящий протокол. Например, — Я умею DES и 3DES, а что умеешь ты? — А я умею только 3DES и AES. — Отлично, давай тогда использовать 3DES;
5. Клиент на своей стороне генерирует сессионный симметричный ключ шифрования и шифрует его открытым ключом сертификата сервера. Этот процесс называется Key exchange. Как мы знаем, прочитать этот ключ сможет только веб сервер, т.к. только он владеет закрытым ключом, который ассоциирован с конкретным сертификатом SSL;
6. После этого, все передаваемые данные шифруются именно этим сессионным ключом. Помните, что при передаче данных сертификаты уже не используются (а многие считают, что все данные шифруются открытыми ключами сертификатов). Сертификаты используются только при обновлении сессионного ключа (который периодически меняется).

Немного другой процесс происходит при интерактивном логоне или логоне на сервер терминалов посредством Remote Desktop при помощи смарт-карты.

Логон смарт-картой или PKINIT

Интерактивная аутентификация в Active Directory по сертификату не является самостоятельным механизмом. Как и всегда, основной протокол аутентификации в домене — Kerberos. Чтобы обеспечить взаимодействие между аутентификацией по смарт-карте и Керберосом, применяется нехитрый протокол PKINIT. PKINIT, в свою очередь, является лишь надстройкой над керберосом (или расширением протокола). Вот как он примерно работает:

Примечание: если у пользователя уже есть соответствующий сервисный тикет (TGS), выполняются только шаги 5 и 6.

1. Пользователь вводит PIN от смарт-карты и посылает запрос AS-REQ на контроллер домена (он же Key Distribution Center — KDC). Этот запрос содержит преаутентификационные данные PA_PK_AS_REQ, которые, в свою очередь, содержат логонный сертификат и подписанная временная метка и опциональные атрибуты. В качестве опциональных атрибутов, клиент посылает список поддерживаемых алгоритмов, корневых CA, параметры Diffie-Hellman и т.д. Более детально структуру запроса (а там есть достаточно занятных вещей) можно найти в RFC 4556 §3.2.1 (пункт 5 на странице 12). В связи с этим (например, передача списка доверенных корневых CA от клиента на сервер) время логона смарт-картой будет значительно медленней, чем при связке логин/пароль. Плюс расходы на криптографические операции.
2. Сервер KDC проверяет запрос и пробует ассоциировать полученный сертификат с учётной записью пользователя. Если сопоставление сертификата с учётной записью произошло успешно, KDC формирует ответ AS-REP, включая в него Ticket-Granting Ticket (TGT) и прочую необходимую информацию. Ответ подписывается сертификатом самого KDC (именно поэтому, при использовании смарт-карты для логона, сервер KDC должен иметь свой собственный сертификат (о нём мы поговорим в следующих статьях).
3. Клиент проверяет этот ответ и проверяет подпись (вместе с сертификатом KDC). Если с ответом и сертификатом всё хорошо, клиент, на основе имеющегося TGT, генерирует Ticket Granting Service запрос — TGS-REQ для доступа к конкретной службе и отправляет его на KDC.
4. KDC проверяет запрос TGS-REQ и в случае положительного вердикта формирует ответ Ticket-Granting Service (TGS-REP), включая в него всю необходимую информацию для интерактивного логона, включая все необходимые SID"ы и учётные данные для аутентификации при помощи NTLM.
5. Клиент генерирует специальный токен GSS-API (

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

Шаг 1. Создание центра сертификации

Чтобы приступить к работе сперва необходимо настроить центр сертификации (CA), это довольно просто. Если на сервере установлен OpenSSL , то СА по умолчанию настроен и готов к работе. Теперь создадим свой собственный доверенный сертифика, он необходим для подписи клиентских сертификатов и для их проверки при авторизации клиента веб-сервером.

Шаг 1.2. Создаем приватный ключ центра сертификации.

Шаг 2.2. Создаем сертификат для веб-сервера.

Шаг 3.2. Создаем клиентский сертификат.

Добавляем сертификаты в систему на примере MacOS

Загружаем client.p12 и установим его в систему.

Переходим в связку ключей и в свойствах установленного сертификата меняем уровень доверия на “Всегда доверять”.

Раскрываем ветку сертификата и предоставляем полный доступ для программ в его свойствах:

Для того, чтобы соединение было доверенным между сервером и клиентом, то обязательно установим корневой сертификат на клиентское устройство (ca.crt )