X.509

Материал из Википедии — свободной энциклопедии
Текущая версия страницы пока не проверялась опытными участниками и может значительно отличаться от версии, проверенной 23 мая 2022 года; проверки требуют 3 правки.
Перейти к навигации Перейти к поиску

X.509 — стандарт ITU-T для инфраструктуры открытого ключа (англ. Public key infrastructure, PKI) и инфраструктуры управления привилегиями (англ. Privilege Management Infrastructure)[1].

X.509 определяет стандартные форматы данных и процедуры распределения открытых ключей с помощью соответствующих сертификатов с цифровыми подписями➤. Эти сертификаты предоставляются удостоверяющими центрами (англ. Certificate Authority). Кроме того, X.509 определяет формат списка аннулированных сертификатов[англ.], ➤, формат сертификатов атрибутов[англ.] и алгоритм проверки подписи путём построения пути сертификации[англ.]. X.509 предполагает наличие иерархической системы удостоверяющих центров➤ для выдачи сертификатов.

История

[править | править код]

По мере развития телекоммуникационных технологий, в частности, сети Интернет, стала актуальной задача обеспечения безопасного доступа пользователей к информационным ресурсам, позволяющая избежать криптографической атаки «человек посередине». Одним из способов её решения является механизм сертификации участников информационного обмена. С целью обеспечения функциональной совместимости различных программно-аппаратных продуктов (средств криптографической защиты информации), использующихся в таких прикладных сервисах (WWW, электронная почта, системы аутентификации пользователей и др.) был создан стандарт, описывающий формат сертификатов, который был впервые опубликован ITU-T в 1988 году в качестве части рекомендаций X.500 (RFC 5280)[2]. Это был X.509 v1. В 1993 году в описание стандарта сертификатов добавили 2 поля, что привело к появлению X.509 v2, а ещё несколько позже появилась третья версия стандарта — X.509 v3➤.

Вопросами реализации стандарта в сети Интернет занимается рабочая группа IETF, сформированная в 1995 году и более известная как Public-Key Infrastructure (X.509) working group (PKIX). Результатами её работы, в частности, стали рекомендации RFC 3280 и 5280[3].

X.509 стал основой для построения иерархической системы удостоверяющих центров➤, несмотря на появление в 1991 году технологии PGP. Стандарт поддерживается в таких протоколах и механизмах как TLS / SSL, HTTPS, IPsec, SSH и других.

Описание

[править | править код]

Согласно RFC 1422, стандарт X.509 определяет понятие «сертификат с открытом ключом» и другие базовые определения PKIX. При этом сертификат с открытым ключом представляет собой определённую структуру данных, которая содержит имя пользователя, открытую составляющую (англ. Public Component) ключа двухключевой криптосистемы этого пользователя и имя компании (далее — «издатель»), который подтверждает, что открытая составляющая привязана к имени пользователя. Эти данные через каждый временной интервал подписываются эмитентом. В сертификатах имена субъекта и издателя являются различимыми именами (англ. Distinguished Names), как определено в системном каталоге Х.500.

После подписания сертификаты могут храниться на LDAP-серверах. Передаются сертификаты через незащищённые обменные сообщения или через любое другое средство, которое делает сертификаты легко доступными при отправке сообщений пользователям. Сертификаты используются в PEM-кодировке, чтобы обеспечить отправителя подлинной открытой составляющей каждого получателя, а также чтобы обеспечить каждого получателя подлинной открытой составляющей отправителя.

Открытый ключ в PKI привязан к конкретной личности пользователя в так называемом цифровом сертификате, которым может быть, например, сертификат X.509[4]. Согласно RFC 347, основными компонентами эффективной PKI являются:

