stringtranslate.com

X.509

В криптографии X.509 — это стандарт Международного союза электросвязи (МСЭ), определяющий формат сертификатов открытых ключей . [1] Сертификаты X.509 используются во многих интернет-протоколах, включая TLS/SSL , который является основой для HTTPS , [2] безопасного протокола для просмотра веб-страниц . Они также используются в офлайн-приложениях, таких как электронные подписи . [3]

Сертификат X.509 связывает личность с открытым ключом с помощью цифровой подписи. Сертификат содержит личность (имя хоста, организации или отдельного лица) и открытый ключ ( RSA , DSA , ECDSA , ed25519 и т. д.) и либо подписан центром сертификации, либо является самоподписанным. Когда сертификат подписан доверенным центром сертификации или проверен другими способами, кто-то, владеющий этим сертификатом, может использовать открытый ключ, который он содержит, для установления безопасной связи с другой стороной или для проверки документов, подписанных в цифровой форме соответствующим закрытым ключом .

X.509 также определяет списки отозванных сертификатов , которые являются средством распространения информации о сертификатах, признанных недействительными подписывающим органом, а также алгоритм проверки пути сертификации , который позволяет подписывать сертификаты промежуточными сертификатами CA, которые, в свою очередь, подписываются другими сертификатами, в конечном итоге достигая якоря доверия .

X.509 определен «Сектором стандартизации» МСЭ ( ИК17 МСЭ-Т ) в Исследовательской группе 17 МСЭ-Т и основан на абстрактной синтаксической нотации версии 1 (ASN.1), другом стандарте МСЭ-Т.

История и использование

X.509 был первоначально выпущен 3 июля 1988 года и был начат совместно со стандартом X.500 . Первыми его задачами было предоставление пользователям безопасного доступа к информационным ресурсам и предотвращение криптографической атаки типа «человек посередине» . Он предполагает строгую иерархическую систему центров сертификации (CA) для выдачи сертификатов. Это контрастирует с моделями сети доверия , такими как PGP , где любой (а не только специальные CA) может подписывать и, таким образом, подтверждать действительность сертификатов ключей других.

Версия 3 X.509 включает гибкость для поддержки других топологий, таких как мосты и сетки . [2] Он может использоваться в одноранговой сети доверия, подобной OpenPGP , [ требуется ссылка ], но редко использовался таким образом по состоянию на 2004 год . Система X.500 была реализована только суверенными государствами [ какими? ] для целей выполнения договора о совместном использовании информации о государственных идентификаторах, а рабочая группа IETF Public-Key Infrastructure (X.509) (PKIX) адаптировала стандарт к более гибкой организации Интернета. Фактически, термин сертификат X.509 обычно относится к сертификату IETF PKIX и профилю CRL стандарта сертификата X.509 v3, как указано в RFC  5280, обычно называемому PKIX для Public Key Infrastructure (X.509) . [4]

Ранней проблемой с Public Key Infrastructure (PKI) и сертификатами X.509 была известная проблема «какой каталог». Проблема в том, что клиент не знает, где получить отсутствующие промежуточные сертификаты, поскольку глобальный каталог X.500 так и не материализовался. Проблема была смягчена путем включения всех промежуточных сертификатов в запрос. Например, ранние веб-серверы отправляли клиенту только сертификат веб-сервера. Клиенты, у которых не было промежуточного сертификата CA или где его найти, не могли построить действительный путь от CA к сертификату сервера. Чтобы обойти эту проблему, веб-серверы теперь отправляют все промежуточные сертификаты вместе с сертификатом веб-сервера. [5]

Хотя PKIX относится к стандарту PKI IETF или Интернета, существует множество других PKI с другими политиками. Например, у правительства США есть свой PKI со своими собственными политиками, а у CA/Browser Forum есть свой PKI со своими собственными политиками. PKI правительства США — это огромная книга объемом более 2500 страниц. Если PKI организации слишком сильно отличается от PKI IETF или CA/Browser Forum, то организация рискует потерять совместимость с такими распространенными инструментами, как веб-браузеры , cURL и Wget . Например, если у PKI есть политика выдачи сертификатов только по понедельникам, то распространенные инструменты, такие как cURL и Wget, не будут применять эту политику и разрешат выдачу сертификата во вторник. [5]

Сертификаты

