Эта статья является кандидатом в добротные статьи

X.509

Материал из Википедии — свободной энциклопедии
Перейти к: навигация, поиск

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

X.509 определяет стандартные форматы данных и процедуры распределения открытых ключей с помощью соответствующих сертификатов с цифровыми подписями[⇨]. Эти сертификаты предоставляются удостоверяющими центрами (англ. Certificate Authority). Кроме того, X.509 определяет формат списка аннулированных сертификатов (англ. Certificate revocation lists, CRL)[⇨], формат сертификатов атрибутов (англ. Attribute certificates) и алгоритм проверки подписи путём построения пути сертификации (англ. Certification path validation algorithm). X.509 предполагает наличие иерархической системы удостоверяющих центров[⇨] для выдачи сертификатов. Тем не менее, немало решений, основанных на стандарте 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 способны быстро реагировать на компрометацию отдельного УЦ внутри инфраструктуры. Если УЦ скомпрометирован, вышестоящий УЦ просто аннулирует его сертификат. Как только работа УЦ восстанавливается, он выпускает новые сертификаты для всех своих пользователей. Вышестоящий УЦ выпускает для скомпрометированного УЦ новый сертификат с новым открытым ключом, что позволяет вернуть этот центр обратно в иерархию.

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

Согласно RFC 2459:

  • .CER — сертификат, или набор сертификатов, закодированных по стандарту CER.
  • .DER — сертификат, закодированный по стандарту DER.
  • .PEM — PEM-сертификат, закодированный по стандарту DER и использующий Base64 и помещенный между «----- BEGIN CERTIFICATE -----» и «----- END CERTIFICATE -----».
  • .P7B, .P7C — PKCS #7 содержит несколько сертификатов или CRL.
  • .P12 — PKCS #12 содержит блок, хранящий одновременно и закрытый ключ, и сертификат (в зашифрованном виде).
  • .PFX — PFX, предшественник PKCS #12, также содержит блок закрытого ключа и сертификат.

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

Согласно 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», на веб-сайте ITU, 2012  (Проверено 10 февраля 2017).
  2. " L’annuaire — Cadre d’authentification " на веб-сайте ITU, 2008  (Проверено 11 февраля 2017).
  3. Public-Key Infrastructure (X.509) (pkix). IETF Datatracker. Проверено 11 марта 2017.
  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. Colliding X.509 Certificates based on MD5-collisions, Eindhoven University of Technologies News (1 марта 2005 года).
  12. J.R. Prins (CEO Fox-IT). DigiNotar Certificate Authority breach “Operation Black Tulip” (англ.) (PDF), FOX-IT BV (5 сентября 2011).
  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. Report of the investigation into the DigiNotar Certificate Authority breach (англ.) (PDF), FOX-IT BV (13 августа 2012).
  14. Jim Fenton. Top of Mind: Reexamining Public Key Infrastructure (англ.), Cisco Blogs (14 ноября 2011 года).
  15. Michael Gielesberger Alternatives to X.509 (англ.) // Technical University of Munich : Internet Seminar. — 2013. — 1 февраль.

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

  • EJBCA — open source PKI.
  • CAcert — бесплатный персональный сертификат.
  • X.509 Builder — бесплатный инструмент.