Для технологии открытых ключей необходимо, чтобы пользователь открытого ключа был уверен, что этот ключ принадлежит именно тому удалённому субъекту (пользователю или системе), который будет использовать средства шифрования или цифровой подписи. Такую уверенность дают сертификаты открытых ключей. Сертификат имеет ограниченный срок действия. Поскольку пользователь сертификата может самостоятельно проверить его подпись и срок действия, сертификаты могут распространяться через незащищённые каналы связи и серверные системы, а также храниться в кэш-памяти незащищённых пользовательских систем. В настоящее время в этой области предлагается следующий общий стандарт для всемирной сети с использованием X.509 v3:

Структура сертификата X.509

[править | править код]
Общий стандарт для интернета, использующий формат X.509
  • Сертификат
    • Версия
    • Серийный номер
    • Идентификатор алгоритма подписи
    • Имя издателя
    • Период действия:
      • Не ранее
      • Не позднее
    • Имя субъекта
    • Информация об открытом ключе субъекта:
      • Алгоритм открытого ключа
      • Открытый ключ субъекта
    • Уникальный идентификатор издателя (обязательно только для v2 и v3)
    • Уникальный идентификатор субъекта (обязательно только для v2 и v3)
    • Дополнения (для v2 и v3)
      • Возможные дополнительные детали
  • Алгоритм подписи сертификата (обязательно только для v3)
  • Подпись сертификата[5] (обязательно для всех версий)

В 4 разделе RFC 2459 описана структура сертификата X.509 v3. Обновленная структура сертификата X.509 v3 описана в документе RFC 5280 в 4 разделе. Она специализирована под интернет-приложения.

Для описания внутренней структуры сертификатов X.509 используется ASN.1. Хранятся, как правило, в виде DER или PEM-файлов. Общепринятое расширение .cer или .crt. Может быть и другое расширение➤.

Особенности

[править | править код]

Для выпуска сертификатов существует четко определённая иерархическая система удостоверяющих центров (далее — УЦ)➤, согласно RFC 5280. В этом его отличие от моделей, основанных на принципе сети доверия (англ. Web of trust), подобной криптографической технологии PGP, где любой (не только УЦ) может выпускать, подписывать и проверять на соответствие сертификат. Согласно RFC 4158, X.509 v3 обладает гибкостью для поддержки таких топологий как мосты (англ. bridges) и сетки (англ. meshes), а также может быть использован в p2p сетях.

Добавлены расширения и особенность критичности для X.509 в 1995 году[6].

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

Иерархическая PKI

[править | править код]

Согласно RFC 4387, суть PKI следующая: в браузере хранятся не сертификаты сайтов, а сертификаты УЦ. Это означает, что когда ваш браузер получает сертификат сайта при установке соединения, он видит помимо адреса сайта ещё и «адрес» УЦ, а также цифровую подпись, которую сгенерировал УЦ с использованием своего секретного ключа. Дальше браузер берёт из локального хранилища цепь сертификатов УЦ, достаёт из него публичный ключ и с помощью него проверяет подпись в сертификате сайта. Если подпись правильная, соединение успешно устанавливается.

Согласно RFC 5280, цепь сертификатов представляет собой список сертификатов (начиная с лица, удостоверенного в качестве сервера), включающий один или несколько УЦ (последний подписывается самим собой), обладает следующими свойствами:

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

Иерархические PKI способны быстро реагировать на компрометацию отдельного УЦ внутри инфраструктуры. Если УЦ скомпрометирован, вышестоящий УЦ просто аннулирует его сертификат. Как только работа УЦ восстанавливается, он выпускает новые сертификаты для всех своих пользователей. Вышестоящий УЦ выпускает для скомпрометированного УЦ новый сертификат с новым открытым ключом, что позволяет вернуть этот центр обратно в иерархию.

Общеупотребительные расширения файлов сертификатов

