X. 509

Материал из wikixw
Перейти к навигации Перейти к поиску

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

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

X. 509 определяется сектором стандартизации Международного союза электросвязи (МСЭ-Т) и основывается на ASN.1, другой стандарт ITU-T.

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

X. 509 был первоначально выпущен 3 июля 1988 и был начат в связи со стандартом X. 500. Она предполагает строгую иерархическую систему центров сертификации (ЦС) для выдачи сертификатов. Это контрастирует с моделями Web of trust, такими как PGP , где любой человек (а не только специальные ЦС) может подписывать и, таким образом, подтверждать действительность сертификатов чужих ключей. Версия 3 X. 509 включает гибкость для того чтобы поддержать другие топологии как мосты и сетки . это может использоваться в одноранговой, подобной OpenPGP сети доверия, [ цитата, необходимая] но редко использовался таким образом с 2004 года. Система X. 500 была внедрена суверенными государствами только для целей выполнения Договора о совместном использовании государственной идентификационной информации, а инфраструктура открытого ключа IETF (X. 509) или рабочая группа PKIX адаптировала стандарт к более гибкой организации Интернета. Фактически, термин сертификат X. 509 обычно относится к сертификату PKIX IETF и профилю CRL стандарта сертификата X. 509 v3, как определено в RFC 5280 , обычно называемом Pkix для инфраструктуры открытого ключа (X. 509) .[ цитата необходима]

Сертификаты[править]

В системе X. 509 организация, которая хочет подписанный сертификат, запрашивает один через запрос подписи сертификата (CSR).

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

Центр сертификации выдает сертификат, связывающий открытый ключ с определенным отличительным именем .

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

X. 509 и RFC 5280 также включают стандарты для реализаций списка отзыва сертификатов (CRL). Другим утвержденным IETF способом проверки действительности сертификата является протокол состояния сертификата (OCSP). Firefox 3 включает проверку OCSP по умолчанию, как и версии Windows, по крайней мере, с Vista и более поздних версий.

Структура сертификата[править]

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

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

  • Сертификат
    • номер версии
  • серийный номер
  • Идентификатор алгоритма подписи
  • Имя Эмитента
  • Срок действия
    • Не Раньше.
  • Не После
  • Имя субъекта
  • Информация Об Открытом Ключе Субъекта
    • Алгоритм Открытого Ключа
  • Тема Открытого Ключа
  • Уникальный идентификатор эмитента (необязательно)
  • Уникальный идентификатор субъекта (необязательно)
  • Расширения (необязательно)
           ...
  • Алгоритм Подписи Сертификата
  • Подпись Сертификата

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

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

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

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

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

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

  • Основные Ограничения, { id-ce 19 } , [6] используются, чтобы указать, принадлежит ли сертификат CA.
  • Использование ключа, { id-ce 15 }, [7] предоставляет битовую карту, определяющую криптографические операции, которые могут быть выполнены, используя открытый ключ, содержащийся в сертификате; например, это могло указать, что ключ должен использоваться для подписей, но не для шифрования.
  • Расширенное использование ключа, { id-ce 37 }, [8] используется, как правило, на сертификате листа, чтобы указать цель открытого ключа, содержащегося в сертификате. Он содержит список OIDs, каждый из которых указывает на разрешенное использование. Например, { id-pkix 3 1 } указывает, что ключ может использоваться на стороне сервера соединения TLS или SSL; { id-pkix 3 4 } указывает, что ключ может использоваться для защиты электронной почты.

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

Расширения имени файла сертификата[править]

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

  • .PEM-(конфиденциальность-enhanced электронная почта ) base64 encoded DER certificate, заключенный между "- - - - - начать сертификат - - - - - " и " - - - - - конец сертификат-----"
  • .cer,.ЭЛТ,.der-обычно в двоичной форме DER ,но сертификаты с кодировкой Base64 также распространены (см.pem выше)
  • .p7b, .p7c-PKCS#7 SignedData структура без данных, только сертификат(ы) или CRL (Ы)
  • .p12-PKCS#12, может содержать сертификаты (открытые) и закрытые ключи (защищенные паролем)
  • .pfx-PFX, предшественник PKCS#12 (обычно содержит данные в формате PKCS#12, например, с файлами PFX, сгенерированными в IIS)

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

