Без какого элемента не будет работать pki

Журнал ВРМ World

PKI: Как это работает

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

Используя комбинацию туннелирования, шифрования, аутентификации и контроля доступа, VPN предоставляет пользователям защищенный способ доступа через Интернет или другие общие или частные IP-сети. Реализация VPN включает в себя два основных технологических решения: протокол туннелирования и метод аутентификации пользователей туннеля.

IPSec, протокол туннелирования Уровня 3 (сетевого уровня), сегодня обычно используется для шифрования и выделения данных для защищенной передачи по VPN корпоративных сетей. Ряд методов аутентификации, служащих для проверки идентичности допущенных пользователей, может реализовываться через IPSec, включая пароли, известные серверу и клиенту, доступ с передачей маркера и цифровые сертификаты. Для широкой реализации в экстранет самым простым методом является Инфраструктура Открытых Ключей (Public Key Infrastructure, PKI), использующая технологию цифровых сертификатов. Эта статья расскажет о том, как PKI работает в среде VPN.

Определение PKI

Технология PKI заключается в использовании двух математически-связанных цифровых ключей, имеющих следующие свойства:

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

Простая PKI начинается с Certificate Authority (CA), программного пакета, используемого в защищенном режиме доверенной третьей стороной для выпуска цифровых сертификатов X.509v3. Цифровой сертификат представляет собой структуру электронных данных, связывающую значения открытого ключа с идентифицирующей информацией о конкретном предмете. Цифровой сертификат подписывается цифровым методом (авторизуется) с помощью выпуска Certificate Authority. Цифровой сертификат гарантирует любой сертифицированной организации, использующей открытый ключ, что соответствующий закрытый ключ хранится соответствующим удаленным предметом. Разъяснение полей информации в сертификате можно найти в RFC 2459 (Internet X.509 Public Key Infrastructure Certificate and CRL profile), опубликованном в Январе 1999 года. В сильнозащищенной области Certificate Authority также имеется как минимум X.509v3-совместимая база данных. CA-оператор выпускает цифровой сертификат к End Entity (конечной сущности; в данном случае — конечным точкам EE-IPSec) и сохраняет копию сертификата в базе данных для последующего обращения. Языком, используемым для любых запросов к базе данных X.509v3, является Lightweight Data Access Protocol v3 (LDAP v3).

Обслуживание недействительных сертификатов

Даже если срок действия сертификата еще не истек, он может рассматриваться как недействительный или непригодным по ряду причин: владелец может больше в нем не нуждаться, сертификат может быть дискредитирован или украден, владелец мог уже выпустить новый сертификат, имеющий преимущество относительно существующего.

В этом случае CA-оператор может пойти двумя путями. Сертификат может быть внесен в Certificate Revocation List (CRL-X.509v2) и выпущен на определенный срок. CRL остается в v2, так как было оговорено, что при переходе других компонентов на v3 в него не было внесено никаких изменений. Либо аннулирование сертификата осуществляется с помощью Online Certificate Status Protocol (OCSP) на онлайновом сервере, представляющим собой, например, сервер базы данных X.509 v3, обеспечивающий сервис такого рода.

Каждый раз, как конечная точка IPSec проверяет допустимость сертификата, предоставленного для аутентификации, она проверяет последний кэшированный CRL или использует OCSP для определения, включен ли данный сертификат в соответствующий список. Если он в списке, это означает, что сертификат больше не действителен и конечная точка IPSec его отклонит.

Как работает сложная PKI

Сложная PKI может использовать множество различных CA с Root CA (корневыми CA). Root CA хранит «собственноручно» подписанный сертификат и выпускает сертификаты для подчиненных CA (т.е. относящихся к более низкому уровню), которые, в свою очередь, могут выпускать сертификаты для различных RA (Registration Authorities) или LRA (Local Registry Authorities). В процессе работы RA или LRA получает исходный запрос на сертификат от запрашивающей стороны и передает аутентифицированный запрос своему CA, выпускающему этот сертификат. Иерархия различных CA напоминает дерево, именно поэтому исходный CA назван Root CA (см. Рис. 1).

К этому моменту между всеми EE (в данном случае — конечными точками IPSec) всех подчиненных СА устанавливается «цепь взаимного доверия» (chain of trust). Однако как EE-1, Relying Party (полагающаяся на сертификат сторона, RP), чей сертификат выпущен CA-1, узнает, что сертификат EE-5, выпущенный CA-2, заслуживает доверия? Это происходит следующим образом:

1. Сначала EE-1 проверяет либо все CRL либо использует OCSP, чтобы определить допустимость сертификата EE-5.
2. Затем EE-1 проверяет, кто подписал сертификат EE-5, и обнаруживает, что авторизующей стороной является CA-2.
3. Теперь EE-1 необходимо узнать, кто такой CA-2, поэтому она проверяет, кто подписал сертификат CA-2.
4. EE-1 обнаруживает, что это был CA-0, корневой сертификат, подписавший и сертификат CA-1.
5. CA-1 выпускает и подписывает сертификат EE-1.

