Инфраструктура открытых ключей

редактировать

Схема инфраструктуры открытых ключей

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

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

Роль PKI, которая может быть делегирована CA для обеспечения действительной и правильной регистрации, называется центром регистрации (RA). По сути, RA отвечает за прием запросов на цифровые сертификаты и аутентификацию объекта, отправляющего запрос. RFC 3647 Инженерной группы Интернета определяет RA как «объект, который отвечает за одну или несколько из следующих функций: идентификация и аутентификация заявителей на сертификат, утверждение или отклонение заявок на сертификат, инициирование сертификата. аннулирование или приостановка действия при определенных обстоятельствах, обработка запросов подписчиков об отзыве или приостановке их сертификатов, а также утверждение или отклонение запросов подписчиков на обновление или смену ключей для своих сертификатов. Однако RA не подписывают и не выдают сертификаты (т. е. RA делегируется определенные задачи от имени CA) ". Хотя Microsoft могла называть подчиненный ЦС RA, это неверно в соответствии со стандартами PKI X.509. RA не имеют полномочий подписи CA и управляют только проверкой и предоставлением сертификатов. Таким образом, в случае Microsoft PKI функциональность RA предоставляется либо веб-сайтом служб сертификации Microsoft, либо через службы сертификации Active Directory, которые обеспечивают соблюдение Microsoft Enterprise CA и политики сертификатов с помощью шаблонов сертификатов и управляют регистрацией сертификатов (ручная или автоматическая регистрация). В случае автономных центров сертификации Microsoft функция RA не существует, поскольку все процедуры, управляющие этим центром сертификации, основаны на процедурах администрирования и доступа, связанных с системой, в которой размещен этот центр сертификации, и самим центром сертификации, а не с Active Directory. Большинство коммерческих решений PKI сторонних разработчиков предлагают автономный компонент RA.

Объект должен быть однозначно идентифицируемым в каждом домене CA на основе информации об этом объекте. Сторонний центр проверки (VA) может предоставить информацию об этом объекте от имени CA.

Стандарт X.509 определяет наиболее часто используемый формат для сертификатов открытых ключей.

Содержание

  • 1 Дизайн
  • 2 Методы сертификации
    • 2.1 Центры сертификации
      • 2.1.1 Доля эмитента на рынке
      • 2.1.2 Временные сертификаты и единый вход
    • 2.2 Сеть доверия
    • 2.3 Простая инфраструктура открытых ключей
    • 2.4 Децентрализованная PKI
    • 2.5 Блокчейн на основе PKI
  • 3 История
  • 4 Использование
  • 5 Реализации с открытым исходным кодом
  • 6 Критика
  • 7 См. также
  • 8 Ссылки
  • 9 Внешние ссылки

Дизайн

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

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

PKI состоит из:

  • A центра сертификации (CA), который хранит, выдает и подписывает цифровые сертификаты;
  • Орган регистрации (RA), который проверяет идентичность объектов, запрашивающих их цифровые сертификаты для хранения в ЦС;
  • Центральный каталог, т. е. безопасное место, в котором ключи хранятся и индексируются;
  • Система управления сертификатами, управляющая такими вещами, как доступ к сохраненным сертификатам или доставка сертификатов, которые будут выпущены;
  • Политика сертификатов, устанавливающая PKI требования, касающиеся его процедур. Его цель - позволить посторонним проанализировать надежность PKI.

Методы сертификации

В общем, традиционно существует три подхода к получению такого доверия: центры сертификации (CA), сеть доверия (WoT) и инфраструктура простых открытых ключей (SPKI).

Центры сертификации

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

Термин доверенная третья сторона (TTP) также может использоваться для центра сертификации (CA). Более того, PKI сам по себе часто используется как синоним реализации CA.

Доля рынка эмитента

В этой модели доверительных отношений CA является доверенной третьей стороной, которой доверяют оба субъекта. (владелец) сертификата и стороной, полагающейся на сертификат.