PKCS#12 эволюционировал от стандарта обмена личной информацией (PFX) и используется для обмена публичными и частными объектами в одном файле. Цепи сертификатов и перекрестная сертификация

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

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

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

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

Пример 1. перекрестная сертификация между двумя ПКП

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

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

На этой диаграмме:

  • Каждая ячейка представляет собой сертификат, тема которого выделена жирным шрифтом.
  • A → B означает " a подписывается B "(или, точнее,"a подписывается секретным ключом, соответствующим открытому ключу, содержащемуся в B").
  • Сертификаты одного цвета (не белые/прозрачные) содержат один и тот же открытый ключ.

Пример 1: перекрестная сертификация на уровне корневого Центра сертификации (CA) между двумя PKI[править]

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

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

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

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

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

Это пример декодированного сертификата X. 509, который использовался wikipedia.org и несколько других сайтов Википедии. Он был выпущен GlobalSign, как указано в поле эмитента. Его поле темы описывает Википедию как организацию, а поле альтернативного имени темы описывает имена хостов, для которых оно может быть использовано. Поле 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=Фонд Викимедиа, 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:
9d: 3b: ef
ASN1 OID: prime256v1
КРИВАЯ NIST: P-256
Расширения X509v3:
Использование ключа X509v3: критическое
Цифровая Подпись, Ключевое Соглашение
Доступ К Информации О Полномочиях: 
Эмитенты ЦС-URI: http: / / secure.глобалсин.com/cacert / gsorganizationvalsha2g2r1.ЭЛТ
OCSP-URI: http: / / ocsp2.глобалсин.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 Основные Ограничения: 
CA: FALSE
X509v3 точки распространения CRL: 
фамилия, имя, отчество:
URI: http: / / crl.глобалсин.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: 
keyid: 96: DE: 61: F1:BD: 1C: 16: 29: 53: 1C: C0:CC: 7D: 3B: 83: 00: 40: E6: 1A: 7C

Алгоритм подписи: sha256WithRSAEncryption
8b: c3: ed:d1: 9d: 39:6f: af: 40: 72: bd: 1e: 18: 5e: 30: 54: 23: 35:
...

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

Эмитент C=BE, O=GlobalSign nv-sa, CN=проверка организации GlobalSign CA-SHA256-G2
Идентификатор Ключа Полномочий 96:DE:61:F1:BD:1C:16:29:53:1C:C0:CC:7D:3B:83:00: 40: E6: 1A: 7C

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

Промежуточный сертификат[править]

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

Сертификат: 

Данные:
Версия: 3 (0x2)
серийный номер:
04:00:00:00:00:01:44:4e: f0: 42: 47
Алгоритм подписи: sha256WithRSAEncryption
Издатель: C=BE, O=GlobalSign nv-sa, OU=Root CA, CN=GlobalSign Root CA
Обоснованность
Не раньше: 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/

X509v3 точки распространения CRL:

фамилия, имя, отчество:
URI: http: / / crl.глобалсин.net / root.crl

Доступ К Информации О Полномочиях:
OCSP-URI: http: / / ocsp.глобалсин.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. В противном случае сертификат конечного объекта считается ненадежным.

Свидетельство: 

Данные:
Версия: 3 (0x2)
серийный номер:
04:00:00:00:00:01:15:4b: 5a: c3: 94
Алгоритм подписи: sha1WithRSAEncryption
Издатель: C=BE, O=GlobalSign nv-sa, OU=Root CA, CN=GlobalSign Root CA
Обоснованность
Не раньше: 1 сентября 12: 00: 00 1998 GMT
Не после: 28 января 12: 00: 00 2028 GMT
Тема: C=BE, O=GlobalSign nv-sa, OU=Root CA, CN=GlobalSign Root CA
Информация Об Открытом Ключе Субъекта:
Алгоритм открытого ключа: rsaEncryption
Открытый ключ: (2048 бит)
Модуль:
00: da: 0e: e6: 99:8d:ce: A3: e3: 4f: 8a: 7e:fb: f1: 8b:
...
Экспонента: 65537 (0x10001)
Расширения X509v3:
Использование ключа X509v3: критическое
Знак сертификата, знак CRL
X509v3 Основные Ограничения: критические
CA: ПРАВДА
Идентификатор Ключа Субъекта 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 Брюса Шнайера, Питера Гутмана и других экспертов по безопасности.

