Из Википедии, бесплатной энциклопедии
Перейти к навигации Перейти к поиску
X.509
Информационные технологии - Взаимодействие открытых систем - Справочник: структуры открытых ключей и сертификатов атрибутов
Положение делДействует (Рекомендация)
Впервые опубликовано1.0 от 25 ноября 1988 г . ; 32 года назад ( 1988-11-25 )
Последняя версия9.0
14 октября 2019 г . ; 16 месяцев назад ( 2019-10-14 )
ОрганизацияITU-T
Комитет17-я Исследовательская комиссия МСЭ-Т
СерииИкс
Базовые стандартыASN.1
Связанные стандартыИСО / МЭК 9594-8: 2020, X.500
ДоменКриптография
Интернет сайтWWW .itu .int / REC / T-Rec-X 0,509

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  • .pem - ( Электронная почта с повышенной секретностью ) сертификат DER в кодировке Base64 , заключенный между "----- BEGIN CERTIFICATE -----" и "----- END CERTIFICATE -----"
  • .cer , .crt , .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 ) [12] представляет собой список сертификатов (обычно начиная с сертификата конечного объекта) с последующим одним или более CA сертификатов ( как правило , последний из которых будучи самозаверяющий сертификат) со следующими свойствами:

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

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

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

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

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

Примеры [ править ]

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

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

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

Для управления тем, что сертификаты пользователей, существующие в PKI 2 (например, «Пользователь 2»), являются доверенными для PKI 1, 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 [ править ]

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

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

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

Это пример декодированного сертификата X.509, который использовался wikipedia.org и несколькими другими веб-сайтами Википедии. Он был выпущен GlobalSign , как указано в поле «Эмитент». Его поле «Тема» описывает Википедию как организацию, а поле «Альтернативное имя субъекта» описывает имена хостов, для которых он может использоваться. Поле «Информация об открытом ключе субъекта» содержит открытый ключ 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 Organization Validation CA - SHA256 - G2 Срок действия Не раньше: 21 ноября, 08:00:00 2016 г., GMT Не после: 22 ноября, 07:59:59 2017 г. по Гринвичу Тема: 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: 9d: 3b: ef OID ASN1: prime256v1 КРИВАЯ NIST: P-256 Расширения X509v3: X509v3 Использование ключа: критическое Цифровая подпись, ключевое соглашение Доступ к информации о полномочиях:  Эмитенты ЦС - 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:  CA: FALSE Точки распространения 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:  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 = CA для проверки организации GlobalSign - 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» из сертификата конечного объекта.

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

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

