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

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

Инфраструктура, используемая для поддержки сертификатов в организации, на­зывается инфраструктурой открытого ключа (Public Key Infrastructure, PKI). [22]

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

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

При использовании сертификатов для аутентификации секретный ключ при­меняется для шифрования или цифровой подписи некоторого запроса или «вопро­са». Соответствующий открытый ключ (доступный в сертификате) может исполь­зоваться сервером или центральным сервером аутентификации для расшифровки запроса. Если результат соответствует ожидаемому, подлинность считается дока­занной. Так как с помощью соответствующего открытого ключа можно успешно расшифровать вопрос, а секретным ключом, посредством которого был зашифро­ван вопрос, обладает только объект-сущность, сообщение должно исходить имен­но от этого объекта-сущности. Ниже приведены шаги описанного процесса аутен­тификации.

1. Клиент подает запрос аутентификации.

2. Сервер создаст вопрос.

3. Рабочая станция использует свой секретный ключ для шифрования вопроса.

4. Ответ возвращается серверу.

5. Так как сервер содержит копию сертификата, он может использовать открытый ключ для расшифровки ответа. Результат сравнивается с вопросом.

6. Если наблюдается совпадение, клиент успешно проходит аутентификацию. Данная концепция представлена на рис. 4.2.

Рис. 4.2. Аутентификация с использованием открытого и секретного ключей

Здесь полезно понять, что исходный набор ключей генерируется клиентом и в центр сертификации передается только открытый ключ. СА генерирует сертифи­кат и подписывает его с помощью секретного ключа, после чего возвращает копию сертификата пользователю и его базе данных. [23]

SSL/TLS

SSL (англ. Secure Sockets Layer — уровень защищённых сокетов) — криптографический протокол, обеспечивающий безопасную передачу данных по сети Интернет. При его использовании создаётся защищённое соединение между клиентом и сервером. SSL изначально разработан компанией Netscape Communications. Впоследствии на основании протокола SSL 3.0 был разработан и принят стандарт RFC, получивший имя TLS.

Дан­ная система может использоваться в электронной коммерции или в любой другой сфере, где требуется машинная аутентификация или необходимы безопасные со­единения. Transport Layer Security (TLS) - это версия SSL, стандартизированная для использования в Интернете (RFC 2246). Несмотря на то, что TLS и SSL выпол­няют одну и ту же функцию, они не являются совместимыми: сервер, использую­щий SSL, не может установить защищенный сеанс с клиентом, который использу­ет только TLS. Необходимо обеспечить совместимость приложений с SSL или TLS, прежде чем использовать одну из этих двух систем.

Хотя наиболее общая реализация SSL обеспечивает безопасное соедине­ние и аутентификацию сервера, может быть также реализована аутентификация кли­ента. Клиенты должны обладать для этой цели своими собственными сертификатами, веб-сервер должен быть настроен на требование аутентификации от клиентов.

В наиболее распространенном варианте использования SSL организация полу­чает SSL-сертификат сервера из открытого центра сертификации, такого как VeriSign, и устанавливает его на свой Веб-сервер.

Процесс аутентификации состоит из следующих этапов.

1. Пользователь вводит URL сервера в браузере.

2. Запрос клиента на веб-страницу передается на сервер.

3. Сервер получает запрос и отправляет свой сертификат сервера клиенту.

4. Браузер клиента проверяет свое хранилище сертификатов на наличие сертифи­ката от центра сертификации, выпустившего сертификат сервера.

5. Если обнаруживается сертификат СА, браузер подтверждает сертификат посред­ством проверки подписи на сертификате сервера с использованием открытого ключа, имеющегося в сертификате СА.

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

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

8. Зашифрованный ключ возвращается серверу.

9. Сервер расшифровывает ключ с помощью собственного секретного ключа сервера. Для компьютера теперь общий ключ шифрования, который может использоваться для обеспечения безопасности соединений между ними.[24]

Существует множество потенциальных проблем, связанных с данной системой.

· Если веб-сервер не настроен соответствующим образом на требование исполь­зования SSL, сервер не аутентифицируется относительно клиента, и может быть установлено обычное незащищенное соединение. Безопасность зависит от того, укажет ли пользователь в строке URL браузера протокол https:/ вместо http:/.

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

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

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

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

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

Для SSL-сеансов обычно применяются 40- и 128-разрядный уровни шифрования. Первый вариант подходит для большинства ситуаций, включая электронную коммерцию, а второй - обеспечивает дополнительную защиту важных личных и финансовых сведений клиента. В версиях Microsoft Windows для США реализовано 128-, а в экспортных версиях - 40-разрядное шифрование. Чтобы обновить сервер для 128-разрядного шифрования, необходимо установить специальный пакет обновления, распространяемый Microsoft.

Необходимо различать уровень шифрования SSL-сеансов (стойкость ключа сеанса, выраженная в разрядах) и уровень шифрования SSL-сертификатов (стойкость открытого и закрытого ключей сертификата, выраженная в разрядах). Обычно длина ключа шифрования, открытого или закрытого, составляет 512 или 1024 разряда. Внутренние американские и экспортные версии большинства приложений и ОС поддерживают ключи шифрования длиной 512 разрядов. Ключи длиной 1 024 и более разрядов во многих случаях не поддерживаются.

Когда пользователь пытается установить SSL-соединение с Web-сервером, клиентский браузер и сервер на основе своих ключей шифрования определяют максимально возможный уровень шифрования. Если длина ключей шифрования 512 разрядов, используется 40-разрядное, если 1 024 - 128-разрядное шифрование. Также доступны другие длины ключей и уровни шифрования.