Архитектурные слабости[править]

  • Использование недопустимых сертификатов черного списка (с использованием CRL и OCSP),
  • Если клиент доверяет сертификатам только при наличии списков отзыва сертификатов, они теряют автономную возможность, которая делает PKI привлекательным. Таким образом, большинство клиентов доверяют сертификатам, когда CRL недоступны, но в этом случае злоумышленник, контролирующий канал связи, может отключить CRL. Адам Лэнгли из Google сказал, что проверки CRL с мягким отказом похожи на ремень безопасности, который работает, за исключением случаев, когда вы попадаете в аварию.
  • CRL-особенно плохой выбор из-за больших размеров и запутанных образцов распределения,
  • Неоднозначная семантика OCSP и отсутствие исторического статуса отзыва,
  • Отзыв корневых сертификатов не рассматривается,
  • Проблема агрегации: утверждения идентификации (проверка подлинности с помощью идентификатора), утверждения атрибутов (отправка пакета проверенных атрибутов) и утверждения политики объединяются в одном контейнере. Это вызывает вопросы конфиденциальности, сопоставления политик и обслуживания.[ требуется разъяснение]
  • Проблема делегирования: ЦС не может технически ограничить выдачу сертификатов подчиненными ЦС вне ограниченных пространств имен или набора атрибутов; эта функция X. 509 не используется. Поэтому в интернете существует большое количество ЦС, и классифицировать их и их политику является непреодолимой задачей. Делегирование полномочий внутри организации вообще не может осуществляться, как в обычной деловой практике.
  • Проблема Федерации: цепочки сертификатов, которые являются результатом подчиненных ЦС, ЦС моста и перекрестной подписи, делают проверку сложной и дорогостоящей с точки зрения времени обработки. Семантика проверки пути может быть неоднозначной. Иерархия со сторонней доверенной стороной является единственной моделью. Это неудобно, когда двусторонние доверительные отношения уже существуют.
  • Выдача сертификата расширенной проверки (EV) для имени хоста не предотвращает выдачу сертификата более низкой проверки, действительного для того же имени хоста, что означает, что более высокий уровень проверки EV не защищает от атак "человек в середине".

Проблемы с центрами сертификации[править]

  • Субъект, а не проверяющая сторона, приобретает сертификаты. Субъект часто использует самого дешевого эмитента, поэтому качество не оплачивается на конкурирующем рынке. Это частично решается с помощью расширенных сертификатов проверки, но значение доверия в глазах экспертов по безопасности уменьшается.
  • Сертификационные органы отказывают почти во всех гарантиях пользователю (включая субъекта или даже проверяющих сторон).
  • Срок годности должен использоваться для ограничения времени, в течение которого сила ключа считается достаточной [ сомнительная – обсудить ] . Этот параметр злоупотребляется органами по сертификации, чтобы взимать с клиента плату за продление . Это возлагает ненужную нагрузку на пользователя с помощью опрокидывания ключа .
  • "Пользователи используют неопределенный протокол запроса сертификации для получения сертификата, который публикуется в неясном месте в несуществующем каталоге без реальных средств для его отзыва."
  • Как и все предприятия, CAs подчиняются правовым юрисдикциям, в которых они работают, и могут быть юридически вынуждены компрометировать интересы своих клиентов и их пользователей. Разведывательные агентства также использовали ложные сертификаты, выданные через внеправовой компромисс CAs , такие как DigiNotar, для проведения атак "человек в середине". другой пример-запрос об отзыве CA голландского правительства из-за нового голландского закона, становящегося активным начиная с 1 января 2018, давая новые полномочия голландским разведывательным службам и службам безопасности.

