3.4 Система цифровых сертификатов.

Формат сертификатов открытых ключей X.509

Формат сертификата открытого ключа определен в рекомендациях Международного Союза по телекоммуникациям ITU (X.509) и документе RFC 3280 Certificate & CRL Profile организации инженерной поддержки Интернета Internet Engineering Task Force (IETF). В настоящее время основным принятым форматом является формат версии 3, позволяющий задавать дополнения, с помощью которых реализуется определенная политика безопасности в системе.

Описание.

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

серийный номер сертификата Certificate Serial Number;

идентификатор алгоритма подписи Signature Algorithm Identifier;

имя издателя Issuer Name;

период действия Validity (Not Before/After);

открытый ключ субъекта Subject Public Key Information;

имя субъекта сертификата Subject Name.

Под субъектом сертификата понимается сторона, которая контролирует секретный ключ, соответствующий данному открытому ключу. Наличие необязательных полей характерно для сертификатов версий 2 и 3, к необязательным полям сертификата относятся номер версии, два уникальных идентификатора и дополнения.

Дополнения сертификата

Дополнения позволяют включать в сертификат информацию, которая отсутствует в основном содержании. В дополнениях содержится технологическая информация, позволяющая проверить подлинность сертификата.

Опциональное поле "Extensions" появляется в сертификатах третьей версии. Каждое дополнение состоит из идентификатора типа дополнения Extension identifier, признака критичности Criticality flag и собственно значения дополнения Extension value.

Дополнения сертификатов X.509 определены рекомендациями Х.509 версии 3 Международного Союза по телекоммуникациям и документом RFC 3280. Все эти дополнения можно разделить на две категории: ограничивающие и информационные. Первые ограничивают область применения ключа, определенного сертификатом, или самого сертификата. Вторые содержат дополнительную информацию, которая может быть использована в прикладном программном обеспечении пользователем сертификата. К ограничивающим дополнениям относятся:

основные ограничения (Basic Constraints);

назначение ключа (Key Usage);

расширенное назначение ключа (Extended Key Usage);

политики применения сертификата (Certificates Policies, Policy Mappings, Policy Constraints);

ограничения на имена (Name Constraints).

К информационным дополнениям относятся:

идентификаторы ключей (Subject Key Identifier, Authority Key Identifier);

альтернативные имена (Subject Alternative Name, Issuer Alternative Name);

пункт распространения списка аннулированных сертификатов (CRL Distribution Point, Issuing Distribution Point);

способ доступа к информации УЦ (Authority Access Info). [22]

RADIUS – Сервер

Аббревиатура RADIUS расшифровывается как Remote Authentication Dial-In User Service (Служба удаленной аутентификации входящих пользователей). Изначально концепция RADIUS состояла в обеспечении удаленного доступа через коммутируемое телефонное соединение. Сейчас же протокол RADIUS используется для авторизации, аутентификации и учета пользователей в различных системах (в том числе и беспроводных). Протокол RADIUS полностью абстрагирован не только от технологии связи, но и от протоколов передачи данных в сети, в которой происходит авторизация. Фактически функция сервера RADIUS сводится к тому, что сервер принимает информацию, которую пользователь сети предоставляет в процессе аутентификации, и авторизует пользователя. Использование сервера RADIUS не может сделать безопаснее сам процесс передачи данных в сети, оно может обезопасить только процесс передачи данных в ходе аутентификации. После того как процесс авторизации пользователя в сети завершился, сервер RADIUS ему больше не нужен, по крайней мере, до тех пор, пока пользователю не понадобится снова авторизоваться в системе.

Oсновные составные части службы RADIUS описываются двумя RFC от IETF: RFC 2865 под названием Remote Authentication Dial-In User Service (RADIUS) в форме проекта стандарта и RFC 2866 под названием RADIUS Accounting в виде «информационного RFC».

Концепция службы идентификации удаленных пользователей подразумевает, что клиент отсылает серверу RADIUS параметры доступа пользователя (в англоязычной документации они часто называются Credentials, т. е. мандат, куда, к примеру, входят его настройки безопасности и права доступа), а также параметры соответствующего соединения. Для этого клиент использует специальный формат, так называемый RADIUS-Message (сообщение RADIUS). В ответ сервер начинает проверку, в ходе которой он аутентифицирует и авторизует запрос клиента RADIUS, а затем пересылает ему ответ — RADIUS-Message-response. После этого клиент передает на сервер RADIUS учетную информацию (Рисунок 9). (Приложение 9).

Сами по себе сообщения RADIUS передаются в форме пакетов UDP. Причем информация об аутентификации направляется на порт UDP с номером 1812. Некоторые серверы доступа используют, однако, порты 1645 (для сообщений об аутентификации) или, соответственно, 1646 (для учета) — выбор должен определять своим решением администратор. В поле данных пакета UDP всегда помещается только одно сообщение RADIUS. В соответствии с RFC 2865 и RFC 2866 определены следующие типы сообщений:

Access-Request – «запрос доступа». Запрос клиента RADIUS, с которого начинается собственно аутентификация и авторизация попытки доступа в сеть;