Сертификаты X.509 связывают личность с открытым ключом с помощью цифровой подписи. В системе X.509 существует два типа сертификатов. Первый — сертификат CA. Второй — сертификат конечного субъекта. Сертификат CA может выдавать другие сертификаты. Самоподписанный сертификат CA верхнего уровня иногда называют корневым сертификатом CA. Другие сертификаты CA называются промежуточными CA или подчиненными сертификатами CA. Сертификат конечного субъекта идентифицирует пользователя, например, человека, организацию или бизнес. Сертификат конечного субъекта не может выдавать другие сертификаты. Сертификат конечного субъекта иногда называют листовым сертификатом, поскольку под ним не могут быть выданы другие сертификаты.

Организация, которая хочет получить подписанный сертификат, запрашивает его у CA, используя протокол, такой как Certificate Signing Request (CSR) , Simple Certificate Enrollment Protocol (SCEP) или Certificate Management Protocol (CMP) . Организация сначала генерирует пару ключей , сохраняя закрытый ключ в секрете и используя его для подписания CSR. CSR содержит информацию, идентифицирующую заявителя, и открытый ключ заявителя , который используется для проверки подписи CSR, а также уникальное имя (DN), которое является уникальным для человека, организации или предприятия. CSR может сопровождаться другими учетными данными или доказательствами личности, требуемыми центром сертификации.

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

Доверенные корневые сертификаты организации могут быть распространены среди всех сотрудников, чтобы они могли использовать систему PKI компании. Такие браузеры, как Internet Explorer , Firefox , Opera , Safari и Chrome, поставляются с предопределенным набором предустановленных корневых сертификатов, поэтому SSL- сертификаты от основных центров сертификации будут работать мгновенно; по сути, разработчики браузеров определяют, какие центры сертификации являются доверенными третьими сторонами для пользователей браузеров. Например, Firefox предоставляет файл CSV и/или HTML, содержащий список включенных центров сертификации. [8]

X.509 и RFC  5280 также включают стандарты для реализаций списков отзыва сертификатов (CRL). Другим одобренным IETF способом проверки действительности сертификата является Online Certificate Status Protocol (OCSP). Firefox 3.0 включил проверку OCSP по умолчанию, как и версии Windows , начиная с Vista и выше. [9]

Структура сертификата

Структура, предусмотренная стандартами, выражена на формальном языке, абстрактной синтаксической нотации версии 1 (ASN.1).

Структура цифрового сертификата X.509 v3 выглядит следующим образом:

Поле Extensions, если оно присутствует, представляет собой последовательность одного или нескольких расширений сертификата. [10] : §4.1.2.9: Расширения  Каждое расширение имеет свой собственный уникальный идентификатор, выраженный как идентификатор объекта (OID) , который представляет собой набор значений вместе с критическим или некритическим указанием. Система, использующая сертификат, должна отклонить сертификат, если она сталкивается с критическим расширением, которое она не распознает, или критическим расширением, содержащим информацию, которую она не может обработать. Некритическое расширение может быть проигнорировано, если оно не распознано, но должно быть обработано, если оно распознано. [10] : §4.2: Расширения сертификатов 

Структура версии 1 приведена в RFC  1422.

Внутренний формат уникальных идентификаторов эмитента и субъекта, указанный в X.520 Справочник: Рекомендации по выбранным типам атрибутов.

ITU-T ввел уникальные идентификаторы эмитента и субъекта в версии 2, чтобы разрешить повторное использование имени эмитента или субъекта через некоторое время. Примером повторного использования может быть банкротство CA и удаление его имени из публичного списка страны. Через некоторое время другой CA с тем же именем может зарегистрироваться, даже если он не связан с первым. Однако IETF рекомендует не использовать повторно имена эмитента и субъекта. Поэтому версия 2 не получила широкого распространения в Интернете. [ необходима цитата ]

Расширения были введены в версии 3. Центр сертификации может использовать расширения для выдачи сертификата только для определенной цели (например, только для подписи цифровых объектов ).

Во всех версиях серийный номер должен быть уникальным для каждого сертификата, выданного конкретным центром сертификации (как указано в RFC  5280).

Расширения, информирующие о конкретном использовании сертификата

RFC  5280 (и его предшественники) определяет ряд расширений сертификатов, которые указывают, как сертификат должен использоваться. Большинство из них являются дугами из joint-iso-ccitt(2) ds(5) id-ce(29)OID. Некоторые из наиболее распространенных, определенные в разделе 4.2.1, следующие:

В общем случае при использовании RFC  5280, если сертификат имеет несколько расширений, ограничивающих его использование, все ограничения должны быть выполнены для данного использования, чтобы быть приемлемым. RFC дает конкретный пример сертификата, содержащего как keyUsage, так и extendedKeyUsage: в этом случае оба должны быть обработаны, и сертификат может быть использован только в том случае, если оба расширения согласованы в указании использования сертификата. Например, NSS использует оба расширения для указания использования сертификата. [11]

