В том случае, когда пользователи имеют сертификаты открытых ключей , необходимость в ЦРК отпадает. Это не означает, что отпадает необходимость в доверии и третьих сторонах; просто доверенной третьей стороной становится УЦ. Однако УЦ не участвует в обмене протоколами, и в отличие от ситуации с ЦРК , если УЦ недоступен, аутентификация по-прежнему может быть выполнена.
Аутентификацию при помощи сертификатов обеспечивают несколько распространенных протоколов, в частности, наиболее известный и широко распространенный протокол Secure Socket Layer (SSL), который применяется практически в каждом web-браузере. Помимо него применяются протоколы Transport Layer Security (TLS) >, Internet Key Exchange (IKE) >, S/MIME >, PGP и Open PGP >. Каждый из них немного по-своему использует сертификаты , но основные принципы - одни и те же.
Рис. 2.5. Взаимная аутентификация на базе сертификатов
Иллюстрирует типичный обмен сообщениями при аутентификации на базе сертификатов , использующий цифровые подписи >. Обмен соответствует стандарту аутентификации субъектов на основе криптографии с открытыми ключами >. Во многих протоколах предусматривается, что клиент направляет запрос серверу для того, чтобы инициировать аутентификацию. Такой подход, характерный, например, для дополнений аутентификации и шифрования к протоколу Internet File Transfer Protocol, гарантирует, что и пользователь, и сервер поддерживают один и тот же механизм аутентификации. Некоторые протоколы не требуют этого подготовительного шага.
Если сервер В поддерживает метод аутентификации, запрашиваемый пользователем А , то начинается обмен сообщениями. Сообщение Token ID уведомляет о том, что будет выполняться взаимная аутентификация , а также содержит номер версии протокола и идентификатор протокола. Хотя этот идентификатор не обязателен, он намного упрощает процедуру и поэтому обычно используется. Пользователь А ожидает сообщение Token ВА1 от сервера В. Идентификатор протокола в Token ID позволяет пользователю А удостовериться, что сервер В отправляет ожидаемое сообщение. Token ВА1 состоит только из случайного числа ran B , это - своего рода запрос, корректным ответом должна быть цифровая подпись числа ran B . Пользователь А подписывает ответ и отправляет свой сертификат ключа подписи, для того чтобы сервер В при помощи открытого ключа мог выполнить валидацию подписи.
Пользователь А подписывает последовательность из трех элементов: свой запрос ran A , запрос сервера ran B и имя сервера name B . Ran A - это запрос А к серверу В , гарантирующий, что пользователь А подписывает не произвольное сообщение сервера В или другого субъекта, выдающего себя за сервер В . Получив ответ Token АВ от пользователя А , сервер В проверяет, совпадает ли значение ran B с соответствующим значением в сообщении Token ВА1 , а по значению name В устанавливает, действительно ли пользователь А желает пройти аутентификацию сервера В . Если какая-либо из проверок дает отрицательный результат, то и аутентификация завершается неудачно. В противном случае сервер В проверяет подлинность сертификата пользователя А и его цифровую подпись, если сертификат и подпись валидны, то аутентификация пользователя А сервером В прошла успешно. Ответ сервера В пользователю А завершает взаимную аутентификацию .
Ответ сервера Token ВА2 состоит из заверенной цифровой подписью последовательности трех элементов: ran A , ran B и name A , где ran A - запрос, сгенерированный А , ran B - исходный запрос сервера В , а name A - имя пользователя А . Получив ответ сервера, пользователь А убеждается, что ran A имеет то же самое значение, что и в сообщении Token АВ , а проверяя значение name A - что сервер В намерен аутентифицировать именно его (пользователя А ). Если какая-либо из проверок дает отрицательный результат, то и аутентификация завершается неудачно. В противном случае пользователь А проверяет подлинность сертификата сервера В и его цифровой подписи. Если они валидны, то пользователь А аутентифицировал сервер В , и взаимная аутентификация выполнена.
Остальные материалы цикла:
Данная серия постов заказана и оплачена благотворительным фондом винникл Олега Крылова и всех-всех-всех.
Исходя из названия серии, мы, очевидно, будем говорить про цифровые сертификаты и аутентификацию. Для начала предлагаю классический бэкграунд аутентификации другими средствами (паролями же!).
Почти всю свою историю человек использует аутентификацию на основе комбинации логин и пароль. Логин уникально идентфицирует пользователя, а пароль (или секретное слово) подтверждает, что я — это я, а не Вася, который выдаёт себя за меня. Но давайте посмотрим слабые места парольной аутентификации в IT:
В большинстве случаев пользователи используют относительно короткие и несложные пароли для служб, где им нужен доступ. Среднестатистический человек вряд ли будет помнить более длинные пароли. Как показывает практика, эти пароли зачастую несложно угадать техническими методами или при помощи социальной инженерии. Но есть компании, которые требуют от пользователей использования более длинных и сложных паролей (т.е. комбинация букв обоих регистров, цифр и спец.символов). Это повышает надёжность пароля, но вызывает другую проблему:
Действительно пароль вида $gf)a90sfLq*wrF4 запомнить нелегко. С очень высокой долей вероятности, что пользователь после удачных выходных вряд ли в понедельник утром вспомнит его — звонок в тех.поддержку. Пока решается его вопрос с паролем, пользователь простаивает и ничего не делает, просто любуется экраном логона. Но можно выйти из ситуации и обойтись без звонка в тех.поддержку:
Я думаю, что многие администраторы с таким встречались. Поскольку наши пользователи очень современны, они часто обитают на различных интернет-ресурсах, форумах, чатах и прочих социальных сетях. Чтобы не сильно забивать себе голову паролями:
Нередко, когда пользователь зарегистрирован в десятке (а то и в десятках) мест, где используется один и тот же пароль. Потерял 1 пароль — потерял доступ всюду. Лично я не в состоянии удержать в голове все пароли от всех (да хотя бы топ-10) сайтов, где я бываю. Признаюсь, что у меня есть секретный текстовый файл, где я записываю все свои пароли и на сегодняшний день он имеет размер в 5кб. Я знаю, что это несекурно, но пока ничего лучше не придумал (если есть идеи, можете их озвучить в комментариях).
Об этом можно говорить долго и упорно, но смысла это не добавит, поэтому переходим дальше.
Цифровые сертификаты — это альтернативная форма идентификации пользователя. Здесь и далее я буду говорить про цифровые сертификаты в контексте Active Directory.
Цифровой сертификат — это документ, защищённый цифровой подписью (т.е. защищён от подделки), который содержит необходимую информацию о его владельце, которая позволяет уникально идентифицировать пользователя. Эта информация включает как минимум логонную информацию (адрес учётной записи в каталоге Active Directory или его User Principal Name — UPN). Поскольку цифровые сертификаты это часть инфраструктуры открытого ключа, они обязательно содержат открытый ключ.
Ассоциированый с этим открытым ключом, закрытый ключ хранится отдельно от сертификата в защищённом хранилище и только владелец сертификата должен иметь доступ к ассоциированному закрытому ключу. Напомню про главные особенности открытого и закрытого ключей:
Сертификат не подвержен ни одной из проблем, которым подвержены пароли. Надёжность сертификата главным образом обеспечивается его сложностью и надёжностью хранения. В современных системах закрытые ключи хранятся на жёстких дисках компьютеров. Следовательно, получив полный доступ к диску, можно получить и доступ к закрытому ключу и сертификаты на этой машине (а представьте, это сервер CA?) становятся скомпрометированными. Для укрепления физической защиты ключей необходимо иметь надёжное хранилище для них, которым и выступает смарт-карта.
Смарт-карта это устройство со встроенным микрочипом, который хранит цифровой сертификат и закрытый ключ от него. Микрочип устроен так, что извлечь закрытый ключ из него не представляется возможным, а получить доступ можно только путём ввода отдельного пароля, называемым PIN (Personal Identification Number) . Ряд смарт-карт оборудуются дополнительным элементом физической защиты, при разрушении которой уничтожаются и хранимые на них ключи и сертификаты. Это защитная мера, которая предотвращает доступ к ключам и защищённой этими ключами информации при попытке физического доступа к микрочипу, что и есть главное условие безопасности.
В Microsoft Windows мы можем применять пользовательские сертификаты для:
Данный список покрывает уже достаточно полезных вещей, где можно применять сертификаты. На этом я завершаю вводную часть и в следующих сериях мы узнаем про принципы работы такой аутентификации, маппинге сертификатов и многом другом.
Сертификат - это набор данных, определяющих какую-либо сущность (пользователя или устройство) в привязке к открытому ключу ключевой пары открытый/секретный ключ. Обычный сертификат содержит информацию о сущности и указывает цели, с которыми может использоваться сертификат, а также расположение дополнительной информации о месте выпуска сертификата. Сертификат подписан цифровой подписью выпустившего его центра сертификации (СА).
Инфраструктура, используемая для поддержки сертификатов в организации, называется инфраструктурой открытого ключа (Public Key Infrastructure, PKI).
Сертификат может быть сам по себе широкодоступен (передаваться по электронной почте). Открытый ключ каждого сертификата имеет связанный с ним секретный ключ, который содержится в тайне и, как правило, хранится локально самим объектом-сущностью.
Важно, что в отличие от алгоритмов с симметричным ключом, где для расшифрования и шифрования используется один и тот же ключ, в алгоритмах с открытым/ секретным ключом используются два ключа: один для шифрования, а другой - для расшифровки. Если шифрование осуществляется с использованием открытого ключа, то расшифровать зашифрованный текст можно только с помощью соответствующего секретного ключа. Если шифрование осуществляется на секретном ключе, то расшифровать текст можно только с помощью соответствующего открытого ключа.
При использовании сертификатов для аутентификации секретный ключ применяется для шифрования или цифровой подписи некоторого запроса или «вопроса». Соответствующий открытый ключ (доступный в сертификате) может использоваться сервером или центральным сервером аутентификации для расшифровки запроса. Если результат соответствует ожидаемому, подлинность считается доказанной. Так как с помощью соответствующего открытого ключа можно успешно расшифровать вопрос, а секретным ключом, посредством которого был зашифрован вопрос, обладает только объект-сущность, сообщение должно исходить именно от этого объекта-сущности. Ниже приведены шаги описанного процесса аутентификации.
1. Клиент подает запрос аутентификации.
2. Сервер создаст вопрос.
3. Рабочая станция использует свой секретный ключ для шифрования вопроса.
4. Ответ возвращается серверу.
5. Так как сервер содержит копию сертификата, он может использовать открытый ключ для расшифровки ответа. Результат сравнивается с вопросом.
6. Если наблюдается совпадение, клиент успешно проходит аутентификацию. Данная концепция представлена на рис. 4.2.
Рис. 4.2. Аутентификация с использованием открытого и секретного ключей
Здесь полезно понять, что исходный набор ключей генерируется клиентом и в центр сертификации передается только открытый ключ. СА генерирует сертификат и подписывает его с помощью секретного ключа, после чего возвращает копию сертификата пользователю и его базе данных.
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 сервера в браузере.
3. Сервер получает запрос и отправляет свой сертификат сервера клиенту.
4. Браузер клиента проверяет свое хранилище сертификатов на наличие сертификата от центра сертификации, выпустившего сертификат сервера.
5. Если обнаруживается сертификат СА, браузер подтверждает сертификат посредством проверки подписи на сертификате сервера с использованием открытого ключа, имеющегося в сертификате СА.
6. Если проверка завершается успешно, браузер принимает сертификат сервера и считает его действительным.
7. Генерируется симметричный ключ шифрования, происходит его шифрование клиентом с использованием открытого ключа сервера.
8. Зашифрованный ключ возвращается серверу.
9. Сервер расшифровывает ключ с помощью собственного секретного ключа сервера. Для компьютера теперь общий ключ шифрования, который может использоваться для обеспечения безопасности соединений между ними.
Существует множество потенциальных проблем, связанных с данной системой.
· Если веб-сервер не настроен соответствующим образом на требование использования 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-разрядное шифрование. Также доступны другие длины ключей и уровни шифрования.
Похожая информация.
В том случае, когда пользователи имеют сертификаты открытых ключей, необходимость в ЦРК отпадает. Это не означает, что отпадает необходимость в доверии и третьих сторонах; просто доверенной третьей стороной становится УЦ. Однако УЦ не участвует в обмене протоколами, и в отличие от ситуации с ЦРК, если УЦ недоступен, аутентификация по-прежнему может быть выполнена.
Аутентификацию при помощи сертификатов обеспечивают несколько распространенных протоколов, в частности, наиболее известный и широко распространенный протокол Secure Socket Layer (SSL), который применяется практически в каждом web-браузере. Помимо него применяются протоколы Transport Layer Security (TLS), Internet Key Exchange (IKE), S/MIME, PGP и Open PGP. Каждый из них немного по-своему использует сертификаты, но основные принципы - одни и те же.
Рассмотрим обмен сообщениями при аутентификации на базе сертификатов, использующий цифровые подписи. Обмен соответствует стандарту аутентификации субъектов на основе криптографии с открытыми ключами. Во многих протоколах предусматривается, что клиент направляет запрос серверу для того, чтобы инициировать аутентификацию. Если сервер В поддерживает метод аутентификации, запрашиваемый пользователем А, то начинается обмен сообщениями. Сообщение Token ID уведомляет о том, что будет выполняться взаимная аутентификация, а также содержит номер версии протокола и идентификатор протокола. Пользователь А ожидает сообщение Token ВА1 от сервера В. Идентификатор протокола в Token ID позволяет пользователю А удостовериться, что сервер В отправляет ожидаемое сообщение. Token ВА1 состоит только из случайного числа ran B, это - своего рода запрос, корректным ответом должна быть цифровая подпись числа ran B. Пользователь А подписывает ответ и отправляет свой сертификат ключа подписи, для того чтобы сервер В при помощи открытого ключа мог выполнить валидацию подписи.
Пользователь А подписывает последовательность из трех элементов: свой запрос ran A, запрос сервера ran B и имя сервера name B. Ran A - это запрос А к серверу В, гарантирующий, что пользователь А подписывает не произвольное сообщение сервера В или другого субъекта, выдающего себя за сервер В. Получив ответ Token АВ от пользователя А, сервер В проверяет, совпадает ли значение ran B с соответствующим значением в сообщении Token ВА1, а по значению name В устанавливает, действительно ли пользователь А желает пройти аутентификацию сервера В. Если какая-либо из проверок дает отрицательный результат, то и аутентификация завершается неудачно. В противном случае сервер В проверяет подлинность сертификата пользователя А и его цифровую подпись, если сертификат и подпись валидны, то аутентификация пользователя А сервером В прошла успешно. Ответ сервера В пользователю А завершает взаимную аутентификацию.
Ответ сервера Token ВА2 состоит из заверенной цифровой подписью последовательности трех элементов: ran A, ran B и name A, где ran A - запрос, сгенерированный А, ran B - исходный запрос сервера В, а name A - имя пользователя А. Получив ответ сервера, пользователь А убеждается, что ran A имеет то же самое значение, что и в сообщении Token АВ, а проверяя значение name A - что сервер В намерен аутентифицировать именно его (пользователя А). Если какая-либо из проверок дает отрицательный результат, то и аутентификация завершается неудачно. В противном случае пользователь А проверяет подлинность сертификата сервера В и его цифровой подписи. Если они валидны, то пользователь А аутентифицировал сервер В, и взаимная аутентификация выполнена.
Итак, механизмы аутентификации при помощи сертификатов поддерживают аутентификацию в открытой сети, на многих удаленных серверах, и обеспечивают взаимную аутентификацию. В отличие от системы Kerberos протоколы аутентификации на базе сертификатов не требуют активного участия третьих сторон. Для успешной аутентификации должны быть доступны только пользователь и сервер.
Когда число пользователей в сети измеряется миллионами, процедура предварительной регистрации пользователей, связанная с назначением и хранением паролей пользователей, становится крайне громоздкой и практически плохо реализуемой. В таких условиях аутентификация на основе цифровых сертификатов служит рациональной альтернативой применению паролей.
При использовании цифровых сертификатов компьютерная сеть, которая дает доступ к своим ресурсам, не хранит никакой информации о своих пользователях. Эту информацию пользователи предоставляют сами в своих запросах – сертификатах. Такое решение масштабируется гораздо легче, чем вариант с использованием паролей централизованной базой данных. При этом задача хранения секретной информации, в частности закрытых ключей, возлагается теперь на самих пользователей.
Цифровые сертификаты, удостоверяющие личность пользователя, выдаются по запросам пользователей специальными уполномоченными организациями – центрами сертификации при выполнении определенных условий. Следует отметить, что сама процедура получения сертификата также включает этап проверки подлинности (то есть аутентификации) пользователя. Здесь в качестве проверяющей стороны выступает сертифицирующая организация.
Для получения сертификата клиент должен представить в центр сертификации сведения, удостоверяющие его личность, и свой открытый ключ. Перечень необходимых данных зависит от типа получаемого сертификата. Сертифицирующая организация после проверки доказательств подлинности пользователя помещает свою цифровую подпись в файл, содержащий открытый ключ и сведения о пользователе, и выдает ему сертификат, подтверждая факт принадлежности данного открытого ключа конкретному лицу.
Сертификат представляет собой электронную форму, в которой содержится следующая информация:
· открытый ключ владельца данного сертификата;
· сведения о владельце сертификата, например имя, электронный адрес, наименование организации, в которой работает данный сотрудник и т.п.;
· наименование сертифицирующей организации, выдавшей этот сертификат;
· электронная подпись сертифицирующей организации – зашифрованные закрытым ключом этой организации данные, содержащиеся в сертификате.
Сертификат является средством аутентификации пользователя при его обращении к сетевым ресурсам. При этом роль проверяющей стороны играют серверы аутентификации корпоративной сети.
Следует особо отметить тесную связь открытых ключей с сертификатами. Сертификат является не только удостоверением личности, но и удостоверением принадлежности открытого ключа. Цифровой сертификат устанавливает и гарантирует соответствие между открытым ключом и его владельцем. Это предотвращает угрозу подмены открытого ключа.
Если абонент получает от партнера по информационному обмену открытый ключ в составе сертификата, то он может проверить цифровую подпись центра сертификации на этом сертификате с помощью открытого ключа данного центром сертификации и убедиться, что полученный открытый ключ принадлежит именно тому пользователю, адрес и другие сведения о котором содержатся в данном сертификате. При использовании сертификатов исчезает необходимость хранить на серверах корпораций списки пользователей с их паролями. На сервере достаточно иметь список имен и открытых ключей сертифицирующих организаций.
Применение сертификатов основано на предположении, что сертифицирующих организаций относительно немного, и их открытые ключи могут быть доступны всем заинтересованным лицам и организациям (например, с помощью публикаций в журналах).
При реализации процесса аутентификации на основе сертификатов исключительно важно решение вопроса о том, кто будет выполнять функции сертифицирующей организации. Вполне естественным является решение, при котором задачу обеспечения своих сотрудников сертификатами берет на себя само предприятие. На предприятии хранится достаточно много сведений о сотрудниках, а следовательно, оно может взять на себя задачу подтверждения их личности. Это упрощает процедуру первичной аутентификации при выдаче сертификата. Предприятия могут использовать существующие программные продукты, обеспечивающие автоматизацию процессов генерации, выдачи и обслуживания сертификатов. Например, компания Netscape Communications предлагает свои серверы предприятиям для выпуска ими собственных сертификатов.
Альтернативное решение проблемы выполнения функций сертифицирующей организации – привлечение на коммерческой основе независимых центров по выдаче сертификатов. Такие услуги предлагает, в частности, сертифицирующий центр компании Verisign. Ее сертификаты удовлетворяют требованиям международного стандарта Х.509 и используются в ряде продуктов защиты данных, например в протоколе защищенного канала SSL.