Access-Accept – «доступ разрешен». С помощью этого ответа на запрос доступа клиенту RADIUS сообщается, что попытка соединения была успешно аутентифицирована и авторизована; Access-Reject – «доступ не разрешен». Этот ответ сервера RADIUS означает, что попытка доступа к сети не удалась. Такое возможно в том случае, если пользовательских данных недостаточно для успешной аутентификации или доступ для пользователя не авторизован; Access-Challenge – «вызов запроса». Сервер RADIUS передает его в ответ на запрос доступа; Accounting-Request – «запрос учета», который клиент RADIUS отсылает для ввода учетной информации после получения разрешения на доступ; Accounting-Response – «ответ учета». Таким образом сервер RADIUS реагирует на запрос учета и подтверждает факт обработки запроса учета.

Сообщение RADIUS всегда состоит из заголовка и атрибутов, каждый из которых содержит ту или иную информацию о попытке доступа: например, имя и пароль пользователя, запрашиваемые услуги и IP-адрес сервера доступа. Таким образом, главной задачей атрибутов RADIUS является транспортировка информации между клиентами, серверами и прочими агентами RADIUS. Атрибуты RADIUS определены в нескольких RFC: RFC 2865, RFC 2866, RFC 2867, RFC 2868, RFC 2869 и RFC 3162.

Для защиты сообщений клиент и сервер RADIUS обладают «общим секретом» или, проще говоря, ключом. При этом речь, как правило, идет о цепочке символов, имеющейся как на серверах, так и на клиенте RADIUS.

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

В настройках клиентского ПО беспроводной сети можно обнаружить аббревиатуры EAP, EAP-TLS, PEAP-MSCHAP-V2 и другие. Они обозначают различные протоколы аутентификации. Так, EAP (Extensible Authentication Protocol, Расширяемый протокол аутентификации) представляет собой контейнер для протоколов, фактически осуществляющих передачу запросов на аутентификацию и ответов аутентификатора. Поскольку EAP абстрагирован от конкретных процедур аутентификации, сетевое оборудование, поддерживающее EAP, тоже не связано с какими-либо конкретными протоколами.

Компания Microsoft разработала на основе EAP протокол EAP-TLS, принятый позднее в качестве стандарта. Протокол EAP-TLS (Extensible Authentication Protocol – Transport Layer Security) реализует двустороннюю аутентификацию с использованием сертификатов X.509 обеими сторонами. PEAP (Protected Extensible Authentication Protocol) представляет собой расширение протокола EAP. В отличие от EAP, протокол PEAP создает безопасный туннель перед началом процесса аутентификации. Далее по этому туннелю передаются данные для аутентификации. Наличие безопасного туннеля затрудняет перехват данных злоумышленником. Как и EAP, PEAP представляет собой контейнер для высокоуровневых протоколов аутентификации, в которых аутентификация выполняется с помощью имени учетной записи и пароля. Еще один протокол, EAP-TTLS, также использует безопасные туннели для передачи данных. Как и в EAP-TLS, в EAP-TTLS реализована двусторонняя аутентификация (сервер удостоверяет себя с помощью сертификата X.509).

Расширенный протокол аутентификации (EAP)

Расширенный протокол аутентификации (Extensible Authentication Protocol, EAP) изначально задумывался как дополнение к РРР для поддержки различных механизмов аутентификации доступа к сети. Протоколы аутентификации для РРР, определяют механизм аутентификации во время фазы установления соединения. На этом этапе необходимо применять согласованный протокол аутентификации, с целью «верификации» соединения. В данном случае речь идет о заранее определенной последовательности сообщений, причем они должны отсылаться в соответствии с заданной схемой, а точнее, в указанной очередности.

При использовании EAP в процессе установления соединения в рамках РРР специальный механизм аутентификации не определяется. Лишь на этапе аутентификации участники взаимодействуют по специальной схеме аутентификации EAP, обозначаемой также как «схема типа EAP».

ЕАР позволяет осуществлять обмен сообщениями между клиентом, запрашивающим доступ, и аутентифицирующим сервером (в его роли часто выступает сервер RADIUS). При этом обмен сообщениями может варьироваться с учетом особенностей различных соединений; он состоит собственно из запросов, в которых требуется предоставление информации об аутентификации, а также из соответствующих ответов. Длительность и конкретные детали сеанса аутентификации зависят от заданной схемы EAP.

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

ЕАР удобен при таких видах аутентификации, как токены (Generic Token Card), однократные пароли (One Time Password), запрос/ответ (MD5-Challenge) или защита на транспортном уровне (Transport Level Security). Кроме того, эта концепция открыта для применения лучших технологий аутентификации в будущем. Однако ЕАР используется не только вместе с РРР. Он, помимо всего, поддерживается на канальном уровне стандарта IEEE 802. [23]

Установка сервера Сертификатов и RADIUS-сервера.

Установка производится на ОС Ubuntu. Пакеты freeradius, openssl и сопутствующие зависимости.

Конфигурация радиус-сервера описана в приложении 6.