Сертификаты расширенной проверки

Центры сертификации, работающие в рамках PKI CA/Browser Forum, выдают сертификаты с различными уровнями проверки. Различные проверки обеспечивают различные уровни гарантий того, что сертификат представляет то, что он должен. Например, веб-сервер может быть проверен на самом низком уровне гарантий с помощью электронной почты, называемой Domain Validation (DV) . Или веб-сервер может быть проверен на более высоком уровне гарантий с помощью более подробных методов, называемых Extended Validation (EV) .

На практике сертификат DV означает, что сертификат был выдан для домена, например , example.comпосле того, как кто-то ответил на электронное письмо, отправленное на [email protected]. Сертификат EV означает, что сертификат был выдан для домена, например example.com, и компания, например Example, LLC, является владельцем домена, и владелец был проверен Учредительным договором .

Расширенная проверка не добавляет никаких дополнительных мер безопасности, поэтому настройка защищенного канала с использованием сертификата EV не «надежнее», чем настройка канала с использованием другого уровня проверки, например DV.

Расширенная проверка сигнализируется в сертификате с использованием расширения X.509 v3. Каждый CA использует другой идентификатор объекта (OID) для подтверждения расширенной проверки. Не существует единого OID для указания расширенной проверки, что усложняет программирование пользовательского агента. Каждый пользовательский агент должен иметь список OID, которые указывают на расширенную проверку.

PKI CA/Browser Forum распознает расширенную проверку, и многие браузеры предоставляют пользователю визуальную обратную связь, чтобы указать, что сайт предоставляет сертификат EV. Другие PKI, такие как PKI Интернета (PKIX), не уделяют особого внимания расширенной проверке. Инструменты, использующие политики PKIX, такие как cURL и Wget, просто обрабатывают сертификат EV как любой другой сертификат.

Эксперт по безопасности Питер Гутманн утверждает, что CA создали сертификаты EV, чтобы восстановить уровень прибыли после того, как «гонка на дно» сократила прибыль. Во время гонки на дно CA снизили цены, чтобы соблазнить потребителей покупать их сертификаты. В результате прибыль сократилась, и CA снизили уровень проверки, которую они проводили, до такой степени, что в сертификате почти не было никаких гарантий. [5]

Расширения имени файла сертификата

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

PKCS#7 — это стандарт для подписи или шифрования (официально называемый «конвертированием») данных. Поскольку сертификат необходим для проверки подписанных данных, их можно включить в структуру SignedData.

Цепочки сертификатов и кросс-сертификация

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

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

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

Описание в предыдущем абзаце представляет собой упрощенный взгляд на процесс проверки пути сертификации , определенный в разделе 6 RFC  5280, который включает дополнительные проверки, такие как проверка дат действия сертификатов, поиск списков отзыва сертификатов и т. д.

Пример 1: Перекрестная сертификация между двумя PKI
Пример 2: Обновление сертификата CA

Рассматривая, как строятся и проверяются цепочки сертификатов, важно отметить, что конкретный сертификат может быть частью совершенно разных цепочек сертификатов (все они действительны). Это связано с тем, что несколько сертификатов CA могут быть сгенерированы для одного и того же субъекта и открытого ключа, но подписаны разными закрытыми ключами (из разных CA или разными закрытыми ключами из одного CA). Таким образом, хотя один сертификат X.509 может иметь только одного издателя и одну подпись CA, он может быть действительно связан с несколькими сертификатами, создавая совершенно разные цепочки сертификатов. Это имеет решающее значение для перекрестной сертификации между PKI и другими приложениями. [13] См. следующие примеры:

Примеры

На этих диаграммах:

Пример 1: Кросс-сертификация на уровне корневого центра сертификации (CA) между двумя PKI

Чтобы обеспечить доверие PKI 1 к пользовательским сертификатам, существующим в PKI 2 (например, «Пользователь 2»), CA1 генерирует сертификат (cert2.1), содержащий открытый ключ CA2. [14] Теперь и «cert2», и «cert2.1» (зеленый) имеют одинаковый субъект и открытый ключ, поэтому для cert2.2 (Пользователь 2) существуют две действительные цепочки: «cert2.2 → cert2» и «cert2.2 → cert2.1 → cert1».

Аналогичным образом CA2 может сгенерировать сертификат (cert1.1), содержащий открытый ключ CA1, чтобы сертификаты пользователей, существующие в PKI 1 (например, «Пользователь 1»), были доверенными для PKI 2.

Пример 2: Обновление сертификата CA

