13:58 X.509 | |
| В криптографии , X.509 является стандарт , определяющий формат сертификатов открытых ключей . Сертификаты X.509 используются во многих интернет-протоколах, включая TLS / SSL , который является основой для HTTPS , безопасного протокола для просмотра веб-страниц . Они также используются в автономных приложениях, таких как электронные подписи . Сертификат X.509 содержит открытый ключ и идентификатор (имя хоста, или организация, или физическое лицо) и подписан центром сертификации.или самоподписанный. Когда сертификат подписан доверенным центром сертификации или проверен другими средствами, кто-то, владеющий этим сертификатом, может использовать открытый ключ, который он содержит, для установления защищенной связи с другой стороной или проверки документов, подписанных цифровой подписью соответствующим закрытым ключом . X.509 также определяет списки отзыва сертификатов , которые являются средством распространения информации о сертификатах, которые были признаны недействительными подписывающим органом, а также алгоритм проверки пути сертификации , который позволяет сертификатам подписываться промежуточными сертификатами CA, которые в свою очередь подписаны другими сертификатами, в конечном итоге достигнув якоря доверия . X.509 определяется сектором стандартизации Международного союза электросвязи ( МСЭ-Т ) и основан на ASN.1 , другом стандарте МСЭ-Т. В системе X.509 организация, которая хочет подписанный сертификат, запрашивает его через запрос на подпись сертификата (CSR). Для этого он сначала генерирует пару ключей , сохраняя секретный ключ в секрете и используя его для подписи CSR. Он содержит информацию, идентифицирующую заявителя, и открытый ключ заявителя, который используется для проверки подписи CSR, а также отличительное имя (DN), для которого предназначен сертификат. CSR может сопровождаться другими полномочиями или доказательствами личности, требуемыми центром сертификации. Центр сертификации выдает сертификат, связывающий открытый ключ с конкретным отличительным именем . Доверенные корневые сертификаты организации могут быть распространены среди всех сотрудников, чтобы они могли использовать систему PKI компании. Браузеры, такие как Internet Explorer , Firefox , Opera , Safari и Chrome, поставляются с предварительно установленным набором предварительно установленных корневых сертификатов, поэтому сертификаты SSL от основных центров сертификации будут работать мгновенно; по сути, разработчики браузеров определяют, какие CA являются доверенными третьими сторонами для пользователей браузеров. [ цитата нужна ]Например, Firefox предоставляет файл CSV и / или HTML, содержащий список включенных центров сертификации. X.509 и RFC 5280 также включают стандарты для реализаций списка отзыва сертификатов (CRL). Другой одобренный IETF способ проверки действительности сертификата - это протокол статуса сертификата в сети (OCSP). Firefox 3 по умолчанию включает проверку OCSP, как и версии Windows, по крайней мере, с Vista и выше. Структура, предусмотренная стандартами, выражена на официальном языке, абстрактной синтаксической нотации один (ASN.1). Структура цифрового сертификата X.509 v3 выглядит следующим образом: сертификат Номер версии Серийный номер Идентификатор алгоритма подписи Имя эмитента Срок годности Не раньше, чем Не после Имя субъекта Информация о публичном ключе Алгоритм открытого ключа Тематический открытый ключ Уникальный идентификатор эмитента (необязательно) Уникальный идентификатор субъекта (необязательно) Расширения (необязательно) ... Алгоритм подписи сертификата Сертификат Подпись Каждое расширение имеет свой собственный идентификатор, выраженный в виде идентификатора объекта , который представляет собой набор значений вместе с критической или некритической индикацией. Система, использующая сертификат, должна отклонить сертификат, если она обнаружит критическое расширение, которое она не распознает, или критическое расширение, содержащее информацию, которую она не может обработать. Некритическое расширение может игнорироваться, если оно не распознано, но должно обрабатываться, если оно распознано. Структура версии 1 приведена в RFC 1422. МСЭ-Т ввел уникальные идентификаторы эмитента и субъекта в версии 2, чтобы разрешить повторное использование имени эмитента или субъекта через некоторое время. Примером повторного использования будет случай, когда ЦС обанкротится и его имя будет удалено из публичного списка страны. Через некоторое время другой ЦС с тем же именем может зарегистрировать себя, даже если он не связан с первым. Однако IETF рекомендует не использовать имена эмитентов и субъектов. Поэтому версия 2 не получила широкого распространения в Интернете. Расширения были введены в версии 3. ЦС может использовать расширения для выдачи сертификата только для определенной цели (например, только для подписи цифровых объектов ). Во всех версиях серийный номер должен быть уникальным для каждого сертификата, выданного конкретным центром сертификации (как указано в RFC 5280). Расширения, информирующие о конкретном использовании сертификата RFC 5280 (и его предшественники) определяет ряд расширений сертификата, которые указывают, как сертификат должен использоваться. Большинство из них - дуги из OID соединения-iso-ccitt (2) ds (5) id-ce (29) . Некоторые из наиболее распространенных, определенных в разделе 4.2.1: Основные ограничения, {id-ce 19} , используются для указания того, принадлежит ли сертификат CA. Использование ключа, {id-ce 15} , предоставляет битовую карту, определяющую криптографические операции, которые могут выполняться с использованием открытого ключа, содержащегося в сертификате; например, это может означать, что ключ должен использоваться для подписей, но не для шифрования. Расширенное использование ключа, {id-ce 37} , используется, как правило, на листовом сертификате, чтобы указать назначение открытого ключа, содержащегося в сертификате. Он содержит список OID, каждый из которых указывает на разрешенное использование. Например, {id-pkix 3 1} указывает, что ключ может использоваться на стороне сервера соединения TLS или SSL; {id-pkix 3 4} указывает, что ключ может быть использован для защиты электронной почты. В целом, если сертификат имеет несколько расширений, ограничивающих его использование, все ограничения должны быть соблюдены, чтобы данное использование было целесообразным. RFC 5280 дает конкретный пример сертификата, содержащего и keyUsage, и extendedKeyUsage: в этом случае оба должны быть обработаны, и сертификат можно использовать только в том случае, если оба расширения согласованы при указании использования сертификата. Например, NSS использует оба расширения для указания использования сертификата. Расширения файлов сертификатов Существует несколько часто используемых расширений файлов для сертификатов X.509. К сожалению, некоторые из этих расширений также используются для других данных, таких как закрытые ключи. .pem - ( электронная почта с повышенной конфиденциальностью ) сертификат DER в кодировке Base64 , заключенный между "----- BEGIN CERTIFICATE -----" и "----- END CERTIFICATE -----" .cer , .crt , .der - обычно в двоичной форме DER , но также распространены сертификаты в кодировке Base64 (см. выше .pem ) .p7b , .p7c - структура SignedData PKCS # 7 без данных, только сертификат (ы) или CRL (и) .p12 - PKCS # 12 , может содержать сертификат (ы) (открытый) и закрытые ключи (защищенный паролем) .pfx - PFX, предшественник PKCS # 12 (обычно содержит данные в формате PKCS # 12, например, с файлами PFX, созданными в IIS ) PKCS # 7 является стандартом для подписи или шифрования (официально называемых «конвертирующими») данных. Поскольку сертификат необходим для проверки подписанных данных, их можно включить в структуру SignedData. .P7C файл является выродился структура SignedData, без каких - либо данных подписать. PKCS # 12 разработан на основе стандарта обмена личной информацией (PFX) и используется для обмена открытыми и закрытыми объектами в одном файле. Цепочка сертификатов представляет собой список сертификатов (обычно начиная с сертификата конечного объекта) с последующим одним или более CA сертификатов ( как правило , последний из которых будучи самоподписанный сертификат) со следующими свойствами: Эмитент каждого сертификата (кроме последнего) совпадает с темой следующего сертификата в списке. Предполагается, что каждый сертификат (кроме последнего) должен быть подписан секретным ключом, соответствующим следующему сертификату в цепочке (т. Е. Подпись одного сертификата может быть проверена с использованием открытого ключа, содержащегося в следующем сертификате). Последний сертификат в списке - это якорь доверия : сертификат, которому вы доверяете, потому что он был доставлен вам с помощью какой-либо заслуживающей доверия процедуры. Цепочки сертификатов используются для проверки того, что открытый ключ (PK), содержащийся в целевом сертификате (первый сертификат в цепочке) и другие данные, содержащиеся в нем, эффективно принадлежит его субъекту. Чтобы убедиться в этом, подпись на целевом сертификате проверяется с помощью PK, содержащегося в следующем сертификате, чья подпись проверяется с использованием следующего сертификата, и так далее, пока не будет достигнут последний сертификат в цепочке. Поскольку последний сертификат является якорем доверия, успешное его получение докажет, что целевой сертификат может быть доверенным. Описание в предыдущем абзаце представляет собой упрощенный взгляд на процесс проверки пути сертификации, как определено в RFC 5280 , , который включает в себя дополнительные проверки, такие как проверка дат действия сертификатов, поиск CRL и т. Д. Архитектурные недостатки Использование внесения в черный список недействительных сертификатов (с использованием CRL и OCSP ), Если клиент доверяет сертификатам только при наличии CRL, он теряет возможность автономной работы, что делает PKI привлекательным. Таким образом, большинство клиентов доверяют сертификатам, когда CRL недоступны, но в этом случае злоумышленник, управляющий каналом связи, может отключить CRL. Адам Лэнгли из Google сказал, что проверки CRL с мягким отказом подобны ремню безопасности, который работает, за исключением случаев, когда вы попали в аварию. RL особенно плохой выбор из-за больших размеров и запутанных схем распределения, Двусмысленная семантика OCSP и отсутствие исторического статуса отзыва, Отзыв корневых сертификатов не рассматривается, Проблема агрегации : утверждения идентификации (проверка подлинности с помощью идентификатора), утверждения атрибутов (отправка пакета проверенных атрибутов) и утверждения политики объединяются в один контейнер. Это поднимает вопросы конфиденциальности, политик и обслуживания. Проблема делегирования : ЦС не могут технически ограничивать подчиненные ЦС от выдачи сертификатов вне ограниченного пространства имен или набора атрибутов; эта функция X.509 не используется. Поэтому в Интернете существует большое количество ЦС, и их классификация и их политика являются непреодолимой задачей. Передача полномочий внутри организации не может быть решена вообще, как в обычной деловой практике. Проблема федерации : цепочки сертификатов, являющиеся результатом подчиненных ЦС, мостовых ЦС и перекрестной подписи, делают проверку достоверной и дорогой с точки зрения времени обработки. Семантика проверки пути может быть неоднозначной. Иерархия со сторонней доверенной стороной является единственной моделью. Это неудобно, когда уже установлены двусторонние доверительные отношения. Выдача сертификата расширенной проверки (EV) для имени хоста не препятствует выдаче сертификата с более низкой валидацией, действительного для того же имени хоста, что означает, что более высокий уровень проверки EV не защищает от человека посередине атаки Основные протоколы и стандарты, использующие сертификаты X.509 TLS / SSL и HTTPS используют профиль RFC 5280 X.509, как и S / MIME (безопасные многоцелевые расширения почты Интернета) и метод EAP-TLS для аутентификации WiFi. Любой протокол, который использует TLS, такой как SMTP, POP, IMAP, LDAP, XMPP и многие другие, по своей природе использует X.509. IPSec может использовать профиль RFC 4945 для аутентификации одноранговых узлов. OpenCable спецификация безопасности определяет свой собственный профиль X.509 для использования в кабельной промышленности. Такие устройства, как смарт-карты и доверенные платформенные модули, часто имеют сертификаты для идентификации себя или своих владельцев. Эти сертификаты в форме X.509. Стандарт WS-Security определяет аутентификацию либо через TLS, либо через собственный профиль сертификата. Оба метода используют X.509. Система подписи кода Microsoft Authenticode использует X.509 для идентификации авторов компьютерных программ. Стандарт связи промышленной автоматизации OPC UA использует X.509. Обычно SSH использует модель безопасности « Доверие при первом использовании» и не нуждается в сертификатах. Тем не менее, популярная реализация OpenSSH поддерживает подписанную СА модель идентификации, основанную на собственном формате сертификата не-X.509. | |
|
| |
| Всього коментарів: 0 | |