✖


Jump to content

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

PKI состоит из: [9] [11] [12]

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

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

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

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

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

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

Отзыв сертификата [ править ]

Основная статья: Отзыв сертификата

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

При распространении информации об отзыве среди клиентов своевременность обнаружения отзыва (и, следовательно, возможность злоумышленнику использовать скомпрометированный сертификат) уступает место использованию ресурсов при запросе статусов отзыва и проблемам конфиденциальности. [18] Если информация об отзыве недоступна (либо из-за аварии, либо из-за атаки), клиенты должны решить, следует ли выполнять отказоустойчивую работу и рассматривать сертификат как отозванный (и, таким образом, ухудшать доступность ) или же перейти к отказоустойчивому и рассматривать его как неотозванный (и позволить злоумышленникам обойти отзыв). [19]

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

Доля рынка эмитента [ править ]

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

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

Из-за серьезных проблем с управлением выдачей сертификатов все основные игроки постепенно перестали доверять сертификатам, выдаваемым Symantec, начиная с 2017 года и заканчивая 2021 годом. [22] [23] [24] [25]

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

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

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

Сеть доверия [ править ]

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

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

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

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

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

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

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

Децентрализованная PKI [ править ]

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

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

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

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

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

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

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

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

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

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

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

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

  • OpenSSL — это простейшая форма CA и инструмент для PKI. Это набор инструментов, разработанный на языке C, который включен во все основные дистрибутивы Linux и может использоваться как для создания собственного (простого) центра сертификации, так и для приложений с поддержкой PKI. ( лицензия Apache )
  • EJBCA — это полнофункциональная реализация CA корпоративного уровня, разработанная на Java . Его можно использовать для настройки ЦС как для внутреннего использования, так и в качестве услуги. ( лицензия LGPL )
  • КсиПКИ, [36] Ответчик CA и OCSP. С поддержкой SHA-3 , реализованной на Java . ( лицензия Apache )
  • XCA [37] представляет собой графический интерфейс и базу данных. XCA использует OpenSSL для базовых операций PKI.
  • DogTag — это полнофункциональный центр сертификации, разработанный и поддерживаемый в рамках проекта Fedora .
  • CFSSL [38] [39] набор инструментов с открытым исходным кодом, разработанный CloudFlare для подписи, проверки и объединения сертификатов TLS. ( лицензия BSD 2 )
  • Сейф [40] инструмент для безопасного управления секретами (включая TLS-сертификаты), разработанный HashiCorp . ( лицензия Mozilla Public License 2.0 )
  • Boulder — центр сертификации на базе ACME , написанный на Go . Boulder — это программное обеспечение, на котором работает Let's Encrypt .

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

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

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

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

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

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

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

  1. ^ Чиен, Хун-Ю (19 августа 2021 г.). «Сертификаты динамического открытого ключа с прямой секретностью» . Электроника . 10 (16): 2009. doi : 10.3390/electronics10162009 . ISSN   2079-9292 .
  2. ^ «Инфраструктура открытых ключей (PKI)» . Агентство Европейского Союза по кибербезопасности (ENISA) :: Реагирование на инциденты :: Глоссарий . Евросоюз . Проверено 14 мая 2024 г.
  3. ^ Фрулингер, Джош (29 мая 2020 г.). «Что такое PKI? И как она защищает практически все в Интернете» . CSOOnline . Проверено 26 августа 2021 г.
  4. ^ «Политика сертификатов инфраструктуры открытых ключей Интернета X.509 и структура практики сертификации» . IETF . Проверено 26 августа 2020 г.
  5. ^ «Инфраструктура открытых ключей» . MSDN . Проверено 26 марта 2015 г.
  6. ^ «Использование аутентификации на основе сертификата клиента с NGINX в Ubuntu — SSLTrust» . SSLTrust . Проверено 13 июня 2019 г.
  7. ^ Адамс, Карлайл; Ллойд, Стив (2003). Понимание PKI: концепции, стандарты и аспекты развертывания . Аддисон-Уэсли Профессионал. стр. 11–15. ISBN  978-0-672-32391-1 .
  8. ^ Трчек, Денис (2006). Управление безопасностью и конфиденциальностью информационных систем . Биркгаузер. п. 69. ИСБН  978-3-540-28103-0 .
  9. ^ Jump up to: Перейти обратно: а б Вакка, Джон Р. (2004). Инфраструктура открытых ключей: создание доверенных приложений и веб-сервисов . ЦРК Пресс. п. 8. ISBN  978-0-8493-0822-2 .
  10. ^ Вьега, Джон; и др. (2002). Сетевая безопасность с OpenSSL . О'Рейли Медиа. стр. 61–62. ISBN  978-0-596-00270-1 .
  11. ^ МакКинли, Бартон (17 января 2001 г.). «Азбука PKI: расшифровка сложной задачи создания инфраструктуры открытых ключей» . Сетевой мир . Архивировано из оригинала 29 мая 2012 года.
  12. ^ Аль-Джанаби, Суфьян Т. Фарадж; и др. (2012). «Сочетание опосредованной и основанной на идентификации криптографии для защиты электронной почты» . В Арива, Эзенду; и др. (ред.). Цифровое предприятие и информационные системы: Международная конференция, Deis, [...] Proceedings . Спрингер. стр. 2–3. ISBN  9783642226021 .
  13. ^ «Паспорт сертификации Майка Мейерса CompTIA Security+», TJ Samuelle, стр. 137.
  14. ^ Генри, Уильям (4 марта 2016 г.). «Надежная сторонняя служба» . Архивировано из оригинала 4 марта 2016 года . Проверено 4 марта 2016 г.
  15. ^ Смит, Дикинсон и Симонс 2020 , стр. 1.
  16. ^ Jump up to: Перейти обратно: а б Шеффер, Сен-Андре и Фоссати 2022 , 7.5. Отзыв сертификата.
  17. ^ Чунг и др. 2018 , с. 3.
  18. ^ Смит, Дикинсон и Симонс 2020 , стр. 10.
  19. ^ Лариш и др. 2017 , с. 542.
  20. ^ Смит, Дикинсон и Симонс 2020 , стр. 1-2.
  21. ^ «Подсчет SSL-сертификатов» . 13 мая 2015 г.
  22. ^ «CA: Проблемы с Symantec» . Мозилла Вики . Проверено 10 января 2020 г. .
  23. ^ «План Chrome по отказу от доверия к сертификатам Symantec» . Блог Google по безопасности . Проверено 10 января 2020 г. .
  24. ^ «JDK-8215012: Примечание к выпуску: не доверяйте сертификатам сервера TLS, привязанным к корневым центрам сертификации Symantec» . База данных ошибок Java . Проверено 10 января 2020 г. .
  25. ^ «Информация о недоверии к центрам сертификации Symantec» . Поддержка Apple . 05.09.2023 . Проверено 16 января 2024 г.
  26. ^ Технология единого входа для SAP Enterprises: что говорит SAP? «Технология единого входа для предприятий SAP: что говорит SAP? | Май 2010 г. | SECUDE AG» . Архивировано из оригинала 16 июля 2011 г. Проверено 25 мая 2010 г.
  27. ^ Эд Герк, Обзор систем сертификации: 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.
  28. ^ Гонсалес, Элой. «Простая инфраструктура открытых ключей» (PDF) .
  29. ^ «Децентрализованные идентификаторы (DID)» . Консорциум Всемирной паутины . 9 декабря 2019 года. Архивировано из оригинала 14 мая 2020 года . Проверено 16 июня 2020 г.
  30. ^ «Децентрализованная инфраструктура открытых ключей» . weboftrust.info . 23 декабря 2015 года . Проверено 23 июня 2020 г.
  31. ^ Эллис, Джеймс Х. (январь 1970 г.). «Возможность безопасного несекретного цифрового шифрования» (PDF) . Архивировано из оригинала (PDF) 30 октября 2014 г.
  32. ^ Продрому, Агатоклис (31 марта 2019 г.). «Безопасность TLS 2: Краткая история SSL/TLS» . Акунетикс . Проверено 25 мая 2024 г.
  33. ^ «Руководство по оценке PKI» (PDF) . Комитет информационной безопасности . 0,3 : 43. 2001.
  34. ^ Стивен Уилсон, декабрь 2005 г., «Важность PKI сегодня». Архивировано 22 ноября 2010 г. в Wayback Machine , China Communications , Проверено 13 декабря 2010 г.
  35. ^ Марк Гассон, Мартин Мейнц, Кевин Уорвик (2005), D3.2: Исследование PKI и биометрии , результат FIDIS (3)2, июль 2005 г.
  36. ^ «xipki/xipki · GitHub» . Гитхаб.com . Проверено 17 октября 2016 г.
  37. ^ Хонштадт, Кристиан. «X — Управление сертификатами и ключами» . hohnstaedt.de . Проверено 29 декабря 2023 г.
  38. ^ Салливан, Ник (10 июля 2014 г.). «Представляем CFSSL — набор инструментов PKI Cloudflare» . Блог CloudFlare . CloudFlare . Проверено 18 апреля 2018 г.
  39. ^ «cloudflare/cfssl · GitHub» . Гитхаб.com . Проверено 18 апреля 2018 г.
  40. ^ «hashicorp/хранилище · GitHub» . Гитхаб.com . Проверено 18 апреля 2018 г.
  41. ^ «Следует ли нам отказаться от цифровых сертификатов или научиться использовать их эффективно?» . Форбс .
  42. ^ «Часто задаваемые вопросы по HTTP/2» . HTTP/2 вики — через Github.
  43. ^ «Корневой сертификат против промежуточных сертификатов» . О SSL . Проверено 2 мая 2022 г.
  44. ^ «Мошеннические цифровые сертификаты могут допускать подделку» . Рекомендации Microsoft по безопасности . Майкрософт. 23 марта 2011 года . Проверено 24 марта 2011 г.