Согласно отчету NetCraft от 2015 года, отраслевой стандарт для мониторинга активных сертификатов Transport Layer Security (TLS) гласит: «Хотя глобальная экосистема [TLS] конкурентоспособна, в ней доминируют на горстку основных центров сертификации - три центра сертификации (Symantec, Sectigo, GoDaddy ) приходится три четверти всех выпущенных сертификатов [TLS] в открытых Веб-серверы. Первое место занимает Symantec (или VeriSign до того, как он был приобретен Symantec) с момента начала [нашего] исследования, и в настоящее время на него приходится чуть менее трети всех сертификатов. Для иллюстрации В результате применения различных методологий Symantec выпустила 44% действующих и надежных сертификатов среди миллиона наиболее загруженных сайтов, что значительно превышает ее общую долю на рынке ».

Вслед за серьезными проблемами, связанными с управлением выпуском сертификатов, все основные игроки постепенно перестали доверять сертификатам, выпущенным Symantec, начиная с 2017 года.

Временные сертификаты и единый вход

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

Начиная с сентября 2020 года, срок действия сертификата TLS снижен до 13 месяцев.

Сеть доверия

Альтернативным подходом к проблеме публичной аутентификации информации с открытым ключом является схема сети доверия, в которой используются самозаверяющие сертификаты и сторонние подтверждения этих сертификатов. Единичный термин «сеть доверия» не подразумевает существование единой сети доверия или общей точки доверия, а, скорее, одной из любого числа потенциально непересекающихся «сетей доверия». Примеры реализаций этого подхода: PGP (Pretty Good Privacy) и GnuPG (реализация OpenPGP, стандартизованная спецификация PGP). Поскольку PGP и его реализации позволяют использовать цифровые подписи электронной почты для самостоятельной публикации информации открытого ключа, относительно легко реализовать собственную сеть доверия.

Одно из преимуществ сети доверия, например, в PGP, заключается в том, что она может взаимодействовать с PKI CA, полностью доверенной всеми сторонами в домене (например, внутренним CA в компании), которая готова предоставить сертификаты, как надежный посредник. Если «сеть доверия» является полностью доверенной, то из-за природы сети доверия доверие к одному сертификату дает доверие всем сертификатам в этой сети. PKI настолько ценна, насколько стандарты и методы, которые контролируют выдачу сертификатов, и включение PGP или лично созданной сети доверия может значительно снизить надежность реализации PKI на этом предприятии или в домене.

Концепция доверия была впервые предложена создателем PGP Филом Циммерманном в 1992 году в руководстве по PGP версии 2.0:

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

Простая инфраструктура открытого ключа

Другой альтернативой, не имеющей отношения к открытой аутентификации информации открытого ключа, является простая инфраструктура открытого ключа (SPKI), которая выросла из трех независимых усилий. преодолеть сложности сети доверия X.509 и PGP. SPKI не связывает пользователей с людьми, поскольку ключ - это то, чему доверяют, а не человек. SPKI не использует никакого понятия доверия, поскольку проверяющий также является эмитентом. В терминологии SPKI это называется «циклом авторизации», где авторизация является неотъемлемой частью его конструкции. Этот тип PKI особенно полезен для интеграции PKI, которая не полагается на третьи стороны для авторизации сертификатов, информации о сертификатах и ​​т. Д.; Хорошим примером этого является сеть с воздушным зазором в офисе.

Децентрализованная PKI

Децентрализованные идентификаторы (DID) устраняют зависимость от централизованных реестров для идентификаторов, а также централизованных центров сертификации для управления ключами, что является стандартом в иерархической PKI. В случаях, когда реестр DID является распределенным реестром, каждый объект может служить своим собственным корневым органом. Эта архитектура называется децентрализованной PKI (DPKI).

PKI на основе блокчейна