Сертификат: Данные: Версия: 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 г. по Гринвичу Не после: 20 февраля 10:00:00 2024 по Гринвичу Тема: C = BE, O = GlobalSign nv-sa, CN = GlobalSign Organization Validation 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: ИСТИНА, 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 = Root CA, CN = GlobalSign Root CA Срок действия Не раньше: 1 сентября 12:00:00 1998 GMT Не после: 28 января 12:00:00 2028 по Гринвичу Тема: 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 Основные ограничения: критические 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 . [17] [18] [19]

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

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

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

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

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

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

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

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

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

  • Сертификаты на основе MD2 использовались долгое время и были уязвимы для атак по прообразу . Поскольку корневой сертификат уже имел самоподпись, злоумышленники могли использовать эту подпись и использовать ее для промежуточного сертификата.
  • В 2005 году Арьен Ленстра и Бенн де Вегер продемонстрировали, «как использовать хэш-коллизии для создания двух сертификатов X.509, которые содержат идентичные подписи и различаются только открытыми ключами», что было достигнуто с помощью атаки коллизий на хеш-функцию MD5 . [27]
  • В 2008 году Александр Сотиров и Марк Стивенс представили на Chaos Communication Congress практическую атаку, которая позволила им создать мошеннический центр сертификации, принятый всеми распространенными браузерами, за счет использования того факта, что RapidSSL все еще выдает сертификаты X.509 на основе MD5. [28]
  • В апреле 2009 года на конференции Eurocrypt [29] австралийские исследователи из Университета Маккуори представили «Автоматический поиск дифференциальных путей для SHA-1 ». [30] Исследователи смогли вывести метод, который увеличивает вероятность столкновения на несколько порядков. [31]
  • В феврале 2017 года группа исследователей под руководством Марка Стивенса произвела столкновение SHA-1, продемонстрировав слабость SHA-1. [32]

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

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

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

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

  • PKCS7 (стандарт синтаксиса криптографических сообщений - открытые ключи с подтверждением личности для подписанного и / или зашифрованного сообщения для PKI) [39]
  • Transport Layer Security (TLS) и его предшественник SSL - криптографические протоколы для безопасной связи в Интернете. [40]
  • Online Certificate Status Protocol (OCSP) [41] / список отзыва сертификатов (CRL) [42]  - это для проверки статуса отзыва сертификата.
  • PKCS12 (стандарт синтаксиса обмена личной информацией) - используется для хранения закрытого ключа с соответствующим сертификатом открытого ключа [43]

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

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

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

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

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

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

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

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

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

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

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

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

  • Первая абстрактная синтаксическая нотация
  • Политика сертификатов
  • Безопасность доступа кода
  • Безопасность связи
  • Информационная безопасность
  • ISO / IEC JTC 1
  • Протокол запросов к ресурсам PKI
  • Криптография с открытым ключом
  • Протокол отметки времени
  • Надежная отметка времени
  • EdDSA

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

  1. ^ «X.509: Информационные технологии - Взаимодействие открытых систем - Справочник: структуры открытых ключей и сертификатов атрибутов» . ITU . Дата обращения 6 ноября 2019 .
  2. ^ a b RFC 4158
  3. ^ «Сертификат инфраструктуры открытого ключа Internet X.509 и профиль отзыва сертификатов (CRL)» . Май 2008 . Дата обращения 29 мая 2020 . Ниже приведен упрощенный вид архитектурной модели, принятой инфраструктурой открытого ключа с использованием спецификаций X.509 (PKIX).
  4. ^ "CA: IncludedCAs" . Mozilla Wiki . Проверено 17 января 2017 года .
  5. ^ «Ошибка 110161 - (ocspdefault) включить OCSP по умолчанию» . Mozilla . Проверено 17 марта 2016 года .
  6. ^ "RFC 5280 раздел 4.2" . Инструменты . IETF. Май 2008 . Проверено 12 февраля 2013 года .
  7. ^ RFC 1422
  8. ^ «RFC 5280, раздел« Основные ограничения » » .
  9. ^ " ' RFC 5280, раздел" Использование ключей " " .
  10. ^ «RFC 5280, раздел« Расширенное использование ключа » » .
  11. ↑ Нельсон Б. Боярд (9 мая 2002 г.). «Все о расширениях сертификатов» . Mozilla . Дата обращения 10 сентября 2020 .
  12. ^ a b «Подтверждение пути сертификации». Сертификат инфраструктуры открытых ключей Internet X.509 и профиль отзыва сертификатов (CRL) . Сетевая рабочая группа. 2008 г.
  13. ^ Ллойд, Стив (сентябрь 2002 г.). Общие сведения о построении пути сертификации (PDF) . Форум PKI.
  14. ^ «Перекрестная сертификация между корневыми центрами сертификации». Сценарии развертывания квалифицированного подчинения . Microsoft. Август 2009 г.
  15. ^ Нэш; Дуэйн; Джозеф; Бринк (2001). «Жизненные циклы ключей и сертификатов. Продление сертификата ЦС». PKI: внедрение и управление электронной безопасностью . RSA Press - Осборн / Макгроу-Хилл. ISBN 0-07-213123-3.
  16. ^ a b «Безопасность веб-служб X.509 Token Profile Version 1.1.1» . Оазис . Проверено 14 марта 2017 года .
  17. ^ Карл Эллисон и Брюс Шнайер. «10 основных рисков PKI» (PDF) . Журнал компьютерной безопасности (том XVI, номер 1, 2000 г.).
  18. ^ Питер Гутманн. «PKI: он не мертв, просто отдыхает» (PDF) . IEEE Computer (том: 35, выпуск: 8).
  19. ^ a b Гутманн, Питер. «Все, что вы никогда не хотели знать о PKI, но были вынуждены узнать» (PDF) . Проверено 14 ноября 2011 года .
  20. ↑ Лэнгли, Адам (5 февраля 2012 г.). «Проверка отзыва и CRL Chrome» . Императорский фиолетовый . Дата обращения 2 февраля 2017 .
  21. ^ Майкл Зусман; Александр Сотиров (июль 2009 г.). «Sub-Prime PKI: Атака на SSL с расширенной проверкой» (PDF) . Blackhat . Дата обращения 10 сентября 2020 .
  22. ^ Хант, Трой. «Сертификаты расширенной проверки мертвы» . TroyHunt.com . Проверено 26 февраля 2019 .
  23. ^ Ван Пелт, Крис. "Logius: проблема доверия правительства Нидерландов к CA" . Bugzilla . Проверено 31 октября 2017 года .
  24. ^ Мокси Марлинспайк (2009). «Дополнительные приемы для определения SSL на практике» (PDF) . Институт подрывных исследований. Blackhat . Дата обращения 10 сентября 2020 .
  25. ^ Рек. МСЭ-T X.690, пункт 8.19.2
  26. ↑ Дэн Камински (29 декабря 2009 г.). «26C3: Black Ops Of PKI» . Блог событий CCC . Компьютерный клуб Der Chaos . Проверено 29 сентября 2013 года .
  27. ^ Ленстра, Арьен; де Вегер, Бенн (19 мая 2005 г.). О возможности построения значимых хеш-коллизий для открытых ключей (PDF) (Технический отчет). Lucent Technologies, Bell Laboratories и Технический университет Эйндховена. Архивировано 14 мая 2013 года (PDF) из оригинала . Проверено 28 сентября 2013 года .
  28. ^ «MD5 сегодня считается вредным» . Эйндховенский технологический университет. 16 июня 2011 . Проверено 29 сентября 2013 года .
  29. ^ «Eurocrypt 2009» . Международная ассоциация криптологических исследований.
  30. ^ Кэмерон Макдональд; Филип Хоукс; Йозеф Пиепшик (2009). «Коллизии SHA-1 сейчас» (PDF) . Университет Маккуори и Qualcomm . Дата обращения 10 сентября 2020 .
  31. ↑ Деннис Двайер (2 июня 2009 г.). «Коллизионные атаки SHA-1 теперь 252» . SecureWorks Insights . Проверено 24 февраля +2016 .
  32. ^ Марк Стивенс; Эли Бурштейн; Пьер Карпман; Анж Альбертини; Ярик Марков. «Первая коллизия для полного SHA-1» (PDF) . CWI Amsterdam и Google Research . Проверено 10 сентября 2020 года - через Shattered.
  33. ^ «Документы с базовыми требованиями» . CA Browser Forum . Проверено 19 марта 2017 года .
  34. ↑ Эндрю Уолли (16 ноября 2016 г.). «Сертификаты SHA-1 в Chrome» . Блог Google Online Security . Проверено 19 марта 2017 года .
  35. ^ «Конец SHA-1 в общедоступной сети» . Блог о безопасности Mozilla . Проверено 19 марта 2017 года .
  36. ^ "Рекомендации по безопасности Microsoft 4010323" . Technet . Microsoft . Дата обращения 16 мая 2017 .
  37. ^ «Safari и WebKit не поддерживают сертификаты SHA-1» . Служба поддержки Apple . 16 августа 2018 . Дата обращения 10 сентября 2020 .
  38. ^ Даниэль Стенбург (10 января 2017 г.). «Меньший HTTPS для не браузеров» . Дэниел Хакс . Проверено 19 марта 2017 года .
  39. ^ B Kaliski (март 1998). «PKCS # 7: версия 1.5 синтаксиса криптографических сообщений» . IETF . Дата обращения 10 сентября 2020 .
  40. ↑ Т. Диркс (август 2008 г.). «Протокол безопасности транспортного уровня (TLS) версии 1.2» . IETF . Дата обращения 10 сентября 2020 .
  41. ^ Стефан Сантессон; Майкл Майерс; Богатый Анки; Слава Гальперин; Карлайл Адамс (июнь 2013 г.). «Протокол статуса сертификата Интернет-инфраструктуры открытых ключей X.509 - OCSP» . Инструменты . IETF . Дата обращения 10 сентября 2020 .
  42. ↑ Дэвид Купер; Стефан Сантессон; Стивен Фаррелл; Шарон Бойен; Рассел Хаусли; Тим Полк (май 2008 г.). «Сертификат инфраструктуры открытых ключей Internet X.509 и профиль отзыва сертификатов (CRL)» . Инструменты . IETF . Дата обращения 10 сентября 2020 .
  43. ^ «PKCS 12: стандарт синтаксиса обмена личной информацией» . EMC.com . RSA Laboratories . Проверено 19 марта 2017 года .[ мертвая ссылка ]
  44. ^ «Инфраструктура открытых ключей (X.509) (pkix) - Устав» . IETF Datatracker . Инженерная группа Интернета . Проверено 1 октября 2013 года .
  45. ^ "Страницы состояния Pkix" . Инструменты IETF . Проверено 10 марта 2017 года .
  46. ^ «Как создать SSH CA для проверки хостов и клиентов с Ubuntu» . DigitalOcean . Проверено 19 марта 2017 года .

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

  • Стандарты ITU-T X.509
  • Статьи Питера Гутмана:
    • Обзор PKI
    • Замечания по реализации и руководство по стилю X.509
  • «Часто задаваемые вопросы о криптографии от RSA Labs» . RSA Laboratories. Архивировано из оригинала 30 декабря 2006 года.
  • Правила безопасного кода Sun
  • RFC 4158 - Инфраструктура открытых ключей Internet X.509: построение пути сертификации
  • CSR Decoder и Certificate Decoder - могут использоваться для декодирования и проверки закодированного CSR или сертификата.
  • phpseclib: X.509 Decoder - декодирует в ассоциативный массив, ключи которого соответствуют описанию X.509 ASN.1
  • SeSeLe , Мастер самозаверяющих SSL-сертификатов
  • Общие сведения о цифровых сертификатах Microsoft TechNet