Из Википедии, бесплатной энциклопедии
Перейти к навигации Перейти к поиску
Схема инфраструктуры открытого ключа

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

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

Роль PKI, которая может быть делегирована CA для обеспечения действительной и правильной регистрации, называется органом регистрации (RA). По сути, 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]

Возможности [ править ]

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

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

Целостность: гарантия того, что если объект хоть немного изменил (подделал) передаваемые данные, то это было бы очевидно, поскольку его целостность была бы нарушена. Часто не имеет первостепенного значения предотвратить нарушение целостности (защита от несанкционированного доступа), однако крайне важно, чтобы в случае нарушения целостности имелись четкие доказательства того, что это было сделано (очевидное вмешательство).

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

Дизайн [ править ]

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

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

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

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

Методы сертификации [ править ]

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

Центры сертификации [ править ]

Основная роль 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 (Pretty Good Privacy) и GnuPG (реализация OpenPGP , стандартизованной спецификации PGP). Поскольку PGP и его реализации позволяют использовать электронную почтуцифровые подписи для самостоятельной публикации информации с открытым ключом, относительно легко реализовать собственную сеть доверия.

Одним из преимуществ сети доверия, такой как PGP , является то, что она может взаимодействовать с PKI CA, полностью доверенной всеми сторонами в домене (например, внутренним CA в компании), который готов гарантировать сертификаты, поскольку надежный представитель. Если «сеть доверия» является полностью доверенной, то из-за природы сети доверия доверие к одному сертификату дает доверие всем сертификатам в этой сети. 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 на основе блокчейна:

  • CertCoin [23]
  • FlyClient [24]
  • BlockQuick [25]

История [ править ]

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

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

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

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

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

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

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

Использует [ редактировать ]

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

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

Реализации с открытым исходным кодом [ править ]

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

Критика [ править ]

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

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

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

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

См. Также [ править ]

  • Шифрование без сертификата аутентификации
  • Крипто-гибкость

Ссылки [ править ]

  1. ^ «Обзор инфраструктур открытых ключей (PKI)» . Techotopia . Проверено 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. ^ Trček, Denis (2006). Управление безопасностью и конфиденциальностью информационных систем . Бирхаузер. п. 69. ISBN 978-3-540-28103-0.
  7. ^ a b Vacca, Джон Р. (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", TJ Samuelle, p. 137.
  12. ↑ Генри, Уильям (4 марта 2016 г.). «Надежная сторонняя служба» .
  13. ^ http://news.netcraft.com/archives/2015/05/13/counting-ssl-certificates.html
  14. ^ «CA: Проблемы Symantec» . Mozilla Wiki . Проверено 10 января 2020 года .
  15. ^ «План Chrome не доверять сертификатам Symantec» . Блог по безопасности Google . Проверено 10 января 2020 года .
  16. ^ «JDK-8215012: Примечание к выпуску: не доверять сертификатам сервера TLS, закрепленным корневыми центрами сертификации Symantec» . База данных ошибок Java . Проверено 10 января 2020 года .
  17. ^ Технология единого входа для предприятий SAP: что может сказать SAP? «Архивная копия» . Архивировано из оригинала на 2011-07-16 . Проверено 25 мая 2010 .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. Архивировано 5 сентября 2008 г. на Wayback Machine.
  19. ^ «Децентрализованные идентификаторы (DID)» . Консорциум World Wide Web . 9 декабря 2019. Архивировано из оригинала 14 мая 2020 года . Дата обращения 16 июня 2020 .
  20. ^ «Децентрализованная инфраструктура открытых ключей» (PDF) . weboftrust.info . 23 декабря 2015 . Проверено 23 июня 2020 .
  21. ^ Аллен, Кристофер (ноябрь 2015 г.). «Децентрализованная инфраструктура открытых ключей» (PDF) . Перезагрузка семинара Web of Trust Design .
  22. ^ Хуанг, Ясин (2019-05-14). «Децентрализованная инфраструктура открытых ключей (DPKI): что это такое и почему это важно?» . Хакерский полдень . Проверено 22 мая 2019 .
  23. ^ Fromknecht Коннер (ноябрь 2014). «Децентрализованная инфраструктура открытых ключей с сохранением идентичности» (PDF) . IACR Cryptology ePrint Archive .
  24. ^ Bunz, Бенедикта (февраль 2019). «FlyClient: сверхлегкие клиенты для криптовалют» (PDF) . IACR Cryptology ePrint Archive .
  25. ^ Letz, Доминик (май 2019). «BlockQuick: сверхлегкий клиентский протокол для проверки блокчейна на ограниченных устройствах» (PDF) . IACR Cryptology ePrint Archive .
  26. ↑ Эллис, Джеймс Х. (январь 1970 г.). «Возможность безопасного несекретного цифрового шифрования» (PDF) . Архивировано из оригинального (PDF) 30 октября 2014 года.
  27. ↑ Стивен Уилсон, декабрь 2005 г., «Важность PKI сегодня». Архивировано 22ноября 2010 г.в Wayback Machine , China Communications , проверено 13декабря 2010 г.
  28. ^ Марк Гассон, Мартин Мейнтс, Кевин Уорвик (2005), D3.2: Исследование PKI и биометрии , результат FIDIS (3) 2, июль 2005 г.
  29. ^ "xipki / xipki · GitHub" . Github.com . Проверено 17 октября 2016 .
  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 . Проверено 24 марта 2011 .

Внешние ссылки [ править ]

  • Тенденции рыночной доли центров сертификации SSL (W3Techs)