Understanding Certification Path Construction (PDF) . Форум PKI. Сентябрь 2002 г. Чтобы обеспечить плавный переход от старой пары ключей подписи к новой паре ключей подписи, центр сертификации должен выдать сертификат, содержащий старый открытый ключ, подписанный новым закрытым ключом подписи, и сертификат, содержащий новый открытый ключ, подписанный старым закрытым ключом подписи. Оба эти сертификата являются самовыпущенными, но ни один из них не является самоподписанным . Обратите внимание, что они являются дополнением к двум самоподписанным сертификатам (одному старому, одному новому).

Поскольку и cert1, и cert3 содержат один и тот же открытый ключ (старый), для cert5 существуют две действительные цепочки сертификатов: "cert5 → cert1" и "cert5 → cert3 → cert2", и аналогично для cert6. Это позволяет, чтобы старые пользовательские сертификаты (такие как cert5) и новые сертификаты (такие как cert6) могли быть доверены одинаково стороной, имеющей либо новый корневой сертификат CA, либо старый в качестве якоря доверия во время перехода на новые ключи CA. [15]

Образцы сертификатов X.509

Это пример расшифрованного сертификата X.509, который использовался в прошлом wikipedia.org и несколькими другими сайтами Wikipedia. Он был выпущен GlobalSign , как указано в поле Issuer. Его поле Subject описывает Wikipedia как организацию, а его поле Subject Alternative Name (SAN) для DNS описывает имена хостов, для которых он может использоваться. Поле Subject Public Key Info содержит открытый ключ ECDSA , в то время как подпись внизу была сгенерирована закрытым ключом RSA GlobalSign . (Подписи в этих примерах усечены.)

Сертификат конечного объекта

Сертификат: Данные: Версия: 3 (0x2) Серийный номер: 10:e6:fc:62:b7:41:8a:d5:00:5e:45:b6 Алгоритм подписи: sha256WithRSAEncryption Эмитент: C=BE, O=GlobalSign nv-sa, CN=GlobalSign Проверка организации CA - SHA256 - G2 Действительность Не раньше: 21 ноября 08:00:00 2016 GMT Не позже: 22 ноября 07:59:59 2017 GMT Тема: C=США, ST=Калифорния, L=Сан-Франциско, O=Wikimedia Foundation, Inc., CN=*.wikipedia.org Информация о публичном ключе субъекта: Алгоритм открытого ключа: id-ecPublicKey Открытый ключ: (256 бит) паб: 00:c9:22:69:31:8a:d6:6c:ea:da:c3:7f:2c:ac:a5: af:c0:02:ea:81:cb:65:b9:fd:0c:6d:46:5b:c9:1e: 9д:3б:эф ASN1 OID: prime256v1 КРИВАЯ NIST: P-256 Расширения X509v3: Использование ключа X509v3: критическое Цифровая подпись, соглашение о ключах Доступ к информации органов власти: Эмитенты CA - URI: http://secure.globalsign.com/cacert/gsorganizationvalsha2g2r1.crt OCSP - URI: http://ocsp2.globalsign.com/gsorganizationvalsha2g2 Политики сертификата X509v3: Политика: 1.3.6.1.4.1.4146.1.20 CPS: https://www.globalsign.com/repository/ Политика: 2.23.140.1.2.2 Основные ограничения X509v3: КА:ЛОЖЬ Точки распространения CRL X509v3: Полное имя: URI:http://crl.globalsign.com/gs/gsorganizationvalsha2g2.crl X509v3 Альтернативное имя субъекта: DNS:*.wikipedia.org, DNS:*.m.mediawiki.org, DNS:*.m.wikibooks.org, DNS:*.m.wikidata.org, DNS:*.m.wikimedia.org, DNS: *.m.wikimediafoundation.org, DNS:*.m.wikinews.org, DNS:*.m.wikipedia.org, DNS:*.m.wikiquote.org, DNS:*.m.wikisource.org, DNS: *.m.wikiversity.org, DNS:*.m.wikivoyage.org, DNS:*.m.wiktionary.org, DNS:*.mediawiki.org, DNS:*.planet.wikimedia.org, DNS:*. wikibooks.org, DNS:*.wikidata.org, DNS:*.wikimedia.org, DNS:*.wikimediafoundation.org, DNS:*.wikinews.org, DNS:*.wikiquote.org, DNS:*.wikisource.org, DNS:*.wikiversity.org, DNS:*.wikivoyage.org, DNS:*.wiktionary.org, DNS:*.wmfusercontent.org, DNS: *.zero.wikipedia.org, DNS:mediawiki.org, DNS:w.wiki, DNS:wikibooks.org, DNS:wikidata.org, DNS:wikimedia.org, DNS:wikimediafoundation.org, DNS:wikinews.org, DNS:wikiquote.org, DNS:wikisource.org, DNS:wikiversity.org, DNS:wikivoyage.org, DNS:wiktionary.org, DNS:wmfusercontent.org, DNS:wikipedia.org Использование расширенного ключа X509v3: Аутентификация веб-сервера TLS, Аутентификация веб-клиента TLS Идентификатор ключа субъекта X509v3: 28:2A:26:2A:57:8B:3B:CE:B4:D6:AB:54:EF:D7:38:21:2C:49:5C:36 Идентификатор ключа авторизации X509v3: идентификатор ключа:96:DE:61:F1:BD:1C:16:29:53:1C:C0:CC:7D:3B:83:00:40:E6:1A:7C
 Алгоритм подписи: sha256WithRSAEncryption 8б:в3:ред:д1:9д:39:6е:аф:40:72:бд:1д:18:5д:30:54:23:35: ...

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