Эта информация обеспечивает проверку допустимости EE — 5, так как они находятся в рамках одной PKI. Такая процедура называется «проход по цепи доверия» или просто «проход по цепи». Это основные элементы работы отдельной PKI. Далее в этой статье будут рассмотрены множественные реализации PKI. Сертификационная политика (Certificate Policy) устанавливает основные правила. Независимо от того, сама ли компания, реализующая PKI, использует CA, или поручает это делать кому-то еще, она все равно должна определить для себя Сертификационную политику (Certificate Policy, CP). CP очерчивает требования, необходимые в процессе аутентификации для получения сертификата от CA, а также может определять уровень полномочий (например, «этот сертификат имеет право подписи информации по сделкам, не превышающим один миллион долларов «).

В случае конечной точки IPSec CP определяет, какая информация должна быть предъявлена CA для аутентификации до выпуска сертификата для этой конечной точки. Он также определяет, какую информацию будет содержать индивидуальный сертификат и как он будет выглядеть. CP определяет обновление CRL или требования размещения уведомления об аннулированном сертификате на сервере OCSP. Кроме того, CP может также определять требования физической безопасности, которым должен соответствовать CA.

Присвоение и регистрация Объектного Идентификатора (Object Identifier)

Когда CP уже сформулирована, ее следует разместить на сайте компании. Компания, составляющая CP, должна быть зарегистрирована через IANA (Internet Assigned Numbers Association), чтобы ее CP был присвоен Объектный идентификатор (Object Identifier, OID). OID представляет собой представление компании в численной форме. Этот OID следует поместить в сертификат, чтобы RP (лицо, получающее данный сертификат) могло найти и ознакомиться с CP сертификата на сайте идентифицируемой компании. Прочитав CP, RP самостоятельно решает, заслуживает ли данный сертификат доверия.

Написание Положения об использовании сертификата (Certificate Practice Statement)

Для успешной реализации CA, в зависимости от уровня необходимой авторизации, оператор CA должен либо написать специальное Положение об использовании сертификата (Certificate Practice Statement, CPS) либо составить общее CPS. CPS представляет собой документ, описывающий подробности реализации CP и объясняющий порядок соотнесения CA с требованиями CP. По правилам American Bar Association, идентификатор CPS (OID) также должен включаться в сертификат. Эта информация в дальнейшем позволит RP проверять квалификацию Certificate Authority.

Создание собственного CA

Если компания реализует собственный CA, она должна создать также и CP и CPS. Лучшим справочным материалом при написании CP и CPS является RFC 2527 (Internet X.509 Public Key Infrastructure Certificate Policy and Certification Practices Framework), увидевшая свет в марте 1999 года. Прежде, чем публиковать CP и CPS, необходимо также проконсультироваться с юристами компании. Тем не менее, не следует ждать от них особой помощи ни в вопросе создания CP, ни CPS — к сожалению, очень немногие корпоративные юристы способны разбираться в таких вещах.

Хотя разработка CP и CPS может показаться ненужной, так как компания, использующая CA, полностью контролирует их реализацию, тем не менее, это необходимо по двум причинам. Во-первых, это гарантирует оптимальный уровень безопасности, поскольку компания создает документы и по эксплуатационным вопросам, и по проверке безопасности. Во-вторых, это необходимо в случае, когда компания планирует провести взаимную сертификацию с другой PKI.

Взаимная сертификация означает, что сертификат, выпущенный одной PKI, становится применим в другой PKI. И CP и CPS каждой из PKI будет проверен другой PKI с целью убедиться, что их сертификаты можно рассматривать как равнозначные относительно важных для них аспектов (не совсем верно было бы называть их полностью «равнозначными», так как юридически это означало бы и словесное совпадение). Взаимная сертификация представляет собой простое физическое действие: каждый CA выпускает для другого сертификат, содержащий Policy Mappings Extension (Расширенное отображение политики), закрепляющий вышеуказанное соглашение. Сложность состоит в согласовании соглашений CP и CPS между двумя PKI.

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

Отдельный Bridge CA обменивается взаимными сертификатами со всеми Root CA имеющихся PKI. Это уменьшает длину цепочки, которую необходимо пройти EE, чтобы провести аутентификацию сертификата, предъявленного ей извне ее PKI. Это основная причина реализации Bridged PKI, однако такая технология выгодна потому, что она упрощает аннулирование взаимной сертификации. Вместо размещения 12 сертификатов необходимо будет разместить только один — тот, что выпущен Bridge CA для взаимной сертификации. Итак, мы разобрались с основными понятиями технологии PKI. А теперь самое сложное… Реализация PKI: заказывать или делать самим?

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

Источник

Национальная библиотека им. Н. Э. Баумана
Bauman National Library

Персональные инструменты

PKI (Public Key Infrastructure)

Разработчики: British intelligence agency GCHQ Написана на: C++ Операционная система: Windows Тип ПО: Служба каталогов Веб-сайт Официальный сайт

PKI (англ. Public Key Infrastructure – инфраструктура открытых ключей) — совокупность сервисов для управления ключами и цифровыми сертификатами пользователей, программ и систем.