Новый подход к PKI заключается в использовании технологии блокчейн, обычно связанной с современными криптовалюта. Поскольку технология блокчейн направлена ​​на обеспечение распределенного и неизменяемого реестра информации, она обладает качествами, которые считаются очень подходящими для хранения открытых ключей и управления ими. Некоторые криптовалюты поддерживают хранение различных типов открытых ключей (SSH, GPG, RFC 2230 и т. Д.) И предоставляют программное обеспечение с открытым исходным кодом, которое напрямую поддерживает PKI для OpenSSH серверы. Хотя технология блокчейн может приблизиться к доказательству работы, часто подкрепляя доверие доверенных сторон к PKI, остаются такие проблемы, как административное соответствие политике, операционная безопасность и качество реализации программного обеспечения. Парадигма центра сертификации имеет эти проблемы независимо от используемых криптографических методов и алгоритмов, и PKI, которая стремится наделить сертификаты надежными свойствами, также должна решать эти проблемы.

Вот список известных PKI на основе блокчейна:

  • CertCoin
  • FlyClient
  • BlockQuick

История

Развитие PKI произошло в начале 1970-х годов в британском разведывательном агентстве GCHQ, где Джеймс Эллис, Клиффорд Кокс и другие сделали важные открытия, связанные с алгоритмами шифрования и распределением ключей. Поскольку разработки в GCHQ строго засекречены, результаты этой работы держались в секрете и не признавались публично до середины 1990-х годов.

Публичное раскрытие как безопасного обмена ключами, так и алгоритмов асимметричного ключа в 1976 году Диффи, Хеллман, Ривест, Шамир и Адлеман полностью изменили безопасную связь. С дальнейшим развитием высокоскоростной цифровой электронной связи (Интернет и его предшественники) стала очевидной необходимость в способах, с помощью которых пользователи могли бы безопасно общаться друг с другом, и, как дальнейшее следствие этого, в способы, которыми пользователи могли быть уверены, с кем они на самом деле взаимодействуют.

Были изобретены и проанализированы различные криптографические протоколы, в которых можно было эффективно использовать новые криптографические примитивы. С изобретением Всемирной паутины и ее быстрым распространением потребность в аутентификации и безопасной связи стала еще более острой. Одних коммерческих причин (например, электронная коммерция, онлайн-доступ к частным базам данных из веб-браузеров ) было достаточно. Тахер Эльгамал и другие сотрудники Netscape разработали протокол SSLhttps » в веб-адресах URL ); он включал установление ключа, аутентификацию сервера (до v3, только одностороннюю) и так далее. Таким образом, была создана структура PKI для веб-пользователей / сайтов, желающих безопасного взаимодействия.

Продавцы и предприниматели увидели возможность большого рынка, открыли компании (или новые проекты в существующих компаниях) и начали агитировать за юридическое признание и защиту от ответственности. В технологическом проекте Американской ассоциации юристов был опубликован обширный анализ некоторых предполагаемых юридических аспектов операций PKI (см. Руководство по цифровой подписи ABA ), а вскоре после этого несколько штатов США (Юта первой в 1995 г.) и другие юрисдикции по всему миру начали принимать законы и постановления. Группы потребителей подняли вопросы о конфиденциальности, доступе и ответственности, которые в одних юрисдикциях учитывались больше, чем в других.

Принятые законы и постановления различались, возникали технические и операционные проблемы при преобразовании схем PKI в успешную коммерческую эксплуатацию, и прогресс шел намного медленнее, чем предполагали пионеры.

К первым нескольким годам 21 века базовую криптографическую инженерию было явно нелегко правильно развернуть. Рабочие процедуры (ручные или автоматические) было нелегко правильно спроектировать (или даже если они так спроектированы, чтобы выполнить безупречно, как того требовала инженерия). Существовавших стандартов было недостаточно.

Поставщики PKI нашли рынок, но это не совсем тот рынок, который предполагалось в середине 1990-х годов, и он рос как медленнее, так и несколько иначе, чем ожидалось. PKI не решили некоторые проблемы, которые от них ожидали, и несколько крупных поставщиков прекратили свою деятельность или были приобретены другими. PKI добилась наибольшего успеха при внедрении в государственных учреждениях; Самая крупная реализация PKI на сегодняшний день - это инфраструктура PKI Defense Information Systems Agency (DISA) для программы Common Access Cards.