В соединении TLS правильно настроенный сервер предоставит промежуточный сертификат как часть рукопожатия. Однако также возможно получить промежуточный сертификат, извлекая URL-адрес "CA Issuers" из сертификата конечного объекта.

Промежуточный сертификат

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

Сертификат: Данные: Версия: 3 (0x2) Серийный номер: 04:00:00:00:00:01:44:4e:f0:42:47 Алгоритм подписи: sha256WithRSAEncryption Эмитент: C=BE, O=GlobalSign nv-sa, OU=Корневой центр сертификации, CN=Корневой центр сертификации GlobalSign Действительность Не раньше: 20 февраля 10:00:00 2014 GMT Не позже: 20 февраля 10:00:00 2024 GMT Тема: C=BE, O=GlobalSign nv-sa, CN=GlobalSign Проверка организации CA - SHA256 - G2 Информация о публичном ключе субъекта: Алгоритм открытого ключа: rsaEncryption Открытый ключ: (2048 бит) Модуль: 00:c7:0e:6c:3f:23:93:7f:cc:70:a5:9d:20:c3:0e: ... Экспонента: 65537 (0x10001) Расширения X509v3: Использование ключа X509v3: критическое Знак сертификата, знак CRL Основные ограничения X509v3: критические CA:TRUE, pathlen:0 Идентификатор ключа субъекта X509v3: 96:DE:61:F1:BD:1C:16:29:53:1C:C0:CC:7D:3B:83:00:40:E6:1A:7C Политики сертификата X509v3: Политика: X509v3 Любая политика CPS: https://www.globalsign.com/repository/ Точки распространения CRL X509v3: Полное имя: URI:http://crl.globalsign.net/root.crl Доступ к информации органов власти: OCSP - URI: http://ocsp.globalsign.com/rootr1 Идентификатор ключа авторизации X509v3: keyid:60:7B:66:1A:45:0D:97:CA:89:50:2F:7D:04:CD:34:A8:FF:FC:FD:4B Алгоритм подписи: sha256WithRSAEncryption 46:2a:ee:5e:bd:ae:01:60:37:31:11:86:71:74:b6:46:49:c8: ...

Корневой сертификат

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

Сертификат: [16] Данные: Версия: 3 (0x2) Серийный номер: 04:00:00:00:00:01:15:4b:5a:c3:94 Алгоритм подписи: sha1WithRSAEncryption Эмитент: C=BE, O=GlobalSign nv-sa, OU=Корневой центр сертификации, CN=Корневой центр сертификации GlobalSign Действительность Не раньше: 1 сентября 12:00:00 1998 GMT Не позже: 28 января 12:00:00 2028 GMT Тема: C=BE, O=GlobalSign nv-sa, OU=Корневой центр сертификации, CN=Корневой центр сертификации GlobalSign Информация о публичном ключе субъекта: Алгоритм открытого ключа: rsaEncryption Открытый ключ: (2048 бит) Модуль: 00:da:0e:e6:99:8d:ce:a3:e3:4f:8a:7e:fb:f1:8b: ... Экспонента: 65537 (0x10001) Расширения X509v3: Использование ключа X509v3: критическое Знак сертификата, знак CRL Основные ограничения X509v3: критические КА:ИСТИНА Идентификатор ключа субъекта X509v3: 60:7B:66:1A:45:0D:97:CA:89:50:2F:7D:04:CD:34:A8:FF:FC:FD:4B Алгоритм подписи: sha1WithRSAEncryption d6:73:e7:7c:4f:76:d0:8d:bf:ec:ba:a2:be:34:c5:28:32:b5: ...

Безопасность

Существует ряд публикаций о проблемах PKI, написанных Брюсом Шнайером , Питером Гутманном и другими экспертами по безопасности. [17] [18] [19]