[править | править код]
  • .der — сертификат, закодированный по стандарту DER. Устаревший и больше не используется.
  • .pem — DER-сертификат, закодированный в Base64 и помещенный между -----BEGIN CERTIFICATE----- и -----END CERTIFICATE-----.
  • .cer, .crt — сертификат, или набор сертификатов. Обычно закодирован в PEM но может быть и DER.
  • .p8, .p8e, .pk8 — приватный ключ в формате PKCS #8. Может быть в DER или PEM формате который начинается с -----BEGIN PRIVATE KEY-----. Зашифрованный ключ начинается с -----BEGIN ENCRYPTED PRIVATE KEY----- и может иметь расширение файла .p8e.
  • .p10, .csr – PKCS#10 Certificate Signing Request (CSR). Ответ на него приходит обычно в файле .p7r.
  • .p7r — PKCS #7 ответ на CSR. Содержит только что подписанный сертификат, и сертификат ЦА.
  • .p7s — PKCS#7 цифровая подпись. Может содержать изначальный файл или сообщение. Используется в S/MIME для подписи email писем. Специфицирован в RFC 2311.
  • .p7m - PKCS#7 (SignedData, EnvelopedData) Зашифрованный файл, сообщение, или MIME email письмо. Специфицирован в RFC 2311.
  • .p7c - PKCS#7 (degenerated SignedData) только сертификаты, без каких либо данных для подписи. Специфицирован в RFC 2311.
  • .p7b, .keystore (SignedData) содержит несколько сертификатов и/или CRL.
  • .p12, .pfx, .pkcs12 — PKCS #12 содержит блок, хранящий одновременно и закрытый ключ, и сертификат (в зашифрованном виде). .pfx — PFX, предшественник PKCS #12.
  • .crl - Certificate Revocation List (CRL). ЦА публикуют такие файлы чтобы деавторизировать сертификаты до истечения их срока действия.

Список аннулированных сертификатов (CRL)

[править | править код]
Основная статья: Certificate Revocation List

Согласно RFC 3280, CRL подписывается удостоверяющим центром и свободно распространяется через общедоступный репозиторий сертификатов. Репозиторий сертификатов обычно размещается на сервере каталогов в соответствии с международным стандартом X.500 и его подмножеством. В списке CRL каждый аннулированный сертификат опознается по своему серийному номеру. Когда у какой-то системы возникает необходимость в использовании сертификата, эта система не только проверяет подпись сертификата и срок его действия, но и просматривает последний из доступных списков CRL, проверяя, не аннулирован ли этот сертификат.

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

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

Он включает в себя дату выдачи, дату обновления (необязательно), и сам список в виде пар (серийный номер аннулированного сертификата; причина возможного аннулирования). Шаблон может присутствовать только в формате CRL v2, который описан в RFC 5280 в 5 разделе.

Большим недостатком является ограничение CRL, которое состоит в долгом поступлении информации об аннулировании сертификата. Чтобы ускорить, был разработан протокол OCSP для проверки сертификата. Описанный изначально в RFC 2560, а затем снова в RFC 6960, протокол OCSP дает почти ту же информацию, что и CRL. Сервер OCSP (англ. Online Certificate Status Protocol) обслуживает пользователей в режиме онлайн и занимается проверкой статуса аннулирования цифрового сертификата.

Примеры использования X.509

[править | править код]

Образовательная сеть доверия на основе сертификатов стандарта X.509

[править | править код]

Этот проект сети взаимного доверия основан на PKIX и предназначен для авторизованной рассылки учебных заданий, получения отчётов об их выполнении и консультаций, а также для получения сертификатов на коммерческих УЦ[8].

EC PERMIS

[править | править код]

Проект EC PERMIS разработал роли, основанные на инфраструктуре управления доступом. Для хранения ролей пользователей используются сертификаты X.509. Сертификат X.509 хранит политику авторизации в формате XML по DtD (англ. Data transfer Device), с помощью которой производится управление доступом. В проекте используется распределитель привилегий, который является инструментом, создающим и подписывающим сертификаты и сохраняющий их в каталог LDAP для последующего их использования функцией контроля доступом[9].

Модель безопасности для сред Мобильный Агент, использующих прокси-сертификаты X.509

[править | править код]

