Инфраструктура открытого ключа - Public key infrastructure

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

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

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

Роль PKI, которая может быть делегирована центром сертификации для обеспечения действительной и правильной регистрации, называется регистрирующий орган (РА). По сути, RA отвечает за прием запросов на цифровые сертификаты и аутентификацию объекта, отправляющего запрос.[1] Инженерная группа Интернета RFC 3647 определяет RA как «объект, который отвечает за одну или несколько из следующих функций: идентификация и аутентификация соискателей сертификатов, утверждение или отклонение заявок на сертификаты, инициирование отзыва или приостановки сертификатов при определенных обстоятельствах, обработка запросов подписчиков на отзыв или приостанавливать действие своих сертификатов и одобрять или отклонять запросы подписчиков на обновление или смену ключей для своих сертификатов. RA, однако, не подписывают и не выдают сертификаты (т.е. RA делегируются определенные задачи от имени CA) ».[2] Хотя Microsoft могла называть подчиненный ЦС RA,[3] это неверно в соответствии со стандартами 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 стандарт определяет наиболее часто используемый формат для сертификаты открытых ключей.[4]

Дизайн

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

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

PKI состоит из:[7][9][10]

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

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

Вообще говоря, традиционно существует три подхода к получению такого доверия: центры сертификации (CA), сеть доверия (WoT) и простая инфраструктура открытого ключа (СПКИ).[нужна цитата ]

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

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

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

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

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

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

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

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

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

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

Сеть доверия

Основная статья: Сеть доверия

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

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

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

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

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

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

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

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

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

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

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

История

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

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

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

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

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

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

Поставщики PKI нашли рынок, но это не совсем тот рынок, который предполагалось в середине 1990-х годов, и он рос как медленнее, так и несколько иначе, чем ожидалось.[27] PKI не решили некоторые проблемы, которые от них ожидали, и несколько крупных поставщиков прекратили свою деятельность или были приобретены другими. PKI добилась наибольшего успеха при внедрении в государственных учреждениях; самая крупная реализация PKI на сегодняшний день - это Агентство оборонных информационных систем (DISA) Инфраструктура PKI для Карты общего доступа программа.

Использует

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

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

  • OpenSSL это простейшая форма CA и инструмент для PKI. Это инструментарий, разработанный на C, который включен во все основные Linux дистрибутивов и может использоваться как для создания собственного (простого) центра сертификации, так и для приложений с поддержкой PKI. (Лицензированный Apache )
  • EJBCA это полнофункциональная реализация CA корпоративного уровня, разработанная в Ява. Его можно использовать для настройки центра сертификации как для внутреннего использования, так и в качестве услуги. (Лицензия LGPL )
  • XiPKI,[29] Ответчик CA и OCSP. С поддержкой SHA3, реализованной на Java. (Лицензированный Apache )
  • OpenCA - это полнофункциональная реализация CA с использованием ряда различных инструментов. OpenCA использует OpenSSL для основных операций PKI.
  • XCA представляет собой графический интерфейс и базу данных. XCA использует OpenSSL для основных операций PKI.
  • (Снято с производства) TinyCA был графическим интерфейсом для OpenSSL.
  • IoT_pki это простой PKI, построенный с использованием Python библиотека криптографии
  • Солдатский жетон это полнофункциональный центр сертификации, разработанный и поддерживаемый как часть Проект Fedora.
  • CFSSL[30][31] набор инструментов с открытым исходным кодом, разработанный CloudFlare для подписания, проверки и объединения сертификатов TLS. (Лицензия BSD с двумя пунктами )
  • Свод[32] инструмент для безопасного управления секретами (включая сертификаты TLS), разработанный HashiCorp. (Лицензия Mozilla Public License 2.0 )
  • Либерметик это автономная система инфраструктуры с открытым ключом, встроенная в C-язык библиотека. Герметик использует LibSodium для всех криптографических операций, и SQLite для всех операций сохранения данных. Программное обеспечение Открытый исходный код и выпущен под Лицензия ISC.

Критика

Смотрите также: X.509 § Безопасность, Comodo Group § 2011 нарушение инцидента, и Diginotar § Выдача поддельных сертификатов

Некоторые утверждают, что покупка сертификатов для защиты веб-сайтов SSL и обеспечение безопасности программного обеспечения подпись кода это дорогостоящее предприятие для малого бизнеса.[33] Однако появление бесплатных альтернатив, таких как Давайте зашифровать, изменил это. HTTP / 2, последняя версия протокола HTTP, теоретически допускает незащищенные соединения; на практике крупные производители браузеров ясно дали понять, что они будут поддерживать этот протокол только через защищенный PKI TLS связь.[34] Реализация HTTP / 2 в веб-браузере, включая Хром, Fire Fox, Опера, и Край поддерживает HTTP / 2 только через TLS, используя ALPN расширение протокола TLS. Это означало бы, что для получения преимущества скорости HTTP / 2 владельцы веб-сайтов были бы вынуждены покупать SSL-сертификаты, контролируемые корпорациями.

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

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

Смотрите также

