Согласно RFC 1422, стандарт X.509 определяет понятие «сертификат с открытом ключом» и другие базовые определения PKIX. При этом сертификат с открытым ключом представляет собой определённую структуру данных, которая содержит имя пользователя, открытую составляющую (англ. ) ключа двухключевой криптосистемы этого пользователя и имя компании (далее — «издатель»), который подтверждает, что открытая составляющая привязана к имени пользователя. Эти данные через каждый временной интервал подписываются эмитентом. В сертификатах имена субъекта и издателя являются различимыми именами (англ. ), как определено в системном каталоге Х.500.
После подписания сертификаты могут храниться на LDAP-серверах. Передаются сертификаты через незащищённые обменные сообщения или через любое другое средство, которое делает сертификаты легко доступными при отправке сообщений пользователям. Сертификаты используются в PEM-кодировке, чтобы обеспечить отправителя подлинной открытой составляющей каждого получателя, а также чтобы обеспечить каждого получателя подлинной открытой составляющей отправителя.
Для технологии открытых ключей необходимо, чтобы пользователь открытого ключа был уверен, что этот ключ принадлежит именно тому удалённому субъекту (пользователю или системе), который будет использовать средства шифрования или цифровой подписи. Такую уверенность дают сертификаты открытых ключей. Сертификат имеет ограниченный срок действия. Поскольку пользователь сертификата может самостоятельно проверить его подпись и срок действия, сертификаты могут распространяться через незащищённые каналы связи и серверные системы, а также храниться в кэш-памяти незащищённых пользовательских систем. В настоящее время в этой области предлагается следующий общий стандарт для всемирной сети с использованием X.509 v3:
Структура сертификата X. 509
Общий стандарт для интернета, использующий формат X.509
В 4 разделе RFC 2459 описана структура сертификата X.509 v3. Обновленная структура сертификата X.509 v3 описана в документе RFC 5280 в 4 разделе. Она специализирована под интернет-приложения.
Согласно RFC 4387, суть PKI следующая: в браузере хранятся не сертификаты сайтов, а сертификаты УЦ. Это означает, что когда ваш браузер получает сертификат сайта при установке соединения, он видит помимо адреса сайта ещё и «адрес» УЦ, а также цифровую подпись, которую сгенерировал УЦ с использованием своего секретного ключа. Дальше браузер берёт из локального хранилища цепь сертификатов УЦ, достаёт из него публичный ключ и с помощью него проверяет подпись в сертификате сайта. Если подпись правильная, соединение успешно устанавливается.
Согласно RFC 5280, цепь сертификатов представляет собой список сертификатов (начиная с лица, удостоверенного в качестве сервера), включающий один или несколько УЦ (последний подписывается самим собой), обладает следующими свойствами:
Иерархические PKI способны быстро реагировать на компрометацию отдельного УЦ внутри инфраструктуры. Если УЦ скомпрометирован, вышестоящий УЦ просто аннулирует его сертификат. Как только работа УЦ восстанавливается, он выпускает новые сертификаты для всех своих пользователей. Вышестоящий УЦ выпускает для скомпрометированного УЦ новый сертификат с новым открытым ключом, что позволяет вернуть этот центр обратно в иерархию.
Общеупотребительные расширения файлов сертификатов
Согласно 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
Использование криптографических хеш-функций SHA-1 только частично решает проблему, так как согласно теории подобная атака возможна, даже если сложность поиска коллизий на SHA-1 намного больше, чем MD5, согласно RFC 3279. Необходимо помнить, что взаимодействие ведётся с людьми и УЦ. Надёжность, безопасность и прочие достоинства использования сертификатов X.509 определяются самым слабым звеном во всех системах безопасности: конкретными людьми или УЦ. Известные проблемы стандарта X.509: невозможность оперативного исключения корневого сертификата, или трудоёмкая процедура получения сертификата в целом.
Тестирование синтаксиса инфраструктуры открытых ключей на уязвимости в сертификате X. 509
Министерство национальной обороны Канады определило потребность в создании универсальной PKI для управления своей повседневной деятельностью и установления доверия к продуктам PKI.
Взлом удостоверяющего центра DigiNotar
Текущая версия страницы пока не проверялась опытными участниками и может значительно отличаться от версии, проверенной 30 декабря 2022 года; проверки требуют 2 правки.
Сертификат открытого ключа (сертификат электронной подписи, сертификат ключа подписи, сертификат ключа проверки электронной подписи (согласно ст. 2 Федерального Закона от 06.04.2011 «Об электронной подписи» № 63-ФЗ)) — электронный или бумажный документ, содержащий открытый ключ, информацию о владельце ключа, области применения ключа, подписанный выдавшим его Удостоверяющим центром и подтверждающий принадлежность открытого ключа владельцу.
Открытый ключ может быть использован для организации защищённого канала связи с владельцем двумя способами:
Существует две модели организации инфраструктуры сертификатов: централизованная (PKI) и децентрализованная (реализуемая на основе т. н. сетей доверия), получившая наибольшее распространение в сетях PGP.
Наглядное объяснение принципа работы сертификатов открытого ключа на примере установки ПО от стороннего разработчика пользователем в Интернете
Сертификаты, как правило, используются для обмена зашифрованными данными в больших сетях. Криптосистема с открытым ключом решает проблему обмена секретными ключами между участниками безопасного обмена, однако не решает проблему доверия к открытым ключам. Предположим, что Алиса, желая получать зашифрованные сообщения, генерирует пару ключей, один из которых (открытый) она публикует каким-либо образом. Любой, кто желает отправить ей конфиденциальное сообщение, имеет возможность зашифровать его этим ключом, и быть уверенным, что только она (так как только она обладает соответствующим секретным ключом) сможет это сообщение прочесть. Однако описанная схема ничем не может помешать злоумышленнику Давиду создать пару ключей, и опубликовать свой открытый ключ, выдав его за ключ Алисы. В таком случае Давид сможет расшифровывать и читать, по крайней мере, ту часть сообщений, предназначенных Алисе, которые были по ошибке зашифрованы его открытым ключом.
Идея сертификата — это наличие третьей стороны, которой доверяют две другие стороны информационного обмена. Предполагается, что таких третьих сторон немного, и их открытые ключи всем известны каким-либо способом, например, хранятся в операционной системе или публикуются в журналах. Таким образом, подлог открытого ключа третьей стороны легко выявляется.
Сертификат открытого ключа выдаётся центром сертификации и состоит из таких полей как:
Цифровая подпись гарантирует невозможность подделки сертификата. Она является результатом криптографической хеш-функции от данных сертификата, зашифрованным закрытым ключом центра сертификации. Открытый ключ центра сертификации является общеизвестным, поэтому любой может расшифровать им цифровую подпись сертификата, затем вычислить хеш самостоятельно и сравнить, совпадают ли хеши. Если хеши совпадают — значит сертификат действительный и можно не сомневаться, что открытый ключ принадлежит именно тому, с кем мы собираемся устанавливать соединение.
Если Алиса сформирует сертификат со своим публичным ключом и этот сертификат будет подписан третьей стороной (например, Трентом), любой, доверяющий Тренту, сможет удостовериться в подлинности открытого ключа Алисы. В централизованной инфраструктуре в роли Трента выступает удостоверяющий центр. В сетях доверия Трент может быть любым пользователем, и следует ли доверять этому пользователю, удостоверившему ключ Алисы, решает сам отправитель сообщения.
Пусть имеются две стороны информационного обмена — , , желающие обмениваться сообщениями конфиденциально, и третья сторона (играющая роль удостоверяющего центра), которой доверяют и .
регистрируется у (посылает запрос на подпись), указывая данные о себе и свой . Сторона посредством определенных механизмов “удостоверяет личность” стороны и выдает стороне сертификат , устанавливающий соответствие между субъектом и ключом . Сертификат содержит:
посылает стороне свой сертификат . проверяет цифровую подпись . Для этого
Если полученные хеши равны – ЭЦП корректна, а это подтверждает, что действительно принадлежит .
Теперь , зная открытый ключ и зная, что он принадлежит именно , может шифровать этим открытым ключом все последующие сообщения для . И только сможет их расшифровать, так как известен только .
Электронная форма сертификата определяется стандартом X.509. Перечень обязательных и необязательных полей, которые могут присутствовать в сертификате, определяется данным стандартом, а также законодательством. Согласно законодательству России и Украины (закон «Об электронной цифровой подписи») сертификат должен содержать следующие поля:
Кроме этого в сертификат могут вноситься дополнительные поля.
Бумажный сертификат должен выдаваться на основании подтверждающих документов и в присутствии лица с последующим заверением подписями работника УЦ и носителя закрытого ключа.
В России действуют свои криптографические стандарты. Использование их совместно с сертификатами описано в RFC4491: Using GOST with PKIX.
У этого термина существуют и другие значения, см. Сертификат.
Цифровой сертификат — выпущенный удостоверяющим центром электронный или печатный документ, подтверждающий принадлежность владельцу открытого ключа или каких-либо атрибутов.
Виды сертификатов X. 509
Сертификат открытого ключа удостоверяет принадлежность открытого ключа некоторому субъекту, например, пользователю. Сертификат открытого ключа содержит имя субъекта, открытый ключ, имя удостоверяющего центра, политику использования соответствующего удостоверяемому открытому ключу закрытого ключа и другие параметры, заверенные подписью удостоверяющего центра.
Сертификат открытого ключа используется для идентификации субъекта и уточнения операций, которые субъекту разрешается совершать с использованием закрытого ключа, соответствующего открытому ключу, удостоверяемому данным сертификатом.