Архитектурные недостатки

Проблемы с органами сертификации

Проблемы внедрения

Реализации страдают от недостатков дизайна, ошибок, различных интерпретаций стандартов и отсутствия взаимодействия различных стандартов. Некоторые проблемы:

Криптографические уязвимости

Системы цифровой подписи зависят от безопасных криптографических хэш-функций для работы. Когда инфраструктура открытого ключа позволяет использовать хэш-функцию, которая больше не является безопасной, злоумышленник может использовать уязвимости в хэш-функции для подделки сертификатов. В частности, если злоумышленник может создать коллизию хэшей , он может убедить CA подписать сертификат с безобидным содержимым, где хэш этого содержимого идентичен хешу другого, вредоносного набора содержимого сертификата, созданного злоумышленником со значениями по его выбору. Затем злоумышленник может добавить предоставленную CA подпись к своему вредоносному содержимому сертификата, в результате чего получится вредоносный сертификат, который, по-видимому, подписан CA. Поскольку вредоносное содержимое сертификата выбирается исключительно злоумышленником, у него могут быть другие даты действия или имена хостов, чем у безобидного сертификата. Вредоносный сертификат может даже содержать поле «CA: true», что позволяет ему выдавать дополнительные доверенные сертификаты.

Меры по устранению криптографических уязвимостей

Использование коллизии хэшей для подделки подписей X.509 требует, чтобы злоумышленник мог предсказать данные, которые подпишет центр сертификации. Это может быть несколько смягчено CA, генерирующим случайный компонент в подписываемых им сертификатах, обычно серийный номер. Форум CA/Browser требует энтропию серийного номера в своем разделе 7.1 базовых требований с 2011 года. [35]

С 1 января 2016 года Базовые требования запрещают выдачу сертификатов, использующих SHA-1. С начала 2017 года Chrome [36] и Firefox [37] отклоняют сертификаты, использующие SHA-1. С мая 2017 года Edge [38] и Safari [39] также отклоняют сертификаты SHA-1. Валидаторы X.509, не являющиеся браузерами, пока не отклоняют сертификаты SHA-1. [40]

Стандарты PKI для X.509

Рабочая группа PKIX

В 1995 году Internet Engineering Task Force совместно с Национальным институтом стандартов и технологий [45] сформировали рабочую группу Public-Key Infrastructure (X.509). Рабочая группа, завершившая свою работу в июне 2014 года, [46] обычно называется «PKIX». Она выпустила RFC и другую документацию по стандартам использования и развертывания X.509 на практике. В частности, она выпустила RFC  3280 и его преемник RFC 5280, которые определяют, как использовать X.509 в интернет-протоколах.

Основные протоколы и стандарты, использующие сертификаты X.509

TLS/SSL и HTTPS используют профиль RFC  5280 X.509, как и S/MIME (Secure Multipurpose Internet Mail Extensions) и метод EAP-TLS для аутентификации WiFi. Любой протокол, использующий TLS, например SMTP, POP, IMAP, LDAP, XMPP и многие другие, по своей сути использует X.509.

IPsec может использовать профиль RFC  4945 для аутентификации одноранговых узлов.

Спецификация безопасности OpenCable определяет собственный профиль X.509 для использования в кабельной отрасли.

Такие устройства, как смарт-карты и TPM, часто имеют сертификаты для идентификации себя или своих владельцев. Эти сертификаты имеют форму X.509.

Стандарт WS-Security определяет аутентификацию либо через TLS, либо через собственный профиль сертификата. [16] Оба метода используют X.509.

Система подписи кода Microsoft Authenticode использует X.509 для идентификации авторов компьютерных программ.

Стандарт связи промышленной автоматизации OPC UA использует X.509.

SSH обычно использует модель безопасности Trust On First Use и не нуждается в сертификатах. Однако популярная реализация OpenSSH поддерживает модель идентификации, подписанную CA, на основе собственного формата сертификата, отличного от X.509. [47]

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

