Необходимость защиты информации
Продолжающееся бурное развитие компьютерных технологий и повсеместное внедрение в бизнес с использованием Интернета коренным образом изменяет устоявшиеся способы ведения бизнеса. Системы корпоративной безопасности, обеспечивающие бизнес, тоже не могут оставаться в стороне.
В настоящее время, например, средства электронной почты, используются не только для общения между людьми, а для передачи контрактов и конфиденциальной финансовой информации. Web сервера используются не только для рекламных целей, но и для распространения программного обеспечения и электронной коммерции. Электронная почта, доступ к Web серверу, электронная коммерция, VPN требуют применения дополнительных средств для обеспечения конфиденциальности, аутентификации, контроля доступа, целостности и идентификации. В настоящее время в качестве таких средств повсеместно используются средства криптографической защиты и Инфраструктура Открытых Ключей (ИОК).
Система криптографической защиты должна обеспечивать:
Криптографическое преобразование (шифрование)- взаимно-однозначное математическое преобразование, зависящее от ключа (секретный параметр преобразования), которое ставит в соответствие блоку открытой информации (представленной в некоторой цифровой кодировке) блок шифрованной информации, также представленной в цифровой кодировке. Термин шифрование объединяет в себе два процесса: зашифрование и расшифрование информации.
Криптография делится на два класса: с симметричными ключами и открытыми ключами.
В криптографии с симметричными ключами отправитель и получатель используют один и тот же (общий) ключ, как для шифрования, так и для расшифрования.
Преимущества криптографии с симметричными ключами:
Недостатки криптографии с симметричными ключами:
В криптографии с открытыми ключами используется пара ключей: открытый ключ и секретный (личный) ключ, известный только его владельцу. В отличие от секретного ключа, который должен сохраняться в тайне, открытый ключ может распространяться по сети. Секретный ключ в криптографии с открытыми ключами используется для формирования электронной подписи и расшифрования данных.
Криптография с открытыми ключами обеспечивает все требования, предъявляемые к криптографическим системам. Но реализация алгоритмов требует больших затрат процессорного времени. Поэтому в чистом виде криптография с открытыми ключами в мировой практике обычно не применяется. Для шифрования данных используются симметричные (сеансовые) ключи, которые в свою очередь шифруются с использованием открытых для передачи сеансовых ключей по сети.
Криптография с открытыми ключами требует наличия Инфраструктуры Открытых Ключей (PKI - Public Key Infrastructure) - неотъемлемого сервиса для управления электронными сертификатами и ключами пользователей, прикладного обеспечения и систем.
Верификация открытого ключа
Непосредственное использование открытых ключей требует дополнительной их защиты и идентификации для определения связи с секретным ключом. Без такой дополнительной защиты злоумышленник может представить себя как отправителем подписанных данных, так и получателем зашифрованных данных, заменив значение открытого ключа или нарушив его идентификацию. В этом случае каждый может выдать себя за английскую королеву. Все это приводит к необходимости верификации открытого ключа. Для этих целей используется электронный сертификат.
Электронный сертификат представляет собой цифровой документ, который связывает открытый ключ с определенным пользователем или приложением. Для заверения электронного сертификата используется электронная цифровая подпись доверенного центра - Центра Сертификации (ЦС). Исходя из функций, которые выполняет ЦС, он является основной компонентой всей Инфраструктуры Открытых Ключей. Используя открытый ключ ЦС, каждый пользователь может проверить достоверность электронного сертификата, выпущенного ЦС, и воспользоваться его содержимым.
Верификация цепочки сертификатов
Как описывалось ранее, доверие любому сертификату пользователя определяется на основе цепочки сертификатов. Причем начальным элементом цепочки является сертификат центра сертификации, хранящийся в защищенном персональном справочнике пользователя.
Процедура верификации цепочки сертификатов описана в рекомендациях X.509 и RFC 2459 и проверяет связанность между именем Владельца сертификата и его открытым ключом. Процедура верификации цепочки подразумевает, что все "правильные" цепочки начинаются с сертификатов, изданных одним доверенным центром сертификации. Под доверенным центром понимается главный ЦС, открытый ключ которого содержится в самоподписанном сертификате. Такое ограничение упрощает процедуру верификации, хотя наличие самоподписанного сертификата и его криптографическая проверка не обеспечивают безопасности. Для обеспечения доверия к открытому ключу такого сертификата должны быть применены специальные способы его распространения и хранения, так как на данном открытом ключе проверяются все остальные сертификаты.
Алгоритм верификации цепочек использует следующие данные:
Цепочка сертификатов представляет собой последовательность из n сертификатов, в которой:
Одновременно с цепочкой сертификатов используется цепочка СОС, представляющая собой последовательность из n СОС, в которой:
После построения двух цепочек (сертификатов и СОС) выполняется:
В состав компонент ИОК входят следующие компоненты:
Центр Сертификации (или Удостоверяющий Центр) - основная управляющая компонента ИОК, предназначенная для формирования электронных сертификатов подчиненных Центров и конечных пользователей. Кроме сертификатов, ЦС формирует список отозванных сертификатов X.509 CRL (СОС) с регулярностью, определенной Регламентом системы.
К основным функция ЦС относятся:
Опциональная компонента ИОК, предназначенная для регистрации конечных пользователей. Основная задача ЦР - регистрация пользователей и обеспечение их взаимодействия с ЦС. В задачи ЦР может также входить публикация сертификатов и СОС в сетевом справочнике LDAP.
Пользователь, приложение или система, являющиеся Владельцами сертификата и использующие ИОК.
Опциональная компонента ИОК, содержащая сертификаты и списки отозванных сертификатов и служащая для целей распространения этих объектов среди пользователей с использованием протокола LDAP (HTTP, FTP).
ИОК используется для управления ключами и электронными сертификатами в приложениях (таких как электронная почта, Web приложения, электронная коммерция), использующих криптографию для установления защищенных сетевых соединений (S/MIME, SSL, IPSEC), или для формирования ЭЦП электронных документов, приложений и т.д. Кроме того, ИОК может быть использована для корпоративных приложений.
Защищенные электронная почта и документооборот используют криптографию для шифрования сообщений или файлов и формирования ЭЦП. Из наиболее известных и распространенных стандартов стоит отметить протокол S/MIME (Secure Multipurpose Internet Mail Extensions), который является расширением стандарта Internet почты MIME (Multipurpose Internet Mail Extensions).
Web броузеры и сервера используют ИОК для аутентификации и конфиденциальности сессии, а также для онлайновых банковских приложений и электронных магазинов. Наиболее распространенным протоколом в этой сфере является протокол SSL (Secure Sockets Layer). Протокол SSL не ограничивается применением только для защиты HTTP (Hypertext Transfer Protocol), а также может быть использован для FTP (File Transfer Protocol) и Telnet.
Использование ЭЦП для подписи приложений и файлов позволяет безопасно распространять их по сети Internet. При этом пользователь уверен в корректности полученного приложения от фирмы-разработчика.
Стандарты в области ИОК делятся на две группы: часть из них описывает собственно реализацию ИОК, а вторая часть, которая относится к пользовательскому уровню, использует ИОК, не определяя ее. На приведенном рисунке показана связь приложений со стандартами. Стандартизация в области ИОК позволяет различным приложениям взаимодействовать между собой с использованием единой ИОК.
В особенности стандартизация важна в области:
Основным центром по выпуску согласованных стандартов в области ИОК является рабочая группа ИОК (PKI working group) организации IETF (Internet Engineering Task Force), известная как группа PKIX (от сокращения PKI for X.509 certificates).
Спецификации PKIX основаны на двух группах стандартов: X.509 ITU-T (Международный комитет по телекоммуникациям) и PKCS (Public Key Cryptography Standards) firmy RSA Data Security. X.509 изначально был предназначен для спецификации аутентификации при использовании в составе сервиса X.500 директории. Фактически же, синтаксис электронного сертификата, предложенный в X.509 признан стандартом де-факто и получил всеобщее распространение независимо от X.500. Однако X.509 ITU-T не был предназначен для полного определения ИОК. В целях применения стандартов X.509 в повседневной практике пользователи, поставщики и комитеты по стандартизации обращаются к стандартам PKCS. PKIX группа издала следующие стандарты Internet (RFC).
Формат сертификата Х.509
Х.509 - это другой очень распространённый формат. Все сертификаты Х.509 соответствуют международному стандарту ITU-T X.509; таким образом (теоретически), сертификат Х.509, созданный для одного приложения, может быть использован в любом другом, поддерживающем этот стандарт. На практике, однако, сложилась ситуация, что разные компании создают собственные расширения для Х.509, не все из которых между собой совместимы.
Всякий сертификат требует, чтобы кто-то заверил взаимосвязность открытого ключа и идентифицирующей владельца ключа информации. Имея дело с PGP-сертификатом, каждый может выступать в качестве заверителя содержащихся в нём сведений (за исключением случаев, когда эта возможность намеренно ограничена политикой безопасности). Но в случае сертификатов Х.509 заверителем может быть только Центр сертификации или некто, специально уполномоченный им на эту роль. (Имейте в виду, что PGP-сертификаты также в полной мере поддерживают иерархическое структурирование системы доверия, использующее ЦС для удостоверения сертификатов.)
Сертификат Х.509 - это набор стандартных полей, содержащих сведения о пользователе или устройстве, и их соответствующий открытый ключ. Стардарт Х.509 определяет, какие сведения входят в сертификат и как они кодируются (формат данных).
Сертификат Х.509 содержит следующие сведения:
Версия Х.509 - указывает, на основе какой версии стандарта Х.509 построен данный сертификат, что определяет, какая информация может в нём содержаться.
Открытый ключ владельца сертификата - открытый ключ наряду с идентификатором используемого алгоритма (указывающим криптосистему, к которой принадлежит данный ключ) и прочая информация о параметрах ключа.
Серийный номер сертификата - организация-издатель сертификата обязана присвоить ему уникальный серийный (порядковый) номер для его опознавания среди прочих сертификатов, выданных данной организацией. Эта информация применяется в ряде случаев; например, при аннулировании сертификата, его серийный номер помещается в список аннулированных сертификатов (Certificate Revocation List, CRL).
Уникальный опознаватель владельца ключа (или DN, distinguished name - уникальное имя) - это имя должно быть уникальным и единственным во всём Интернете. DN состоит из нескольких подпунктов и может выглядеть примерно так:
CN=Bob Davis, [email protected], OU=PGP Engineering,
O=PGP Corporation, C=US
(Что обозначает Понятное имя субъекта, Электронную почту, Подразделение организации, Организацию и Страну соответственно.)
Период действия сертификата - дата начала действия сертификата и дата окончания его действия; указывает на то, когда сертификат станет недействителен.
Уникальное имя издателя - уникальное имя организации, подписавшей сертификат. Обычно, это наименование Центра сертификации. Использование сертификата подразумевает доверие организации, его подписавшей. (В случаях с корневыми сертификатами выдавшая организация - этот же ЦС - подписывает его сама.)
ЭЦП издателя - электронная подпись, созданная закрытым ключом организации, выдавшей сертификат. Идентификатор алгоритма подписи - указывает алгоритм, использованный ЦС для подписания сертификата.
Существует ряд фундаментальных различий между форматами сертификатов Х.509 и PGP:
вы можете лично создать собственный сертификат PGP;
вы должны запросить и получить сертификат Х.509 от Центра сертификации; сертификаты Х.509 содержат только одно имя владельца сертификата;
сертификаты Х.509 содержат только одну ЭЦП, подтверждающую подлинность сертификата.
Чтобы получить сертификат Х.509, вы должны попросить ЦС выдать его вам. Вы предоставляете системе свой открытый ключ, чем доказываете, что обладаете соответствующим закрытым, а также некоторые идентифицирующие вас сведения. Затем вы электронно подписываете эти сведения и отправляете весь пакет - запрос сертификата - в Центр сертификации. ЦС выполняет определённый процесс по проверке подлинности предоставленной информации и, если всё сходится, создаёт сертификат, подписывает и возвращает вам.
Вы можете представить сертификат Х.509, как обычный бумажный сертификат или аттестат с приклеенным к нему открытым ключом. На нём указано ваше имя, а также некоторые сведения о вас, плюс подпись издателя сертификата.
Вероятно, наибольшая польза от сертификатов Х.509, это их применение в Веб-браузерах.
Из книги Искусство программирования для Unix автора Реймонд Эрик Стивен Из книги Windows Script Host для Windows 2000/XP автора Попов Андрей ВладимировичСпособы получения цифрового сертификата Различаются цифровые сертификаты трех типов: созданные разработчиком, выданные разработчику организацией и полученные от центра сертификации.Цифровой сертификат, созданный разработчиком, обычно используют те пользователи,
Из книги Инфраструктуры открытых ключей автора Полянская Ольга ЮрьевнаСоздание собственного сертификата Наиболее быстрым способом создания собственного цифрового сертификата является использование программы SelfCert.exe, входящей в состав Microsoft Office 2000/ХР. Запустив эту утилиту, мы получим диалоговое окно, позволяющее задать имя создаваемого
Из книги Яндекс для всех автора Абрамзон М. Г.Дополнения сертификата Важная информация находится также в дополнениях сертификата. Они позволяют включать в сертификат информацию, которая отсутствует в основном содержании, определять валидность сертификата и наличие у владельца сертификата прав доступа к той или
Из книги Введение в криптографию автора Циммерманн ФилиппОнлайновый протокол статуса сертификата Онлайновый протокол статуса сертификата OCSP - относительно простой протокол (типа "запрос-ответ") для получения информации об аннулировании от доверенного субъекта, называемого OCSP-респондером. OCSP-запрос состоит из номера версии
Из книги Операционная система UNIX автора Робачевский Андрей М.Базовый контроль сертификата Базовый контроль сертификата выполняется для всех сертификатов последовательности и состоит из ряда проверок . Проверки, использующие каждую из четырех групп переменных состояния, выполняются, чтобы определить, не является ли
Из книги автораПроверка срока действия сертификата Эта проверка завершается успешно, если текущие дата и время на момент валидации находятся в пределах срока действия
Из книги автораПроверка статуса сертификата Эта проверка завершается успешно, если издатель не аннулировал данный сертификат. Основным средством проверки статуса сертификата являются списки САС, но могут использоваться и другие альтернативные средства
Из книги автораПроверка подписи сертификата Подпись сертификата может быть проверена на базе первой группы переменных состояния при помощи открытого ключа издателя сертификата, использования корректных параметров и алгоритма цифровой
Из книги автораПодготовка следующего сертификата Сначала выполняется некоторая простая проверка сертификата УЦ. Затем обновляются переменные состояния, для того чтобы они могли отражать значения полей дополнений сертификата. Существует несколько дополнений, которые встречаются
Из книги автораЗавершение обработки сертификата Когда завершается обработка сертификата конечного субъекта, на основании значений переменных состояния устанавливаются выходные значения.Корректировка переменных состояния верификации цифровой подписи. В поле информации об
Из книги автора3.3.1. Формат RSS Читать новости сайтов можно по-разному. Самый простой способ - заходить время от времени на сайт и просматривать новые сообщения. Можно поставить программу, которая подключается к новостному каналу и сама получает заголовки или аннотации новостей, по
Из книги автораФормат сертификата Х.509 Х.509 - это другой очень распространённый формат. Все сертификаты Х.509 соответствуют международному стандарту ITU-T X.509; таким образом (теоретически), сертификат Х.509, созданный для одного приложения, может быть использован в любом другом,
Из книги автораАннулирование сертификата Применение сертификата допустимо только пока он достоверен. Опасно полагаться на то, что сертификат будет защищён и надёжен вечно. В большинстве организаций и во всех PKI сертификат имеет ограниченный срок "жизни". Это сужает период, в который
Из книги автораУведомление об аннулировании сертификата После аннулирования сертификата крайне важно оповестить всех потенциальных корреспондентов, что он более недействителен. Наиболее простой способ оповещения в среде PGP - это размещение аннулированного сертификата на
Из книги автораФормат ELF Формат ELF имеет файлы нескольких типов, которые до сих пор мы называли по-разному, например, исполняемый файл или объектный файл. Тем не менее стандарт ELF различает следующие типы:1. Перемещаемый файл (relocatable file), хранящий инструкции и данные, которые могут быть
OS: Linux Debian/Ubuntu.
Application: OpenSSL, Nginx, Apache2.
Здесь простейшая шпаргалка процедуры подготовки к приобретению SSL/TLS-сертификата, проверки его корректности и применения в web-сервисе, расширенная некоторыми пояснениями.
Генерируем закрытый и открытый ключи.
Работы с компонентами сертификата очень желательно проводить в месте, закрытом от доступа посторонних:
$ mkdir -p ./make-cert
$ cd ./make-cert
$ openssl genrsa -des3 -out ./example.net.key 2048
Мешанина символов, которую мы видим в текстовом файле ключей на самом деле представляет собой контейнер обфусцированного набора блоков сгенерированных в соответствии с алгоритмом RSA уникальных шифров, и один из этих блоков - "modulus" - является "открытым" ключём связки асимметричного шифрования, используемым во всех компонентах сертификата. Всё остальное содержимое - "закрытый" ключ.
$ openssl rsa -noout -text -in ./example.net.key
Надо отметить, что на практике, когда SSL-сертфикат применяется всего лишь для перевода на HTTPS ряда сайтов, большинство предпочитает не возиться с запароленным контейнером ключей, а сразу освобождает его от этой защиты, создавая рядом ещё один - "беспарольный":
$ cd ./make-cert
$ openssl rsa -in ./example.net.key -out ./example.net.key.decrypt
Сама по себе подсистема защиты потока трафика посредством SSL/TLS обычно реализуется на сессионных симметричных ключах, вырабатываемых web-сервером и браузером клиента при первичном согласовании соединения, и какие-то особые предустановленные ключи шифрования для этого не требуются (хотя и облегчают процедуру согласования - DH-key, например). Сертификат же (стандарта X.509), набор компонентов которого мы здесь поэтапно формируем, предназначен для своего рода подтверждения подлинности web-ресурса в интернет-инфраструктуре, где условно доверенный центр сертификации гарантирует связь указанных в сертификате "открытого" ключа и описания ресурса посредством электронной подписи содержимого такового.
Для передачи центру сертификации нашего "публичного" ключа (не всего содержимого "приватного" ключа, а лишь его блока "modulus"!) и сведений о ресурсе, подлинность которого мы подтверждаем, предназначен специальный CSR-контейнер (Certificate Signing Request). Создаём его, указывая в качестве источника "открытого" ключа контейнер таковых:
$ cd ./make-cert
$ openssl req -new -key ./example.net.key -out ./example.net.csr
"Country Name" - двухсимвольный код страны согласно ISO-3166 (RU - для России);
"State or Province Name" - название области или региона;
"Locality Name" - название города или населённого пункта;
"Organization Name" - название организации;
"Organizational Unit Name" - название подразделения (необязательное поле);
"Common Name" - полностью определённое доменное имя ресурса (FQDN), для которого запрашивается сертификат;
"Email Address" - контактный e-mail адрес администратора доменного имени (необязательное поле);
"A challenge password" - (необязательное поле, не заполняется);
"An optional company name" - альтернативное имя компании (необязательное поле, не заполняется).
Любопытствующие могут посмотреть, что скрыто в коде CSR-контейнера:
$ openssl req -noout -text -in ./example.net.csr
Приобретение SSL/TLS-сертификата (X.509).
Нюансы выбора поставщика сертификата, процедуры оформления заказа и оплаты здесь не рассматриваются, это не технический вопрос. Один из немаловажных моментов - не пропустить выбор между сертификатом предназначенным для одного домена и "wildcard", покрывающий своими гарантиями все поддомены следующего уровня.
Генерирование самоподписанного X.509-сертификата (опционально).
Как вариант, для использования исключительно в локальной сети, можно создать требуемый сертификат самостоятельно, подписав его своим "закрытым" ключём вместо доверенного центра сертификации - так называемый "self-signed" (самоподписанный):
$ cd ./make-cert
$ openssl x509 -req -days 1095 -in ./example.net.csr -signkey ./example.net.key -out ./example.net.crt
Проверка корректности сертификатов и ключей.
В полученном SSL/TLS-сертификате зафиксирована как минимум следующая информация:
Версия сертификата;
Серийный номер сертификата;
Алгоритм подписи;
Полное (уникальное) имя владельца сертификата;
Открытый ключ владельца сертификата;
Дата выдачи сертификата;
Дата окончания действия сертификата;
Полное (уникальное) имя центра сертификации;
Цифровая подпись издателя.
$ cd ./make-cert
$ openssl x509 -noout -text -in ./example.net.crt
Простейший способ проверки корректности связки "приватного" ключа, CSR-запроса и финального X.509-сертификата заключается в сверке контрольной суммы "публичного" ключа (блока "modulus"), содержащегося во всех этих контейнерах:
$ openssl rsa -noout -modulus -in ./example.net.key | openssl md5
$ openssl req -noout -modulus -in ./example.net.csr | openssl md5
$ openssl x509 -noout -modulus -in ./example.net.crt | openssl md5
Формируем типовой набор файлов сертификатов и ключей.
Обычно центры сертификации предоставляют не только запрашиваемый сертификат, а ещё и дополнительный набор промежуточных сертификатов (самого центра, его вышестоящего узла, и так вплоть до корневого узла).
В общем, в процессе у нас может скопиться несколько файлов, которые я именую соответственно их функционалу, примерно так:
"example.net.key" - контейнер с "закрытым" и "открытым" ключами (защищённый паролем);
"example.net.key.decrypt" - незащищённый паролем контейнер с "закрытым" и "открытым" ключами;
"example.net.csr" - CSR-запрос, использовавшийся при заказе сертификата;
"example.net.crt" - непосредственно наш X.509-сертификат;
"intermediate.crt" - сертификат (или цепочка таковых) центра сертификации;
"root.crt" - сертификат корневого центра, от которого начинается цепь доверия.
$ cd ./make-cert
$ cat ./example.net.crt >> ./example.net-chain.crt
$ сat ./intermediate.crt >> ./example.net-chain.crt
$ cat ./root.crt >> ./example.net-chain.crt
В Linux-е для сертификатов и ключей шифрования уже предусмотрены места в файловой системе. Распределяем файлы и защищаем их от доступа посторонних:
# mkdir -p /etc/ssl/certs
# mkdir -p /etc/ssl/private
# cp ./example.net-chain.crt /etc/ssl/certs/
# cp ./example.net.key.decrypt /etc/ssl/private/
# chown -R root:root /etc/ssl
# chmod -R o-rwx /etc/ssl
В самом простом случае применение SSL-сертификата в web-сервере "Nginx" реализуется примерно следующим образом:
# vi /etc/nginx/sites-enabled/example.net.conf
....
server {
listen 443 ssl;
server_name example.net;
....
ssl on;
ssl_dhparam /etc/nginx/ssl/dhparam.pem;
ssl_protocols SSLv3 TLSv1 TLSv1.1 TLSv1.2;
ssl_ciphers AES256-SHA:RC4:HIGH:!aNULL:!MD5:!kEDH;
ssl_prefer_server_ciphers on;
ssl_session_cache shared:SSL:30m;
ssl_session_timeout 1h;
ssl_certificate /etc/ssl/certs/example.net-chain.crt;
ssl_certificate_key /etc/ssl/private/example.net.key.decrypt;
....
}
....
В web-сервере "Apache" SSL-сертификат применяется примерно так:
# vi /etc/apache2/sites-enabled/example.net.conf
....
# Описание рабочего окружения доступного по HTTPS web-сайта
ServerName example.net
....
# Рекомендуемые обобщённые настройки протокола
SSLEngine on
SSLProtocol all -SSLv2
SSLHonorCipherOrder on
SSLCipherSuite HIGH:MEDIUM:!aNULL:!eNULL:!EXPORT:!DES:!MD5:!PSK:!RC4:!aECDH:+SHA1:+MD5:+HIGH:+MEDIUM
SSLOptions +StrictRequire
SSLCompression off
# Файлы сертификатов и ключей
SSLCertificateFile /etc/ssl/certs/example.net-chain.crt
SSLCertificateKeyFile /etc/ssl/certs/example.net.key.decrypt
....
Результатом усилий технических специалистов по повышению безопасности Интернета стала разработка группы протоколов безопасности, таких как S/MIME, TLS и IPsec. Все эти протоколы используют криптографию с открытыми ключами для обеспечения сервисов конфиденциальности, целостности данных, аутентификации источника данных и неотказуемости.
Цель PKI состоит в обеспечении надежного и эффективного управления ключами и сертификатами открытых ключей . Пользователи систем, основанных на PKI, должны быть уверены, что в любой момент времени при коммуникации с определенным субъектом они полагаются на открытый ключ, связанный с секретным ключом, владельцем которого является именно этот субъект. Эта уверенность возникает в результате использования сертификатов открытых ключей , связывающих значения открытых ключей с их владельцами. Связывание происходит в результате проверки доверенным УЦ идентичности субъекта и заверения цифровой подписью каждого сертификата открытого ключа.
| Термин на английском языке | Аббревиатура | Термин на русском языке |
|---|---|---|
| Attribute Authority | AA | Атрибутный центр |
| Attribute Certificate | AC | Атрибутный сертификат |
| Certificate | Сертификат | |
| Certification Authority | CA | Удостоверяющий центр (УЦ) |
| Certificate Policy | CP | Политика применения сертификатов (ППС) |
| Certification Practice Statement | CPS | Регламент УЦ |
| End-Entity | EE | Конечный субъект |
| Public Key Certificate | PKC | Сертификат открытого ключа |
| Public Key Infrastructure | PKI | Инфраструктура открытых ключей |
| Privilege Management Infrastructure | PMI | Инфраструктура управления привилегиями |
| Registration Authority | RA | Регистрационный центр (РЦ) |
| Relying Party | Доверяющая сторона | |
| Root CA | Корневой УЦ | |
| Subordinate CA | Подчиненный УЦ | |
| Subject | Субъект | |
| Top CA | УЦ верхнего уровня |
Согласно стандартам PKIX, PKI представляет собой комплекс программного и аппаратного обеспечения, персонала, а также политик и процедур, необходимых для создания, управления, хранения, распространения и аннулирования сертификатов открытых ключей . Компоненты PKI представлены в табл. 15.6 . Сертификат открытого ключа имеет ограниченный период действия , который зафиксирован в содержании сертификата. Поскольку клиент должен иметь возможность самостоятельно проверить подпись сертификата открытого ключа и его срок действия, сертификаты должны открыто публиковаться и распространяться посредством даже ненадежных коммуникаций и систем серверов.
| Компонент | Описание |
|---|---|
| Удостоверяющие центры (УЦ) | Выпускают и аннулируют сертификаты |
| Регистрационные центры (РЦ) | Подтверждают связывание открытых ключей и личностей владельцев сертификатов и других атрибутов |
| Владельцы сертификатов | Подписывают и шифруют электронные документы |
| Клиенты | Проверяют подлинность цифровых подписей и соответствующих цепочек сертификатов при помощи открытого ключа доверенного УЦ |
| Репозитории | Хранят и предоставляют информацию о сертификатах и списках САС |
Существуют два вида криптографических систем: системы с секретным ключом (симметричные) и системы с открытым ключом (несимметричные). Говоря достаточно грубо, но понятно, симметричные системы используют один и тот же ключ для проведения операций шифрования и расшифровки, а несимметричные системы — разные.
В симметричных системах существует проблема распределения секретного ключа защищенным способом: обе стороны, обменивающиеся информацией, должны знать этот ключ, но никто другой этим ключом обладать не должен.
Несимметричные системы устроены так, что в них существует два числа:
Последнее обстоятельство очень важно: пользователь может публиковать свой открытый ключ в общедоступных местах, чтобы любой мог им воспользоваться и зашифровать сообщение для A. Поэтому проблема распределения секретного ключа исчезает.
Пользователь должен держать свой закрытый ключ в секрете от посторонних: хочется, чтобы только пользователь мог расшифровывать сообщения, которые ему были направлены. Более того, требование секретности закрытого ключа очень важно в связи с понятием цифровой подписи, которая обсуждается немного ниже. Забегая вперед, скажем, что секретность закрытого ключа важна и потому что только пользователь должен иметь возможность создавать свою цифровую подпись, которая зависит от значения закрытого ключа.
Достаточно часто закрытый ключ хранится на носителе в зашифрованном виде и расшифровывается только на время произведения каких-то действий, требующих знания закрытого ключа. Это несколько повышает надежность хранения закрытого ключа, но создает неудобство, если закрытый ключ нужен какому-то автоматическому сервису: (как минимум) при каждом запуске этого сервиса нужно вводить пароль для расшифровки ключа.
Еще существуют смарт-карты, которые умеют производить криптографические операции внутри себя, отдавая на выход только результат, но не раскрывая содержимого закрытого ключа. Выкрасть закрытый ключ с правильно реализованной смарт-карты должно быть очень сложно. Закрытый ключ, даже хранящийся на смарт-карте, может быть защищен паролем. Если пароля нет, то любой, кто имеет смарт-карту у себя в руках, может произвести действия, для которых нужно знание закрытого ключа: значение самого закрытого ключа останется секретом, но будет возможнось производить с ним любые предусмотренные действия.
У систем с открытым ключом есть еще одна приятная возможность: пользователь может создавать цифровую подпись, которая будучи поставлена на цифровом документе, может служить гарантией того, что пользователь, а не кто-то другой действительно подписал этот документ.
Схема концептуально проста: пользователь A, используя свой закрытый ключ, производит некоторую операцию над данными, которые он хочет подписать и передает результат вместе с исходными данными любому другому объекту. И этот самый объект, используя только открытый ключ пользователя A, может легко убедиться, что цифровая подпись верна.
Еще раз подчеркнем, что условие доступности данного закрытого ключа только его владельцу, играет очень важную роль: если оно выполняется, то пользователь не может отказаться от своей цифровой подписи. Это называется non-repudiation.
Одно из применений цифровой подписи — аутентификация объекта. Аутентификация — это процесс установления «личности» объекта. Понятно, что если объект может поставить цифровую подпись, то эта подпись может быть проверена, а объект связан со своим открытым ключом. Последний ингридиент, которого не хватает в этой схеме для аутентификации — это момент связывания открытого ключа и самого объекта: мы должны точно знать, кто именно владеет этим открытым ключом.
Проблема связывания открытого ключа и некоего объекта может решаться разными способами. Один из самых простых подходов — это составить список соответствия открытых ключей и »имен« объектов. В качестве имени может выступать любой идентификатор, например доменное имя машины, полные имя, фамилия и отчество человека и т.д.; проблема уникальности имен, которая обязательно должна появляется — это отдельная трудность, которая обычно решается административными способами типа иерархической системы пространства имен и некоторой системы разрешения конфликтов имен внутри одного подпространства имен. Здесь эта проблема более освещаться не будет.
Но подход, основанный на списке соответствий, имеет очень слабое масштабирование, поскольку эти самые списки должны быть синхронизированы повсюду в мире (вернее, в той части мира, где эти списки используются).
Поэтому были введены понятия X.509-сертификата и удостоверяющего центра. X.509-сертификат (далее, просто сертификат) — это конгломерат из открытого ключа пользователя, пользовательской информации, имени сертификата, называемого Distungiushed Name (DN) и цифровой подписи удостоверяющего центра, которая скрепляет все эти данные друг с другом. То есть появляется возможность связать открытый ключ и DN пользователя, что может служить искомым ингридиентом процесса аутентификации, если в качестве идентификатора пользователя используется Distinguished Name его сертификата. Кстати говоря, у сертификата есть срок действия, который ограничивает срок соответствия, создаваемого удостоверяющим центром.
Естественно, проблема просто переносится в другое место — вместо поддержания большого списка соответствия мы теперь должны держать существенно меньший список открытых ключей удостоверяющих центров. При этом ключу удостоверяющего центра оказывается достаточно большое доверие: удостоверяющий центр подтверждает связь тысяч пользовательких имен с соответствующими открытыми ключами.
Ну, во-первых, аутентификация ценна сама по себе: компьютерным системам нужно аутентифицировать своих пользователей, чтобы потом решать вопрос об авторизации их доступа к различным ресурсам.
Но если вы берете открытый ключ какого-то пользователя и хотите отправить ему зашифрованное сообщение, то вам скорее всего захочется удостовериться, что вы шифруете сообщение правильным открытым ключом, особенно если вы берете этот ключ из общедоступных источников. Ведь атакующий может поместить свой открытый ключ, но при этом указать, что ключ принадлежит вашему адресату. И если вы не аутентифицируете открытый ключ, то атакующий, перехватив ваше зашифрованное сообщение, сможет его без проблем расшифровать.
То есть введение удостоверяющего центра позволяет нам аутентфифцировать обеъкт, который владеет данным сертификатом. Естественно, перед этим мы должны довериться открытому ключу удостоверяющего центра. Это подразумевает две вещи:
Отлично: теперь у нас есть доверенные удостоверяющие центры, их открытые ключи, сертификаты пользователей и их закрытые ключи. Мы можем шифровать сообщения и может создавать цифровые подписи, отказаться от факта производства которых достаточно сложно.
Что же еще? В многокомпонентных системах очень удобно то, что называется Single Sign-On — возможность аутентифицироваться вручную только один раз, а все остальные операции аутентификации будут проводиться автоматически. Обычно это актуально в системах, которые первоначально вас аутентифицируют, а потом система начинает выполнять действия от вашего лица, например, получать данные, запускать задачи, публиковать их результаты и т.д. Это называется делегированием.
Делегирование, основанное на proxy-сертификатах, функционирует следующим образом: после взаимной аутентификации пользователя и сервиса, который в дальнейшем будет работать от имени пользователя, сервис создает новую ключевую пару и отправляет открытый ключ на подпись пользователю. Пользователь подписывает этот открытый ключ так же, как это делает удостоверяющий центр, но при это используется закрытый ключ пользователя. Появившийся в результате сертификат и называется proxy-сертификатом.
После этого сервис, который выступает от имени пользователя, может аутентифицироваться, используя свой (только что созданный) закрытый ключ и сертификат, подписанный пользователем. Процесс аутентификации проходит примерно так.
С помощью такого же механизма, сервис, которому первоначально был выдан proxy-сертификат, может подписать еще один proxy-сертификат, делегировав полномочия пользователя пользователя по цепочке другому сервису. Именно так и реализуется Single Sign-On.