Содержание

Описание

Инфраструктура открытых ключей – это система цифровых сертификатов, центров сертификации и центров регистрации, которые проверяют и подтверждают подлинность каждого объекта, участвующего в электронной транзакции с использованием криптографии с открытыми ключами. Инфраструктура открытых ключей использует технологию открытых ключей для:

1. идентификации участников электронного обмена (пользователей, программ, систем),
2. обеспечения конфиденциальности информации,
3. контроля за целостностью информации,
4. установления происхождения информации.

Основные определения

Цифровой сертификат — cтруктура данных, применяющаяся для связывания определенного модуля с определенным открытым ключом. Цифровые сертификаты используются для подтверждения подлинности пользователей, приложений и сервисов, и для контроля доступа (авторизации).

Цифровой конверт — метод использования шифрования с открытым ключом для безопасного распространения секретных ключей использующихся при симметричном шифровании и для посылки зашифрованных сообщений. Значительно сокращается проблема распространения ключей связанная с симметричным шифрованием.

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

Шифрование с открытым ключом — тип шифрования, при котором используется пара ключей: открытый, т.е. свободно доступный, и соответствующий ему частный ключ, известный только конкретному пользователю, приложению или сервису, которые владеют этим ключом. Эта пара ключей связана таким образом, что зашифрованное частным ключом, может быть расшифровано только открытым ключом и наоборот.

Симметричное шифрование — тип шифрования, при котором получатель и отправитель используют один и тот же ключ для шифрования и расшифровки. Это означает, что множество пользователей должны иметь одинаковые ключи. Очевидно, что до получения ключа пользователем шифрование невозможно, при этом распространение ключа по сети не является безопасным. Другие же способы распространения, такие как специальный курьер, дорогие и медленные.

Алгоритм RSA — первая шифровальная система с открытым ключом, названная в честь ее изобретателей: Ronald Rivest, Adi Shamir и Leonard Adleman. [1]

Компоненты PKI

Основная идея

Задачей PKI является определение политики выпуска цифровых сертификатов, выдача их и аннулирование, хранение информации, необходимой для последующей проверки правильности сертификатов. В число приложений, поддерживающих PKI, входят: защищенная электронная почта, протоколы платежей, электронные чеки, электронный обмен информацией, защита данных в сетях с протоколом IP, электронные формы и документы с электронной цифровой подписью (ЭЦП).

Деятельность инфраструктуры управления открытыми ключами осуществляется на основе регламента системы. Инфраструктура открытых ключей основывается на использовании принципов криптографической системы с открытым ключом. Инфраструктура управления открытыми ключами состоит из центра сертификации УЦ [2] , конечных пользователей, и опциональных компонентов: центра регистрации и сетевого справочника.

PKI оперирует в работе сертификатами. Сертификат — это электронный документ, который содержит электронный ключ пользователя, — открытый или же ключевую пару (keypair), — информацию о пользователе, которому принадлежит сертификат, удостоверяющую подпись центра выдачи сертификатов (УЦ) и информацию о сроке действия сертификата.

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

Удостоверяющий центр также публикует и списки отозванных сертификатов (Certificate Revocation List/CRL), которые могут использовать клиенты инфраструктуры открытого ключа, когда решают вопрос о доверии сертификату пользователя и/или компьютера.

Создаётся пара ключей либо центром выдачи сертификатов (удостоверяющим центром), по запросу пользователя, или же самим пользователем с помощью специального программного обеспечения. Пользователь делает запрос на сертификат, после чего, после процедуры идентификации пользователя, центр выдаёт ему сертификат со своей подписью. Эта подпись свидетельствует о том, что данный сертификат выдан именно этим центром выдачи сертификатов и никем другим.

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

Архитектуры PKI В основном выделяют 5 видов архитектур PKI:

1. Простая PKI (одиночный удостоверяющий центр).
2. Иерархическая PKI.
3. Сетевая PKI.
4. Кросс-сертифицированные корпоративные PKI.
5. Архитектура мостового УЦ.

В основном PKI делятся на разные архитектуры по следующим признакам:

1. Количество УЦ (а также количество УЦ, которые доверяют друг-другу).
2. Сложность проверки пути сертификации.
3. Последствия выдачи злоумышленника себя за УЦ.

Примеры использования PKI

Шифрование сообщений

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

Электронный отпечаток

Электронный отпечаток — это информация при помощи которой можно проверить, является ли полученный открытый ключ именно тем, который был отослан отправителем. Электронные отпечатки открытого и закрытого ключа одной пары идентичны, поэтому сверив отпечаток полученного ключа (например, по телефону) с отпечатком закрытого ключа отправителя, можно установить соответствие открытого ключа закрытому.

Электронно-цифровая подпись (ЭЦП)

Сторона А формирует ЭЦП документа и отправляет документ стороне Б. Сторона Б запрашивает сертификат открытого ключа стороны А у удостоверяющего центра, а также информацию о действительности сертификата. Если сертификат стороны А действителен и проверка ЭЦП прошла успешно, значит документ был подписан стороной А, а не кем-то другим.

Источник