Ссылки

  1. ^ "X.509: Информационные технологии - Взаимосвязь открытых систем - Справочник: Структуры сертификатов открытых ключей и атрибутов". ITU . Получено 6 ноября 2019 г. .
  2. ^ ab Hesse, Peter; Cooper, Matt; Dzambasow, Yuriy A.; Joseph, Susan; Nicholas, Richard (сентябрь 2005 г.). Инфраструктура открытых ключей Internet X.509: построение пути сертификации. Сетевая рабочая группа. doi : 10.17487/RFC4158 . RFC 4158. Информационный.
  3. ^ "Монументальные ошибки кибербезопасности". circleid.com . Получено 2022-09-03 .
  4. ^ Купер, Д.; Сантессон, С.; Фаррелл, С.; Боен, С.; Хаусли, Р.; Полк, В. (май 2008 г.). Профиль сертификата инфраструктуры открытых ключей Интернета X.509 и списка отзыва сертификатов (CRL). doi : 10.17487/RFC5280 . RFC 5280. Предлагаемый стандарт. Обновлен RFC 9549, 9598, 8398, 8399 и 6818. Отменяет RFC 4630, 4325 и 3280. Ниже приведен упрощенный вид архитектурной модели, принятой инфраструктурой открытых ключей с использованием спецификаций X.509 (PKIX).
  5. ^ abcd Гутманн, Питер (апрель 2014 г.). «Инженерная безопасность» (PDF) .
  6. ^ Хаусли, Р.; Хоффман, П. (май 1999 г.). Протоколы эксплуатации инфраструктуры открытых ключей Интернета X.509: FTP и HTTP. Сетевая рабочая группа. doi : 10.17487/RFC2585 . RFC 2585. Предлагаемый стандарт. Раздел 4: Регистрация MIME.
  7. ^ "x509Certificate". Документация разработчика Apple: унифицированные идентификаторы типов . Apple Inc .
  8. ^ "CA:IncludedCAs". Mozilla Wiki . Получено 17 января 2017 г.
  9. ^ "Ошибка 110161 - (ocspdefault) включить OCSP по умолчанию". Mozilla . Получено 17 марта 2016 г. .
  10. ^ abcdef Купер, Д.; Сантессон, С.; Фаррелл, С.; Боен, С.; Хаусли, Р.; Полк, В. (май 2008 г.). Профиль сертификата инфраструктуры открытых ключей Интернета X.509 и списка отзыва сертификатов (CRL). doi : 10.17487/RFC5280 . RFC 5280. Предлагаемый стандарт. Обновлен RFC 9549, 9598, 8398, 8399 и 6818. Отменяет RFC 4630, 4325 и 3280.
  11. ^ Нельсон Б. Боярд (9 мая 2002 г.). «Все о расширениях сертификатов». Mozilla . Получено 10 сентября 2020 г. .
  12. ^ sysadmin1138 (19 мая 2009 г.). «Что такое файл PEM и чем он отличается от других форматов файлов ключей, сгенерированных OpenSSL?». Ошибка сервера . Получено 19 октября 2023 г.{{cite web}}: CS1 maint: числовые имена: список авторов ( ссылка )  В данной статье использован текст из этого источника, доступный по лицензии CC BY-SA 2.5.
  13. ^ Ллойд, Стив (сентябрь 2002 г.). Понимание построения пути сертификации (PDF) . Форум PKI.
  14. ^ «Перекрестная сертификация между корневыми центрами сертификации». Сценарии развертывания квалифицированного подчинения. Microsoft. Август 2009 г.
  15. ^ Nash; Duane; Joseph; Brink (2001). "Жизненные циклы ключей и сертификатов. Обновление сертификата CA". PKI: Внедрение и управление электронной безопасностью . RSA Press - Osborne/McGraw-Hill. ISBN 0-07-213123-3.
  16. ^ ab "Web Services Security X.509 Token Profile Version 1.1.1". Oasis . Получено 14 марта 2017 г. .
  17. ^ Карл Эллисон и Брюс Шнайер. "10 главных рисков PKI" (PDF) . Computer Security Journal (том XVI, номер 1, 2000).
  18. ^ Питер Гутман . "PKI: она не умерла, просто отдыхает" (PDF) . IEEE Computer (Том:35, Выпуск: 8).
  19. ^ ab Гутманн, Питер . "Все, что вы никогда не хотели знать о PKI, но были вынуждены узнать" (PDF) . Получено 14 ноября 2011 г.
  20. ^ Лэнгли, Адам (5 февраля 2012 г.). «Проверка отзыва и CRL Chrome». Imperial Violet . Получено 2 февраля 2017 г.
  21. ^ "Образец бизнес-плана систем безопасности [2021]". OGScapital . 2014-01-27 . Получено 2021-06-30 .
  22. ^ Майкл Зусман; Александр Сотиров (июль 2009 г.). «Sub-Prime PKI: Attacking Extended Validation SSL» (PDF) . Blackhat . Получено 10 сентября 2020 г. .
  23. ^ Хант, Трой (17 сентября 2018 г.). «Сертификаты расширенной проверки мертвы». TroyHunt.com . Получено 26 февраля 2019 г. .
  24. ^ "Сертификационный центр — Заявление о практике сертификации" (PDF) . Версия 6.1. Apple, Inc. 19 августа 2016 г.
  25. ^ ван Пелт, Крис. «Logius: проблема доверия CA правительства Нидерландов» . Багзилла . Проверено 31 октября 2017 г.
  26. ^ Moxie Marlinspike (2009). «Больше трюков для победы над SSL на практике» (PDF) . Institute For Disruptive Studies. Blackhat . Получено 10 сентября 2020 г. .
  27. ^ Рекомендация МСЭ-Т X.690, пункт 8.19.2
  28. ^ Дэн Камински (29 декабря 2009 г.). "26C3: Black Ops Of PKI". Блог событий CCC . Der Chaos Computer Club . Получено 29 сентября 2013 г.
  29. ^ Lenstra, Arjen; de Weger, Benne (19 мая 2005 г.). О возможности построения значимых хэш-коллизий для открытых ключей (PDF) (Технический отчет). Lucent Technologies, Bell Laboratories & Technische Universiteit Eindhoven. Архивировано (PDF) из оригинала 14 мая 2013 г. . Получено 28 сентября 2013 г. .
  30. ^ "MD5 сегодня считается вредным". Технический университет Эйндховена. 16 июня 2011 г. Получено 29 сентября 2013 г.
  31. ^ "Eurocrypt 2009". Международная ассоциация криптологических исследований.
  32. ^ Кэмерон Макдональд; Филип Хоукс; Йозеф Пиепшик (2009). "SHA-1 collisions now" (PDF) . Университет Маккуори и Qualcomm . Получено 10 сентября 2020 г. .
  33. ^ Деннис Дуайер (2 июня 2009 г.). «SHA-1 Collision Attacks Now 252». SecureWorks Insights . Получено 24 февраля 2016 г. .
  34. ^ Марк Стивенс; Эли Бурштейн; Пьер Карпман; Анж Альбертини; Ярик Марков. «Первое столкновение для полного SHA-1» (PDF) . CWI Amsterdam и Google Research . Получено 10 сентября 2020 г. – через Shattered.
  35. ^ "Документы базовых требований". Форум CA Browser . Получено 19 марта 2017 г.
  36. ^ Эндрю Уолли (16 ноября 2016 г.). «Сертификаты SHA-1 в Chrome». Блог Google Online Security . Получено 19 марта 2017 г.
  37. ^ "Конец SHA-1 в публичной сети". Блог безопасности Mozilla . 23 февраля 2017 г. Получено 19 марта 2017 г.
  38. ^ "Microsoft Security Advisory 4010323". Technet . Microsoft . Получено 16 мая 2017 г. .
  39. ^ «Safari и WebKit не поддерживают сертификаты SHA-1». Поддержка Apple . 16 августа 2018 г. Получено 10 сентября 2020 г.
  40. ^ Дэниел Стенбург (10 января 2017 г.). «Lesser HTTPS for non-browsers». Дэниел Хакс . Получено 19 марта 2017 г.
  41. ^ B Kaliski (март 1998 г.). PKCS #7: Cryptographic Message Syntax Version 1.5. Сетевая рабочая группа. doi : 10.17487/RFC2315 . RFC 2315. Информационный.
  42. ^ T. Dierks; E. Rescorla (август 2008 г.). Протокол Transport Layer Security (TLS) версии 1.2. Рабочая группа IETF TLS. doi : 10.17487/RFC5246 . RFC 5246. Устарело. Устарело из-за RFC 8446; делает устаревшими RFC 3268, 4346 и 4366; обновляет RFC 4492.
  43. ^ Стефан Сантессон; Майкл Майерс; Рич Анки; Слава Гальперин; Карлайл Адамс (июнь 2013 г.). Протокол статуса сертификата онлайн-инфраструктуры открытых ключей Интернета X.509 — OCSP. Инженерная группа Интернета (IETF). doi : 10.17487/RFC6960 . RFC 6960. Предложенный стандарт. Обновлен RFC 8954. Отменяет RFC 6277 и 2560. Обновляет RFC 5912.
  44. ^ "PKCS 12: Personal Information Exchange Syntax Standard". EMC.com . RSA Laboratories. Архивировано из оригинала 6 июля 2017 г. Получено 19 марта 2017 г.
  45. ^ "Public-Key Infrastructure (X.509) (pkix) - Charter". IETF Datatracker . Internet Engineering Task Force . Получено 1 октября 2013 г.
  46. ^ "Pkix Status Pages". Инструменты IETF . Получено 10 марта 2017 г.
  47. ^ "Как создать SSH CA для проверки хостов и клиентов с Ubuntu". DigitalOcean . Получено 19 марта 2017 г.

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