1. Простая pki
Как уже говорилось выше, самая простая из архитектур, это архитектура одиночного УЦ. В данном случае все пользователи доверяют одному УЦ и переписываются между собой. В данной архитектуре, если злоумышленник выдаст себя за УЦ, необходимо просто перевыпустить все выписанные сертификаты и продолжить нормальную работу.
2. Иерархическая pki
Иерархическая структура – это наиболее часто встречающаяся архитектура PKI. В данном случае во главе всей структуры стоит один Головной УЦ, которому все доверяют и ему подчиняются нижестоящие УЦ. Кроме этого головного УЦ в структуре присутствуют ещё не один УЦ, который подчиняется вышестоящему, которому в свою очередь приписаны какие-либо пользователи или нижестоящие УЦ. Частный пример иерархической PKI – корпоративная PKI. Например если у нас есть одна большая фирма, у которой в подчинении множество филиалов по всей стране. В главном здании фирмы есть головной УЦ и в каждом филиале есть УЦ, который подчиняется головному. В иерархической PKI, даже если злоумышленник выдал себя за какой – либо УЦ, сеть продолжает работать без него, а когда он восстанавливает нормальную работоспособность – он просто снова включается в структуру.
3. Сетевая pki
Сетевая архитектура PKI это также частный случай иерархической архитектуры. Но в данном случае нет одного головного УЦ, которому все доверяют. В этой архитектуре все УЦ доверяют рядом стоящим УЦ, а каждый пользователь доверяет только тому УЦ, у которого выписал сертификат. В данную архитектуру PKI легко добавляется новый УЦ. В данной архитектуре наиболее сложное построение цепочки сертификации.
4. Архитектура кросс-сертифицированной корпоративной pki
Данный вид архитектуры можно рассматривать как смешанный вид иерархической и сетевой архитектур. Есть несколько фирм, у каждой из которых организована какая-то своя PKI, но они хотят общаться между собой, в результате чего возникает их общая межфирменная PKI.В архитектуре кросс-сертифицированной корпоративной PKI самая сложная система цепочки сертификации.
5. Архитектура мостового уц
Архитектура мостового УЦ разрабатывалась для того, чтобы убрать недостатки сложного процесса сертификации в кросс-сертифицированной корпоративной PKI. В данном случае все компании доверяют не какой-то одной или двум фирмам, а одному определённому мостовому УЦ, который является практически их головным УЦ, но он не является основным пунктом доверия, а выступает в роли посредника между другими УЦ.
Примеры использования PKI
Электронно-цифровая подпись (ЭЦП)
Сторона А формирует ЭЦП документа и отправляет документ стороне Б. Сторона Б запрашивает сертификат открытого ключа стороны А у удостоверяющего центра, а также информацию о действительности сертификата. Если сертификат стороны А действителен и проверка ЭЦП прошла успешно, значит документ был подписан стороной А, а не кем-то другим.
Шифрование сообщений
Сторона Б зашифровывает документ открытым ключом стороны А. Чтобы убедиться, что открытый ключ действительно принадлежит стороне А, сторона Б запрашивает сертификат открытого ключа у удостоверяющего центра. Если это так, то только сторона А может расшифровать сообщение, т.к. владеет соответствующим закрытым ключем.
Авторизация
Сертификаты могут использоваться для подтверждения личности пользователя и задания полномочий, которыми он наделен. В числе полномочий субъекта сертификата может быть, например, право просматривать информацию или разрешение вносить изменения в материал, представленный на web-сервере.
PKIX
PKIX – наиболее распространенная форма организации инфраструктуры открытых ключей. Представляет собой комплексную систему, обеспечивающую все необходимые сервисы для использования технологии открытых ключей.
Цель PKIX состоит в управлении ключами и сертификатами, посредством которого поддерживается доверительная среда.
Формат сертификата открытого ключа подписи определен в рекомендациях Международного Союза по телекоммуникациям ITU(Х.509) и документе PKIX - RFC 3280 Certificate&CRLProfile.
В PKIX должны функционировать подсистемы:
выпуска и аннулирования сертификатов;
создания резервных копий и восстановления ключей;
выполнения криптографических операций;
управления жизненным циклом сертификатов и ключей.
В настоящее время основным принятым форматом является формат версии 3, позволяющий задать дополнения, с помощью которых реализуется определенная политика безопасности в системе. Несмотря на то, что документ RFC 3820 адресован сообществу Интернет, формат сертификата открытого ключа предоставляет гибкий и мощный механизм передачи разнообразной информации и может применяться в корпоративной практике. Большая часть информации, указываемой в сертификате, не является обязательной, а содержание обязательных полей сертификата может варьироваться. Для разработчиков PKI и пользователей важно понимать назначение полей сертификата и знать варианты выбора. Сертификат открытого ключа подписи или шифрования представляет собой структурированную двоичную запись в формате ASN.1. Сертификат содержит элементы данных, сопровождаемые цифровой подписью издателя сертификата.
В сертификате имеется десять основных полей: шесть обязательных и четыре опциональных. К обязательным полям относятся:
серийный номер сертификата Certificate Serial Number;
идентификатор алгоритм аподписи Signature Algorithm Identifier;
имя издателя Issuer Name;
период действия Validity (Not Before/After);
открытый ключс убъекта Subject Public Key Information и
имя субъекта сертификата Subject Name.
Под субъектом понимается сторона, контролирующая секретный ключ, соответствующий данному открытому ключу. Наличие необязательных полей характерно для сертификатов версий 2 и 3, к необязательным полям сертификата относятся номер версии, два уникальных идентификатора и дополнения.
Компоненты PKIX:
Удостоверяющий центр (Центр сертификации, Certification Authority - CA).
Регистрационный центр (РЦ, Registration Authority – RA).
Репозиторий сертификатов.
Архив сертификатов.
Конечные субъекты (пользователи).
Удостоверяющие центры (УЦ) Выпускают и аннулируют сертификаты
Регистрационные центры (РЦ) Подтверждают связывание открытых ключей и личностей владельцев сертификатов и других атрибутов
Владельцы сертификатов Подписывают и шифруют электронные документы
Клиенты Проверяют подлинность цифровых подписей и соответствующих цепочек сертификатов при помощи открытого ключа доверенного УЦ
Репозитории Хранят и предоставляют информацию о сертификатах и списках САС
Сервисы PKIX
Криптографические сервисы:
генерация пар ключей;
выработка и верификация ЭЦП;
шифрование данных.
Сервисы управления сертификатами:
выпуск сертификатов;
кросс-сертификация;
аннулирование сертификатов;
приостановление действия сертификатов.
Поддержка репозитория и архива.
Поддержка базы данных пользователей и сертификатов.
Резервное хранение и восстановление ключей.
Автоматическое обновление ключей и сертификатов.
Автоматическое управление историями ключей и сертификатов.
Авторизация на базе сертификатов.
Обеспечение неотказуемости ЭЦП.
Электронный нотариат.
Общая схема функционирования PKI представлена на рис. Конечный субъект отправляет запрос на сертификат в РЦ (транзакция управления). Если запрос фактически одобрен, то направляется непосредственно в УЦ для заверения цифровой подписью. УЦ проверяет запрос на сертификат, и если тот проходит верификацию, то подписывается и выпускается сертификат. Сертификат публикуется в репозитории; в зависимости от конкретной конфигурации PKI, эта функция может быть возложена на регистрационный или удостоверяющий центр.
Напоказаны все возможные коммуникации между конечным субъектом и УЦ. Процесс аннулирования сертификата аналогичен процессу его генерации. Конечный субъект запрашивает УЦ об аннулировании своего сертификата, РЦ принимает решение и направляет запрос об аннулировании в УЦ. УЦ вносит изменения в список аннулированных сертификатов и публикует его в репозитории. Конечные субъекты могут проверить статус конкретного сертификата через операционный протокол.
Определение. Инфраструктура открытых ключей (Public Key Infrastructure - PKI) –это механизм, обеспечивающий сервисы, необходимые для непрерывного управления ключами в распределенной системе, связывает открытые ключи с владельцами соответствующих секретных ключей и позволяет пользователям проверять подлинность этих связей
Аутентификация - это только один из необходимых сервисов безопасности. Приложения также требуют конфиденциальности, целостности и невозможности отказаться от участия в обмене информацией. Технология PKI обеспечивает поддержку всех этих сервисов.
PKI обеспечивает аутентификацию.
Наиболее распространенные способы организации PKI:
простая инфраструктура открытых ключей SPKI/SDSI;
защищенная система доменных имен DNS - DNSSEC;
система защищенной почты PGP;
инфраструктура открытых ключей, основанная на
сертификатах Х.509 – PKIX.
PKI:
По сфере применения:
узкоспециализированные
универсальные
По модели доверия:
определяет механизмы
обеспечивающие достоверность
связи открытого ключа
и его владельца
По поддерживаемым стандартам:
построенные на открытых стандартах
построенные на фирменных стандартах
Защищенная система доменных имен DNS
DNSSEC разработана для обеспечения безопасности клиентов от фальшивых DNS-данных. Все ответы от DNSSEC имеют цифровую подпись. При проверке цифровой подписи DNS проверяется верность и целостность информации. Хотя защита IP адресов является непосредственной проблемой для многих пользователей, DNSSEC может защитить остальную информацию, такую как криптографические сертификаты общего назначения. RFC 4398 описывает, как распределить эти сертификаты, в том числе по электронной почте, что позволяет использовать DNSSEC в качестве глобальной инфраструктуры открытых ключей электронной почты.
DNSSEC не обеспечивает конфиденциальность данных. В частности, все DNSSEC ответы аутентифицированы, но не шифруются.
DNSSEC спецификации подробно описывают текущий протокол DNSSEC RFC 4033, RFC 4034 и RFC 4035.
В основе протокола DNSSEC лежит метод цифровой подписи ответов на запрос DNS lookup, который обеспечивает неприкосновенность данных в системе DNS.
Вся информация о защищенном домене (COM, NET, RU…) в системе DNSSEC зашифрована, поэтому может быть изменена только при помощи закрытого ключа шифрования. В процессе защищенного делегирования домена происходит генерация пары ключей. Информация о ключах хранится на первичном DNS-сервере. Закрытый ключ используется для подписи зоны после каждого изменения. Цифровая подпись закрытого ключа передается администратору родительской зоны и подписывается его закрытым ключом. Таким образом организуется цепочка доверия. Зная открытый ключ администратора родительской зоны можно проверить валидность открытого ключа любой из дочерних зон. Получив доступ к файлам с описанием домена на первичном или вторичном серверах DNS или во время передачи данных между серверами, злоумышленник не сможет внести изменения, так как не является владельцем закрытого ключа — все несанкционированные изменения файлов будут отброшены как недостоверные.