Проблемы реализации[править]

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

  • Многие реализации отключают проверку отзыва:
    • Рассматриваемая как препятствие, политика не применяется
  • Если бы это было включено во всех браузерах по умолчанию, включая подпись кода, это, вероятно, разрушило бы инфраструктуру]
  • DNs сложны и мало понятны (отсутствие канонизации, проблемы интернационализации, ..)
  • rfc822Name имеет две нотации
  • Ограничения имени и политики вряд ли поддерживаются
  • Использование ключа игнорируется, используется первый сертификат в списке
  • Обеспечение соблюдения таможенных OIDs трудно
  • Атрибуты не должны быть сделаны критическими, потому что это заставляет клиентов терпеть крах]
  • Неопределенная длина атрибутов приводит к ограничениям для конкретного продукта
  • Существуют ошибки реализации с X. 509, которые позволяют, например, фальсифицировать имена субъектов, используя строки с нулевым завершением [22] или атаки на инъекцию кода в сертификатах.
  • Используя недопустимые 0x80 дополненные подидентификаторы идентификаторов объектов , неправильные реализации или используя целочисленные переполнения браузеров клиента, злоумышленник может включить неизвестный атрибут в CSR, который будет подписан CA, который клиент неправильно интерпретирует как "CN" (OID=2.5.4.3). Дэн Каминский на 26 - м Конгрессе связи Хаоса "Black OPs of PKI"

Криптографические слабости[править]

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

  • Сертификаты на основе MD2 использовались в течение длительного времени и были уязвимы для атак preimage . Поскольку корневой сертификат уже имел самоподпись, злоумышленники могли использовать эту подпись и использовать ее в качестве промежуточного сертификата.
  • В 2005 году Арьен Ленстра и Бенн де Вегер продемонстрировали "как использовать хэш-коллизии для создания двух сертификатов X. 509, которые содержат идентичные подписи и отличаются только открытыми ключами", что было достигнуто с помощью атаки коллизии на хэш-функцию MD5.
  • В 2008 году Александр Сотиров и Марк Стивенс представили на Конгрессе Chaos Communication практическую атаку, которая позволила им создать центр сертификации rogue, принятый всеми распространенными браузерами, используя тот факт, что RapidSSL все еще выпускает сертификаты X. 509 на основе MD5.
  • В апреле 2009 года на конференции Eurocrypt австралийские исследователи из Университета Маккуори представили "автоматический дифференциальный путь поиска SHA-1 ". исследователи смогли вывести метод, который увеличивает вероятность столкновения на несколько порядков.
  • В феврале 2017 года группа исследователей во главе с Марком Стивенсом произвела столкновение SHA-1, продемонстрировав слабость SHA-1.

Смягчение криптографических недостатков[править]

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

По состоянию на 1 января 2016 базовые требования запрещают выдачу сертификатов с использованием SHA-1. По состоянию на начало 2017 , Chrome и Firefox отклоняют сертификаты, использующие SHA-1. По состоянию на май 2017 оба Edge и Safari [35] также отклоняют сертификат SHA-1. Валидаторы без браузера X. 509 еще не отклоняют сертификаты SHA-1.

Стандарты PKI для X. 509[править]

  • PKCS7 (Cryptographic Message Syntax Standard-открытые ключи с удостоверением личности для подписанного и / или зашифрованного сообщения для PKI).[37]
  • Безопасность транспортного уровня (TLS) и его предшественники SSL — криптографические протоколы для безопасной связи в Интернете.
  • Online Certificate Status Protocol (OCSP) / Certificate revocation list (CRL) — проверка состояния отзыва сертификата.
  • PKCS12 (Personal Information Exchange Syntax Standard) - используется для хранения закрытого ключа с соответствующим сертификатом открытого ключа.

Рабочая группа PKIX[править]

В 1995 году целевая группа по разработке интернет совместно с Национальным институтом стандартов и технологий [42] сформировала рабочую группу по инфраструктуре открытого ключа (X. 509). Рабочая группа, завершившаяся в июне 2014 года [43], обычно называется "PKIX."Была подготовлена РЧЦ и другая нормативная документация по использованию развертывания 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 для пользы в индустрии кабеля.

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

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

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

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

SSH обычно использует доверие при первом использовании модели безопасности и не нуждается в сертификатах. Однако популярная реализация OpenSSH поддерживает модель удостоверения, подписанную центром сертификации, основанную на собственном формате сертификата, отличном от X. 509.

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

Пруф[править]

/docs.microsoft.com/en-us/previous-versions/tn-archive/bb123848(v=exchg.65)

Источник — https://wikixw.ru/index.php?title=X._509&oldid=4827