Рекомендации

  1. ^ «Обзор инфраструктур открытых ключей (PKI)». Техотопия. Получено 26 марта 2015.
  2. ^ «Политика сертификатов инфраструктуры открытых ключей Internet X.509 и концепция сертификации». IETF. Получено 26 августа 2020.
  3. ^ «Инфраструктура открытых ключей». MSDN. Получено 26 марта 2015.
  4. ^ "Использование аутентификации на основе сертификата клиента с NGINX в Ubuntu - SSLTrust". SSLTrust. Получено 13 июн 2019.
  5. ^ Адамс, Карлайл; Ллойд, Стив (2003). Понимание PKI: концепции, стандарты и рекомендации по развертыванию. Эддисон-Уэсли Профессионал. С. 11–15. ISBN  978-0-672-32391-1.
  6. ^ Трчек, Денис (2006). Управление безопасностью и конфиденциальностью информационных систем. Бирхаузер. п. 69. ISBN  978-3-540-28103-0.
  7. ^ а б Вакка, Джон Р. (2004). Инфраструктура открытых ключей: создание надежных приложений и веб-сервисов. CRC Press. п. 8. ISBN  978-0-8493-0822-2.
  8. ^ Вьега, Джон; и другие. (2002). Сетевая безопасность с OpenSSL. O'Reilly Media. С. 61–62. ISBN  978-0-596-00270-1.
  9. ^ МакКинли, Бартон (17 января 2001 г.). «Азбука PKI: расшифровка сложной задачи создания инфраструктуры открытого ключа». Сетевой мир. Архивировано из оригинал 29 мая 2012 г.
  10. ^ Аль-Джанаби, Суфьян Т. Фарадж; и другие. (2012). «Сочетание опосредованной криптографии и криптографии на основе личности для защиты электронной почты». В Ариве, Эзенду; и другие. (ред.). Цифровое предприятие и информационные системы: Международная конференция, Deis, [...] Proceedings. Springer. С. 2–3. ISBN  9783642226021.
  11. ^ «Майк Мейерс CompTIA Security + Certification Passport», Т. Дж. Самуэль, с. 137.
  12. ^ Генри, Уильям (4 марта 2016 г.). «Надежная сторонняя служба».
  13. ^ http://news.netcraft.com/archives/2015/05/13/counting-ssl-certificates.html
  14. ^ «CA: проблемы Symantec». Mozilla Вики. Получено 10 января 2020.
  15. ^ «План Chrome по недоверию сертификатам Symantec». Блог по безопасности Google. Получено 10 января 2020.
  16. ^ «JDK-8215012: Примечание к выпуску: не доверять сертификатам сервера TLS, закрепленным корневыми центрами сертификации Symantec». База данных ошибок Java. Получено 10 января 2020.
  17. ^ Технология единого входа для предприятий SAP: что говорит SAP? «Архивная копия». Архивировано из оригинал на 2011-07-16. Получено 2010-05-25.CS1 maint: заархивированная копия как заголовок (ссылка на сайт)
  18. ^ Эд Герк, Обзор систем сертификации: x.509, CA, PGP и SKIP, в The Black Hat Briefings '99, http://www.securitytechnet.com/resource/rsc-center/presentation/black/vegas99/certover.pdf и http://mcwg.org/mcg-mirror/cert.htm В архиве 2008-09-05 на Wayback Machine
  19. ^ «Децентрализованные идентификаторы (DID)». Консорциум World Wide Web. 9 декабря 2019. Архивировано с оригинал 14 мая 2020 г.. Получено 16 июн 2020.
  20. ^ «Децентрализованная инфраструктура открытых ключей» (PDF). weboftrust.info. 23 декабря 2015 г.. Получено 23 июн 2020.
  21. ^ Аллен, Кристофер (ноябрь 2015 г.). «Децентрализованная инфраструктура открытых ключей» (PDF). Перезагрузка семинара по проектированию сети доверия.
  22. ^ Хуанг, Ясин (14.05.2019). «Децентрализованная инфраструктура открытых ключей (DPKI): что это такое и почему это важно?». Хакерский полдень. Получено 2019-05-22.
  23. ^ Фромкнехт, Коннер (ноябрь 2014 г.). «Децентрализованная инфраструктура открытых ключей с сохранением идентичности» (PDF). IACR Cryptology ePrint Archive.
  24. ^ Бюнц, Бенедикт (февраль 2019 г.). «FlyClient: сверхлегкие клиенты для криптовалют» (PDF). IACR Cryptology ePrint Archive.
  25. ^ Летц, Доминик (май 2019 г.). «BlockQuick: сверхлегкий клиентский протокол для проверки блокчейна на ограниченных устройствах» (PDF). IACR Cryptology ePrint Archive.
  26. ^ Эллис, Джеймс Х. (Январь 1970 г.). «Возможность безопасного несекретного цифрового шифрования» (PDF). Архивировано из оригинал (PDF) на 2014-10-30.
  27. ^ Стивен Уилсон, декабрь 2005 г., «Важность PKI сегодня» В архиве 2010-11-22 на Wayback Machine, China Communications, Проверено 13 декабря 2010 г.
  28. ^ Марк Гассон, Мартин Мейнтс, Кевин Уорвик (2005), D3.2: Исследование PKI и биометрии, Отчет FIDIS (3) 2 июля 2005 г.
  29. ^ "xipki / xipki · GitHub". Github.com. Получено 2016-10-17.
  30. ^ Салливан, Ник (10 июля 2014 г.). «Представляем CFSSL - инструментарий PKI Cloudflare». Блог CloudFlare. CloudFlare. Получено 18 апреля 2018.
  31. ^ "cloudflare / cfssl · GitHub". Github.com. Получено 18 апреля 2018.
  32. ^ "hashicorp / vault · GitHub". Github.com. Получено 18 апреля 2018.
  33. ^ «Должны ли мы отказаться от цифровых сертификатов или научиться их эффективно использовать?». Forbes.
  34. ^ «HTTP / 2: часто задаваемые вопросы». HTTP / 2 вики - через Github.
  35. ^ «Поддельные цифровые сертификаты могут позволить спуфинг». Рекомендации Microsoft по безопасности. Microsoft. 23 марта 2011 г.. Получено 2011-03-24.

внешняя ссылка