Технология Мобильный Агент (далее — «МА») представляет собой привлекательную альтернативу для клиент-серверной архитектуры при использовании её для нескольких сетей и приложений в режиме реального времени. Предложена модель безопасности для МА на основе инфраструктуры безопасности для вычислительных сетей, и, в частности, на основе прокси-сертификатов X.509. Прокси-сертификаты служат в качестве учётных данных для сетевых приложений, и их основной целью является временное делегирование полномочий. Используя сходство между грид-приложениями и приложениями МА, можно использовать прокси-сертификаты в качестве учётных данных для МА. Новое расширение для прокси-сертификатов предлагается для того, чтобы сделать их подходящими для их применения в системах МА и в других механизмах в целях ограничения прав агентов и в целях безопасного делегирования полномочий во время прибытия новых агентов[10].

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

[править | править код]

Опубликована информация о коллизиях в алгоритме хеширования MD5 в 2004 году и об атаках на этот алгоритм, которые совершили Арьен Ленстра, Ван Сяоюнь и Бенн де Уэгер. Они подделали два сертификата с одинаковыми подписями. Таким образом, их атака с помощью MD5 поставила под сомнение безопасность использования X.509[11].

Использование криптографических хеш-функций SHA-1 только частично решает проблему, так как согласно теории подобная атака возможна, даже если сложность поиска коллизий на SHA-1 намного больше, чем MD5, согласно RFC 3279. Необходимо помнить, что взаимодействие ведётся с людьми и УЦ. Надёжность, безопасность и прочие достоинства использования сертификатов X.509 определяются самым слабым звеном во всех системах безопасности: конкретными людьми или УЦ. Известные проблемы стандарта X.509: невозможность оперативного исключения корневого сертификата, или трудоёмкая процедура получения сертификата в целом.

Тестирование синтаксиса инфраструктуры открытых ключей на уязвимости в сертификате X.509

[править | править код]

Министерство национальной обороны Канады определило потребность в создании универсальной PKI для управления своей повседневной деятельностью и установления доверия к продуктам PKI.

За основу взяли подход PROTOS по тестированию протоколов, использовав правила кодирования BER. Были использованы модели и инструменты для тестирования реализации системы доверия PKIX на уязвимости в системе безопасности. В рамках тестирования использовался синтаксис сертификата X.509 для создания потенциально опасных сертификатов X.509 с целью выявления уязвимостей в реализации доверия, построенной по стандарту X.509[4].

Взлом удостоверяющего центра DigiNotar

[править | править код]

21 июня 2011 года голландская компания VASCO Data Security International[англ.] зафиксировала взлом DigiNotar[англ.]. Компания Fox-IT[нидерл.], которая специализируется на расследованиях в области информационной безопасности, по запросу компетентных органов провела расследование этого взлома[12]. В августе 2011 в интернете появился поддельный сертификат для *.google.com, c помощью которого неизвестные лица просматривали почту пользователей Gmail из Ирана. Затем обнаружился факт компрометации серверов голландского центра сертификации DigiNotar, а также поддельные сертификаты Yahoo, Mozilla, Tor и других сайтов. Вскоре компания DigiNotar объявила о банкротстве и прекратила работу, а сертификаты DigiNotar были повсюду аннулированы.

Fox-IT опубликовали отчёт о расследовании в 2012 году. Как выяснилось, злоумышленники получили полный контроль над всеми восемью серверами центра сертификации DigiNotar задолго до того, как проникновение было обнаружено. Первым взломали сервер Demilitarized Zone 17 июня 2011 года. В дальнейшем эта система использовалась как точка обмена файлами между внешними системами и внутренними серверами DigiNotar[13].

Взлом DigiNotar заставил усомниться в долгосрочной жизнеспособности X.509 и были предложены альтернативные варианты, в том числе DANE[14] и другие[15].

См. также

[править | править код]

Примечания