Использует

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

  • Шифрование и / или отправителя аутентификация сообщений электронной почты (например, с использованием OpenPGP или S / MIME );
  • Шифрование и / или аутентификация документов (например, стандарты XML Signature или XML Encryption, если документы закодированы как XML );
  • Authentication пользователей в приложениях (например, смарт-карта вход в систему, аутентификация клиента с SSL ). В Enigform и mod_openpgp есть экспериментальное использование для аутентификации с цифровой подписью HTTP. проекты;
  • Начальная загрузка безопасных протоколов связи, таких как Интернет-обмен ключами (IKE) и SSL. В обоих случаях начальная настройка безопасного канала ( a «ассоциация безопасности ») использует асимметричный ключ - т.е. открытый ключ - методы, тогда как фактическая связь использует более быстрый симметричный ключ - т.е. секретный ключ - методы;
  • мобильные подписи - это электронные подписи, которые создаются с помощью мобильного устройства и основываются на подписи или сертификации услуги в телекоммуникационной среде, не зависящей от местоположения;
  • Интернет вещей требует безопасного обмена данными между взаимно доверенными устройствами. Инфраструктура открытых ключей позволяет устройствам получать и обновлять сертификаты X509, которые используются для установления доверия между устройствами и шифрования связи с использованием TLS.

реализации с открытым исходным кодом

  • OpenSSL - простейшая форма CA и инструмент для PKI. Это набор инструментов, разработанный на языке C, который включен во все основные дистрибутивы Linux и может использоваться как для создания собственного (простого) CA, так и для приложений с поддержкой PKI. (Apache с лицензией )
  • EJBCA - это полнофункциональная реализация CA корпоративного уровня, разработанная на Java. Ее можно использовать для настройки CA как для внутреннего использования, так и в качестве сервис. (с лицензией LGPL )
  • ответчик XiPKI, CA и OCSP. С поддержкой SHA3, реализованной на Java. (Apache с лицензией )
  • OpenCA - это полнофункциональная реализация CA с использованием номера различных инструментов. OpenCA использует OpenSSL для основных операций PKI.
  • XCA - графический интерфейс и база данных. XCA использует OpenSSL для основных операций PKI.
  • (Снято с производства) TinyCA был графическим интерфейсом для OpenSSL.
  • IoT_pki - это простая PKI, созданная с использованием криптографической библиотеки python
  • DogTag - полнофункциональный CA, разработанный и поддерживаемый как часть Проект Fedora.
  • CFSSL набор инструментов с открытым исходным кодом, разработанный CloudFlare для подписания, проверки и объединения сертификатов TLS. (инструмент )
  • Vault с лицензией на 2 пункта BSD для безопасного управления секретами (Включая сертификаты TLS), разработанные HashiCorp. (Mozilla Public License 2.0 с лицензией )
  • Libhermetik - это автономная система инфраструктуры с открытым ключом, встроенная в библиотеку языка C. Hermetik использует LibSodium для все криптографические операции и SQLite для всех операций сохранения данных. Программное обеспечение с открытым исходным кодом и выпущено по лицензии ISC.

Критика

Некоторые утверждают, что покупка сертификатов для защиты веб-сайтов с помощью SSL и защиты программного обеспечения с помощью подписи кода является дорогостоящим предприятием для малого бизнеса. Однако появление бесплатных альтернатив, таких как Let's Encrypt, это изменило. HTTP / 2, последняя версия протокола HTTP теоретически допускает незащищенные соединения, на практике крупные браузерные компании ясно дали понять, что они будут поддерживать этот протокол только через защищенный PKI TLS соединение. Реализация HTTP / 2 в веб-браузере, включая Chrome, Firefox, Opera и Edge suppo rts HTTP / 2 только через TLS с использованием ALPN расширения протокола TLS. Это будет означать, что для получения преимущества скорости HTTP / 2 владельцы веб-сайтов будут вынуждены покупать SSL-сертификаты, контролируемые корпорациями.

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

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

См. Также

Ссылки

Внешние ссылки

Последняя правка сделана 2021-06-02 10:10:15
Содержание доступно по лицензии CC BY-SA 3.0 (если не указано иное).
Обратная связь: support@alphapedia.ru
Соглашение
О проекте