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

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

История

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

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

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

Описание

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

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

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

• Удостоверяющий центр
• Регистрационный номер
• Конечные субъекты (например, браузер )

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

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

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

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

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

Особенности

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

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

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

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

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

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

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 (CSR). Ответ на него приходит обычно в файле .p7r .
• .p7r – ответ на CSR. Содержит только что подписанный сертификат, и сертификат ЦА.
• .p7s - PKCS#7 цифровая подпись. Может содержать изначальный файл или сообщение. Используется в S/MIME для подписи email писем. Специфицирован в в .
• .p7m - PKCS#7 (SignedData, EnvelopedData) Зашифрованный файл, сообщение, или MIME email письмо. Специфицирован в .
• .p7c - PKCS#7 (degenerated SignedData) только сертификаты, без каких либо данных для подписи. Специфицирован в .
• .p7b , .keystore (SignedData) содержит несколько сертификатов и/или CRL.
• .p12 , .pfx , .pkcs12 — PKCS #12 содержит блок, хранящий одновременно и закрытый ключ, и сертификат (в зашифрованном виде). .pfx — , предшественник PKCS #12.
• .crl - Certificate Revocation List (CRL). ЦА публикуют такие файлы чтобы деавторизировать сертификаты до истечения их срока действия.

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

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

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

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

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

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

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

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

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

EC PERMIS

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

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

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

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

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

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

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

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

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

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

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

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

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

См. также

• X.500
• Цифровой сертификат

Примечания

Ссылки

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