[править | править код]
  1. ↑ «Recommendation ITU-T X.509» Архивная копия от 18 марта 2017 на Wayback Machine, на веб-сайте ITU, 2012  (Дата обращения: 10 февраля 2017).
  2. ↑ " L’annuaire — Cadre d’authentification " Архивная копия от 11 февраля 2017 на Wayback Machine на веб-сайте ITU, 2008  (Дата обращения: 11 февраля 2017).
  3. ↑ Public-Key Infrastructure (X.509) (pkix). IETF Datatracker. Дата обращения: 11 марта 2017. Архивировано 12 января 2018 года.
  4. ↑ 1 2 Turcotte Y. Syntax testing of the entrust public key infrastructure for security vulnerabilities in the X.509 certificate (англ.) // Royal Military College of Canada (Canada) : диссертация. — 2005.
  5. ↑ Tremblett P. X.509 certificates (англ.) // Miller Freeman Inc. — 1999. — Vol. 24, no. 7. — P. 42—48. — ISSN 1044-789X.
  6. ↑ X.509 security update (англ.) // CMP Media LLC. — 1995. — Vol. 24, no. 10. — P. 14. — ISSN 0363-6399.
  7. ↑ Lewis J. X.509 is a start, but it's no panacea (англ.) // Ziff Davis Media Inc. : статья в журнале. — 1997. — Vol. 14, no. 37. — P. 109. — ISSN 0740-1604.
  8. ↑ Хорев Павел Борисович. Образовательная сеть доверия на основе сертификатов стандарта X.509 // Издательский дом МЭИ (Москва) : конференция. — 2016. — 12—13 апреля.
  9. ↑ Chadwick D.W., Otenko A. The PERMIS X.509 role based privilege management infrastructure (англ.) // Elsevier Science Publishing Company, Inc. — 2003. — Vol. 19, no. 2. — P. 277—289. — ISSN 0167-739X.
  10. ↑ Raghunathan S. A security model for mobile agent environments using X.509 proxy certificates (англ.) // University of North Texas : диссертация. — 2003.
  11. ↑ Arjen Lenstra, Xiaoyun Wang, Benne de Weger (2005-03-01). "Colliding X.509 Certificates based on MD5-collisions". Eindhoven University of Technologies News (англ.). Архивировано 15 мая 2017. Дата обращения: 10 февраля 2017.{{cite news}}: Википедия:Обслуживание CS1 (множественные имена: authors list) (ссылка)
  12. ↑ J.R. Prins (CEO Fox-IT) (2011-09-05). "DigiNotar Certificate Authority breach "Operation Black Tulip"" (PDF). FOX-IT BV (англ.). Архивировано (PDF) 21 апреля 2015. Дата обращения: 16 февраля 2017. {{cite news}}: Указан более чем один параметр |язык= and |language= (справка)
  13. ↑ Hans Hoogstraaten (Team leader), Ronald Prins (CEO), Daniël Niggebrugge, Danny Heppener, Frank Groenewegen, Janna Wettinck, Kevin Strooy, Pascal Arends, Paul Pols. Robbert Kouprie, Steffen Moorrees, Xander van Pelt, Yun Zheng Hu (2012-08-13). "Report of the investigation into the DigiNotar Certificate Authority breach" (PDF). FOX-IT BV (англ.). Архивировано (PDF) 17 февраля 2015. Дата обращения: 16 февраля 2017. {{cite news}}: Указан более чем один параметр |язык= and |language= (справка)Википедия:Обслуживание CS1 (множественные имена: authors list) (ссылка)
  14. ↑ Jim Fenton (2011-11-14). "Top of Mind: Reexamining Public Key Infrastructure". Cisco Blogs (англ.). Архивировано 23 декабря 2016. Дата обращения: 4 марта 2017. {{cite news}}: Указан более чем один параметр |язык= and |language= (справка)
  15. ↑ Michael Gielesberger. Alternatives to X.509 (англ.) // Technical University of Munich : Internet Seminar. — 2013. — 1 февраль. Архивировано 5 марта 2017 года.

Ссылки

[править | править код]
  • EJBCA — open source PKI.
  • CAcert — бесплатный персональный сертификат.
  • X.509 Builder — бесплатный инструмент.
Источник — https://ru.wikipedia.org/w/index.php?title=X.509&oldid=136034910