Цитируемые работы [ править ]

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

Retrieved from "https://en.wikipedia.org/w/index.php?title=Public_key_infrastructure&oldid=1229379472"
Arc.Ask3.Ru: конец переведенного документа.
Arc.Ask3.Ru
Номер скриншота №: 242e90a9369dc7a8282a6c23ce27833f__1718534280
URL1:https://arc.ask3.ru/arc/aa/24/3f/242e90a9369dc7a8282a6c23ce27833f.html
Заголовок, (Title) документа по адресу, URL1:
Public key infrastructure - Wikipedia
Данный printscreen веб страницы (снимок веб страницы, скриншот веб страницы), визуально-программная копия документа расположенного по адресу URL1 и сохраненная в файл, имеет: квалифицированную, усовершенствованную (подтверждены: метки времени, валидность сертификата), открепленную ЭЦП (приложена к данному файлу), что может быть использовано для подтверждения содержания и факта существования документа в этот момент времени. Права на данный скриншот принадлежат администрации Ask3.ru, использование в качестве доказательства только с письменного разрешения правообладателя скриншота. Администрация Ask3.ru не несет ответственности за информацию размещенную на данном скриншоте. Права на прочие зарегистрированные элементы любого права, изображенные на снимках принадлежат их владельцам. Качество перевода предоставляется как есть. Любые претензии, иски не могут быть предъявлены. Если вы не согласны с любым пунктом перечисленным выше, вы не можете использовать данный сайт и информация размещенную на нем (сайте/странице), немедленно покиньте данный сайт. В случае нарушения любого пункта перечисленного выше, штраф 55! (Пятьдесят пять факториал, Денежную единицу (имеющую самостоятельную стоимость) можете выбрать самостоятельно, выплаичвается товарами в течение 7 дней с момента нарушения.)