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

X.509

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

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

X.509 определяет стандартные форматы данных и процедуры распределения открытых ключей с помощью соответствующих сертификатов с цифровыми подписями[⇨]. Эти сертификаты предоставляются удостоверяющими центрами (англ. Certificate Authority). Кроме того, X.509 определяет формат списка аннулированных сертификатов (англ. Certificate revocation lists, CRL)[⇨], формат сертификатов атрибутов (англ. Attribute certificates) и алгоритм проверки подписи, путем построения пути сертификации (англ. Certification path validation algorithm). X.509 предполагает наличие иерархической системы удостоверяющих центров[⇨] для выдачи сертификатов. Тем не менее, немало примеров, основанных на стандарте X.509[⇨], который не всегда безопасно использовать[⇨].

История[править | править вики-текст]

X.509 был выпущен официально 3 июля 1988 года, и его развитие началось в тесной связи со стандартом X.500[2].

Система X.500 так и не была полностью реализована. Рабочая группа IETF, разрабатывающая инфраструктуру открытого ключа, широко известна как PKIX для PKI, основанных на стандарте X.509. PKIX адаптировала стандарт, более криптостойкий для всемирной сети «Интернет». X.509 включает в себя стандарты для реализации многих CRL, а также зачастую и аспекты систем PKI. На самом деле, термин «сертификат X.509» обычно относился к сертификату PKIX и наличию CRL в сертификате стандарта X.509 v3, согласно RFC 3280.

Сервер OCSP (англ. Online Certificate Status Protocol) обслуживает пользователей в режиме онлайн и занимается проверкой статуса аннулирования цифрового сертификата.

Описание[править | править вики-текст]

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

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

В статье RFC 5280 определены сертификат X.509 v3 в 4 разделе и CRL v2 в 5 разделе.

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

Основными компонентами эффективной PKI являются:

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

Структура сертификата X.509[править | править вики-текст]

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

Определение доступно в 4 разделе RFC 2459. Новое определение дано в статье RFC 5280, содержащей описание стандарта X.509, специализированного под интернет-приложения

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

Особенности[править | править вики-текст]

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

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

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

Иерархическая PKI[править | править вики-текст]

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

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

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

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

  • .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)[править | править вики-текст]

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

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

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

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

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

Безопасность[править | править вики-текст]

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

Использование криптографических хеш-функций SHA-1 только частично решает проблему, так как согласно теории подобная атака возможна, даже если сложность поиска коллизий на SHA-1 намного больше, чем MD5.

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

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

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

Взлом удостоверяющего центра DigiNotar[править | править вики-текст]

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

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

Примеры использования X.509[править | править вики-текст]

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

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

EC PERMIS[править | править вики-текст]

Проект EC PERMIS разработал роли, основанные на инфраструктуре управления доступом. Он использует сертификаты X.509 для хранения ролей пользователей. Все решения управления доступом руководствуются политикой авторизации, которая хранится в сертификате X.509. Политики авторизации записываются в формате XML по DtD (англ. Data transfer Device), который был опубликован в XML.org. Функция контроля доступом (англ. Access Decision Function, ADF) написана на Java и Java API, проста в использовании, состоит всего из трех методов и конструктора. К тому же есть распределитель привилегий, который является инструментом, создающим и подписывающим сертификаты и сохраняющий их в каталог LDAP для последующего их использования функцией контроля доступом[11].

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

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

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

Примечания[править | править вики-текст]

  1. «Recommendation ITU-T X.509», на веб-сайте ITU, 2012  (Проверено 10 февраля 2017).
  2. « L'annuaire – Cadre d'authentification » на веб-сайте ITU, 2008  (Проверено 11 февраля 2017).
  3. 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.
  4. Tremblett P. X.509 certificates (англ.) // Miller Freeman Inc. — 1999. — Vol. 24, no. 7. — P. 42—48. — ISSN 1044-789X.
  5. X.509 security update (англ.) // CMP Media LLC. — 1995. — Vol. 24, no. 10. — P. 14. — ISSN 0363-6399.
  6. 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.
  7. Arjen Lenstra, Xiaoyun Wang, Benne de Weger. Colliding X.509 Certificates based on MD5-collisions, Eindhoven University of Technologies News (1 марта 2005 года).
  8. J.R. Prins (CEO Fox-IT). DigiNotar Certificate Authority breach “Operation Black Tulip” (англ.), FOX-IT BV (5 сентября 2011).
  9. 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 (англ.), FOX-IT BV (13 августа 2012).
  10. Хорев Павел Борисович Образовательная сеть доверия на основе сертификатов стандарта X.509 (рус.) // Издательский дом МЭИ (Москва) : конференция. — 2016. — 12—13 апреля.
  11. 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.
  12. Raghunathan S. A security model for mobile agent environments using X.509 proxy certificates (англ.) // University of North Texas : диссертация. — 2003.

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

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