Формат сертификата Х.509
Х.509 - это другой очень распространённый формат. Все сертификаты Х.509 соответствуют международному стандарту ITU-T X.509; таким образом (теоретически), сертификат Х.509, созданный для одного приложения, может быть использован в любом другом, поддерживающем этот стандарт. На практике, однако, сложилась ситуация, что разные компании создают собственные расширения для Х.509, не все из которых между собой совместимы.
Всякий сертификат требует, чтобы кто-то заверил взаимосвязность открытого ключа и идентифицирующей владельца ключа информации. Имея дело с PGP-сертификатом, каждый может выступать в качестве заверителя содержащихся в нём сведений (за исключением случаев, когда эта возможность намеренно ограничена политикой безопасности). Но в случае сертификатов Х.509 заверителем может быть только Центр сертификации или некто, специально уполномоченный им на эту роль. (Имейте в виду, что PGP-сертификаты также в полной мере поддерживают иерархическое структурирование системы доверия, использующее ЦС для удостоверения сертификатов.)
Сертификат Х.509 - это набор стандартных полей, содержащих сведения о пользователе или устройстве, и их соответствующий открытый ключ. Стардарт Х.509 определяет, какие сведения входят в сертификат и как они кодируются (формат данных).
Сертификат Х.509 содержит следующие сведения:
Версия Х.509 - указывает, на основе какой версии стандарта Х.509 построен данный сертификат, что определяет, какая информация может в нём содержаться.
Открытый ключ владельца сертификата - открытый ключ наряду с идентификатором используемого алгоритма (указывающим криптосистему, к которой принадлежит данный ключ) и прочая информация о параметрах ключа.
Серийный номер сертификата - организация-издатель сертификата обязана присвоить ему уникальный серийный (порядковый) номер для его опознавания среди прочих сертификатов, выданных данной организацией. Эта информация применяется в ряде случаев; например, при аннулировании сертификата, его серийный номер помещается в список аннулированных сертификатов (Certificate Revocation List, CRL).
Уникальный опознаватель владельца ключа (или DN, distinguished name - уникальное имя) - это имя должно быть уникальным и единственным во всём Интернете. DN состоит из нескольких подпунктов и может выглядеть примерно так:
CN=Bob Davis, [email protected], OU=PGP Engineering,
O=PGP Corporation, C=US
(Что обозначает Понятное имя субъекта, Электронную почту, Подразделение организации, Организацию и Страну соответственно.)
Период действия сертификата - дата начала действия сертификата и дата окончания его действия; указывает на то, когда сертификат станет недействителен.
Уникальное имя издателя - уникальное имя организации, подписавшей сертификат. Обычно, это наименование Центра сертификации. Использование сертификата подразумевает доверие организации, его подписавшей. (В случаях с корневыми сертификатами выдавшая организация - этот же ЦС - подписывает его сама.)
ЭЦП издателя - электронная подпись, созданная закрытым ключом организации, выдавшей сертификат. Идентификатор алгоритма подписи - указывает алгоритм, использованный ЦС для подписания сертификата.
Существует ряд фундаментальных различий между форматами сертификатов Х.509 и PGP:
вы можете лично создать собственный сертификат PGP;
вы должны запросить и получить сертификат Х.509 от Центра сертификации; сертификаты Х.509 содержат только одно имя владельца сертификата;
сертификаты Х.509 содержат только одну ЭЦП, подтверждающую подлинность сертификата.
Чтобы получить сертификат Х.509, вы должны попросить ЦС выдать его вам. Вы предоставляете системе свой открытый ключ, чем доказываете, что обладаете соответствующим закрытым, а также некоторые идентифицирующие вас сведения. Затем вы электронно подписываете эти сведения и отправляете весь пакет - запрос сертификата - в Центр сертификации. ЦС выполняет определённый процесс по проверке подлинности предоставленной информации и, если всё сходится, создаёт сертификат, подписывает и возвращает вам.
Стандарт PGP (Pretty Good Privacy).
Сертификат PGP содержит, прежде всего, открытый ключ и идентификатор (или несколько альтернативных идентификаторов) владельца. Идентификатор владельца может быть как текстовым, так и графическим.
Сертификат может быть заверен более чем одной цифровой подписью; причем каждая подпись заверяет связь открытого ключа с одним или несколькими из приведенных в сертификате идентификаторов владельца (это разрешает реализовать концепцию кумулятивного доверия). Предполагается, что подписчиками могут выступать обычные пользователи.
В конце концов (начиная, по крайней мере, из версии 7.0), для каждого из подписчиков сертификат может содержать пометку о том, что подписант полностью доверяет субъекту (владельцу) сертификата как издателю сертификатов для других пользователей (причем еще и указать домен адресов электронной почты, на который распространяется это доверие). Это дает возможность расширять “сети доверия” пользователей за границы круга их личных знакомых (хотя и недалеко) и создавать корпоративные ИУОК с определенной политикой издания сертификатов практически любой сложности.
Стандарт PGP применяется в одноименной системе защиты электронной переписки. Первая версия этой системы была разработана в 1991 году Ф. Циммерманом (США). Версия 7.0 вышла в 2000 году (как разработка фирмы Network Associates, Inc.).
Стандарт ISO ITU-T X.509v1, 2.
X.509v1 — исторически первый стандарт цифрового сертификата (появился в 1988 году). Отличие между версиями 1 и 2 несущественная.
Сертификат X.509v1, 2 — это обычный идентификационный сертификат с жестким форматом.
Содержит, прежде всего, открытый ключ и идентификатор (один) владельца. Идентификатор владельца является текстовым.
Указывается также срок действия сертификата (открытого ключа).
Заверяется одним издателем.
Стандарт ISO ITU-T X.509v3.
Главное отличие сертификата X.509v3 от сертификата X.509v1, 2 — наличие так называемых приложений (extensions). Стандарт X.509v3 (появился в 1997 году) определяет несколько стандартных (standard), т.е. определенных не только по форме, но и по содержанию, приложений. Кроме того, разрешает включать в сертификат так называемые пользовательские (user-defined) приложения, которые определяются только по форме.
Пользовательские приложения применяются ИУОК, главным образом, для включения в сертификат информации о полномочии субъектов.
Среди наиболее важных стандартных приложений можно выделить такие:
- идентификатор политики издания;
- альтернативные идентификаторы субъекта;
- идентификатор полномочий субъекта как издателя сертификатов (пользователи могут применять это приложение при авторизации полномочий издателя);
- адрес сервера публикации СОС (может быть несколько таких приложений, в том числе, например, адреса сервера публикации дельта-СОС).
Сертификаты формата X.509 применяются подавляющим большинством современных ИУОК. Например, они применяются в системах Visa и MasterCard, на их основе функционирует всемирная ИУОК фирмы VeriSign (эта фирма, в частности, выдает сертификаты для Web-Серверов), на их основе функционируют, как правило, системы, предназначенные для создания корпоративных ИУОК (например, от фирм Entrust и TimeStamp), их применение предусматривает проект глобальной ИУОК для Интернет PKIX.
В рамках спонсорства:
Незабываемый отдых, туристические экскурсии по известным местам, лазурное море, горячий песок, умеренные цены, Анталия (см. www.tourskidki.ru) ждет Вас!..
инфраструктура управления привилегиями PMI " (Privilege Management Infrastructure). Главное отличие между ними заключается в том, что PKI управляет , а PMI - атрибутными сертификатами . Сертификат открытого ключа можно сравнить с паспортом субъекта, а атрибутный сертификат - с визой, первый обеспечивает идентификацию личности, а второй дает определенное разрешение. Основные термины и аббревиатуры, используемые в стандартах PKIX, а также их аналоги на русском языке приведены в табл. 15.5 .Системы, использующие сертификаты, и PKI
Результатом усилий технических специалистов по повышению безопасности Интернета стала разработка группы протоколов безопасности, таких как S/MIME, TLS и IPsec. Все эти протоколы используют криптографию с открытыми ключами для обеспечения сервисов конфиденциальности, целостности данных, аутентификации источника данных и неотказуемости.
Цель PKI состоит в обеспечении надежного и эффективного управления ключами и сертификатами открытых ключей . Пользователи систем, основанных на PKI, должны быть уверены, что в любой момент времени при коммуникации с определенным субъектом они полагаются на открытый ключ, связанный с секретным ключом, владельцем которого является именно этот субъект. Эта уверенность возникает в результате использования сертификатов открытых ключей , связывающих значения открытых ключей с их владельцами. Связывание происходит в результате проверки доверенным УЦ идентичности субъекта и заверения цифровой подписью каждого сертификата открытого ключа.
| Термин на английском языке | Аббревиатура | Термин на русском языке |
|---|---|---|
| Attribute Authority | AA | Атрибутный центр |
| Attribute Certificate | AC | Атрибутный сертификат |
| Certificate | Сертификат | |
| Certification Authority | CA | Удостоверяющий центр (УЦ) |
| Certificate Policy | CP | Политика применения сертификатов (ППС) |
| Certification Practice Statement | CPS | Регламент УЦ |
| End-Entity | EE | Конечный субъект |
| Public Key Certificate | PKC | Сертификат открытого ключа |
| Public Key Infrastructure | PKI | Инфраструктура открытых ключей |
| Privilege Management Infrastructure | PMI | Инфраструктура управления привилегиями |
| Registration Authority | RA | Регистрационный центр (РЦ) |
| Relying Party | Доверяющая сторона | |
| Root CA | Корневой УЦ | |
| Subordinate CA | Подчиненный УЦ | |
| Subject | Субъект | |
| Top CA | УЦ верхнего уровня |
Согласно стандартам PKIX, PKI представляет собой комплекс программного и аппаратного обеспечения, персонала, а также политик и процедур, необходимых для создания, управления, хранения, распространения и аннулирования сертификатов открытых ключей . Компоненты PKI представлены в табл. 15.6 . Сертификат открытого ключа имеет ограниченный период действия , который зафиксирован в содержании сертификата. Поскольку клиент должен иметь возможность самостоятельно проверить подпись сертификата открытого ключа и его срок действия, сертификаты должны открыто публиковаться и распространяться посредством даже ненадежных коммуникаций и систем серверов.
| Компонент | Описание |
|---|---|
| Удостоверяющие центры (УЦ) | Выпускают и аннулируют сертификаты |
| Регистрационные центры (РЦ) | Подтверждают связывание открытых ключей и личностей владельцев сертификатов и других атрибутов |
| Владельцы сертификатов | Подписывают и шифруют электронные документы |
| Клиенты | Проверяют подлинность цифровых подписей и соответствующих цепочек сертификатов при помощи открытого ключа доверенного УЦ |
| Репозитории | Хранят и предоставляют информацию о сертификатах и списках САС |
Существуют два вида криптографических систем: системы с секретным ключом (симметричные) и системы с открытым ключом (несимметричные). Говоря достаточно грубо, но понятно, симметричные системы используют один и тот же ключ для проведения операций шифрования и расшифровки, а несимметричные системы — разные.
В симметричных системах существует проблема распределения секретного ключа защищенным способом: обе стороны, обменивающиеся информацией, должны знать этот ключ, но никто другой этим ключом обладать не должен.
Несимметричные системы устроены так, что в них существует два числа:
- «открытый ключ пользователя A», который используется для зашифрования сообщения, предназначенного пользователю A,
- «закрытый ключ пользователя A», который используется этим пользователем для расшифровки направленных ему сообщений.
Последнее обстоятельство очень важно: пользователь может публиковать свой открытый ключ в общедоступных местах, чтобы любой мог им воспользоваться и зашифровать сообщение для A. Поэтому проблема распределения секретного ключа исчезает.
Пользователь должен держать свой закрытый ключ в секрете от посторонних: хочется, чтобы только пользователь мог расшифровывать сообщения, которые ему были направлены. Более того, требование секретности закрытого ключа очень важно в связи с понятием цифровой подписи, которая обсуждается немного ниже. Забегая вперед, скажем, что секретность закрытого ключа важна и потому что только пользователь должен иметь возможность создавать свою цифровую подпись, которая зависит от значения закрытого ключа.
Достаточно часто закрытый ключ хранится на носителе в зашифрованном виде и расшифровывается только на время произведения каких-то действий, требующих знания закрытого ключа. Это несколько повышает надежность хранения закрытого ключа, но создает неудобство, если закрытый ключ нужен какому-то автоматическому сервису: (как минимум) при каждом запуске этого сервиса нужно вводить пароль для расшифровки ключа.
Еще существуют смарт-карты, которые умеют производить криптографические операции внутри себя, отдавая на выход только результат, но не раскрывая содержимого закрытого ключа. Выкрасть закрытый ключ с правильно реализованной смарт-карты должно быть очень сложно. Закрытый ключ, даже хранящийся на смарт-карте, может быть защищен паролем. Если пароля нет, то любой, кто имеет смарт-карту у себя в руках, может произвести действия, для которых нужно знание закрытого ключа: значение самого закрытого ключа останется секретом, но будет возможнось производить с ним любые предусмотренные действия.
Цифровая подпись
У систем с открытым ключом есть еще одна приятная возможность: пользователь может создавать цифровую подпись, которая будучи поставлена на цифровом документе, может служить гарантией того, что пользователь, а не кто-то другой действительно подписал этот документ.
Схема концептуально проста: пользователь A, используя свой закрытый ключ, производит некоторую операцию над данными, которые он хочет подписать и передает результат вместе с исходными данными любому другому объекту. И этот самый объект, используя только открытый ключ пользователя A, может легко убедиться, что цифровая подпись верна.
Еще раз подчеркнем, что условие доступности данного закрытого ключа только его владельцу, играет очень важную роль: если оно выполняется, то пользователь не может отказаться от своей цифровой подписи. Это называется non-repudiation.
Одно из применений цифровой подписи — аутентификация объекта. Аутентификация — это процесс установления «личности» объекта. Понятно, что если объект может поставить цифровую подпись, то эта подпись может быть проверена, а объект связан со своим открытым ключом. Последний ингридиент, которого не хватает в этой схеме для аутентификации — это момент связывания открытого ключа и самого объекта: мы должны точно знать, кто именно владеет этим открытым ключом.
Удостоверяющий центр (Certification Authority)
Проблема связывания открытого ключа и некоего объекта может решаться разными способами. Один из самых простых подходов — это составить список соответствия открытых ключей и »имен« объектов. В качестве имени может выступать любой идентификатор, например доменное имя машины, полные имя, фамилия и отчество человека и т.д.; проблема уникальности имен, которая обязательно должна появляется — это отдельная трудность, которая обычно решается административными способами типа иерархической системы пространства имен и некоторой системы разрешения конфликтов имен внутри одного подпространства имен. Здесь эта проблема более освещаться не будет.
Но подход, основанный на списке соответствий, имеет очень слабое масштабирование, поскольку эти самые списки должны быть синхронизированы повсюду в мире (вернее, в той части мира, где эти списки используются).
Поэтому были введены понятия X.509-сертификата и удостоверяющего центра. X.509-сертификат (далее, просто сертификат) — это конгломерат из открытого ключа пользователя, пользовательской информации, имени сертификата, называемого Distungiushed Name (DN) и цифровой подписи удостоверяющего центра, которая скрепляет все эти данные друг с другом. То есть появляется возможность связать открытый ключ и DN пользователя, что может служить искомым ингридиентом процесса аутентификации, если в качестве идентификатора пользователя используется Distinguished Name его сертификата. Кстати говоря, у сертификата есть срок действия, который ограничивает срок соответствия, создаваемого удостоверяющим центром.
Естественно, проблема просто переносится в другое место — вместо поддержания большого списка соответствия мы теперь должны держать существенно меньший список открытых ключей удостоверяющих центров. При этом ключу удостоверяющего центра оказывается достаточно большое доверие: удостоверяющий центр подтверждает связь тысяч пользовательких имен с соответствующими открытыми ключами.
Зачем нужна аутентификация? Одного шифрования недостаточно?
Ну, во-первых, аутентификация ценна сама по себе: компьютерным системам нужно аутентифицировать своих пользователей, чтобы потом решать вопрос об авторизации их доступа к различным ресурсам.
Но если вы берете открытый ключ какого-то пользователя и хотите отправить ему зашифрованное сообщение, то вам скорее всего захочется удостовериться, что вы шифруете сообщение правильным открытым ключом, особенно если вы берете этот ключ из общедоступных источников. Ведь атакующий может поместить свой открытый ключ, но при этом указать, что ключ принадлежит вашему адресату. И если вы не аутентифицируете открытый ключ, то атакующий, перехватив ваше зашифрованное сообщение, сможет его без проблем расшифровать.
То есть введение удостоверяющего центра позволяет нам аутентфифцировать обеъкт, который владеет данным сертификатом. Естественно, перед этим мы должны довериться открытому ключу удостоверяющего центра. Это подразумевает две вещи:
- доверие удостоверяющему центру вообще, то есть доверие его репутации,
- уверенность в том, что тот открытый ключ, который к вам попал, действительно является открытым ключом данного удостоверяющего центра.
- звонить в удостоверяющий центр и сверять содержимое открытого ключа по телефону,
- приезжать в сам удостоверяющий центр и забирать открытый ключ на каком-то носителе,
- доверяться тем открытым ключам удостоверяющих центров, которые уже присутствуют в составе какого-то программного пакета
- и множество других способов, которые еще неудобнее уже названных;))
Proxy-сертификаты
Отлично: теперь у нас есть доверенные удостоверяющие центры, их открытые ключи, сертификаты пользователей и их закрытые ключи. Мы можем шифровать сообщения и может создавать цифровые подписи, отказаться от факта производства которых достаточно сложно.
Что же еще? В многокомпонентных системах очень удобно то, что называется Single Sign-On — возможность аутентифицироваться вручную только один раз, а все остальные операции аутентификации будут проводиться автоматически. Обычно это актуально в системах, которые первоначально вас аутентифицируют, а потом система начинает выполнять действия от вашего лица, например, получать данные, запускать задачи, публиковать их результаты и т.д. Это называется делегированием.
Делегирование, основанное на proxy-сертификатах, функционирует следующим образом: после взаимной аутентификации пользователя и сервиса, который в дальнейшем будет работать от имени пользователя, сервис создает новую ключевую пару и отправляет открытый ключ на подпись пользователю. Пользователь подписывает этот открытый ключ так же, как это делает удостоверяющий центр, но при это используется закрытый ключ пользователя. Появившийся в результате сертификат и называется proxy-сертификатом.
После этого сервис, который выступает от имени пользователя, может аутентифицироваться, используя свой (только что созданный) закрытый ключ и сертификат, подписанный пользователем. Процесс аутентификации проходит примерно так.
- Проверяется подпись, созданная сервисом. При этом используется открытый ключ, который был передан вместе с подписью.
- Аутентифицируется открытый ключ, которым была проверена подпись. Сначала проверяется подпись на proxy-сертификате, которая была создана с помощью закрытого ключа пользователя. Это делается с помощью открытого ключа пользователя.
- Таким же образом аутентифицируется открытый ключ самого пользователя, но здесь уже используются данные об удостоверяющем центре.
С помощью такого же механизма, сервис, которому первоначально был выдан proxy-сертификат, может подписать еще один proxy-сертификат, делегировав полномочия пользователя пользователя по цепочке другому сервису. Именно так и реализуется Single Sign-On.
- X.509 Style Guide , написанный Питером Гутманном. Там много технических деталей, но некоторым почитать вполне стоит.
Х.509 -- это другой очень распространённый формат. Все сертификаты Х.509 согласованы с международным стандартом ITU-T X.509; таким образом (теоретически), сертификат Х.509, созданный для одного приложения, может быть использован в любом другом, поддерживающим этот стандарт. На деле, однако, выясняется, что разные компании создали собственные расширения Х.509, многие из которых друг с другом никак не совместимы.
Имея дело с PGP-сертификатом, каждый может выступать в качестве заверителя содержащейся в нём информации (за исключением случаев, когда эта возможность намеренно ограничена системным администратором). Однако, в случае сертификатов Х.509, заверителем может быть только Центр сертификации или некто, специально уполномоченный им. (Имейте в виду, что PGP-сертификаты также в полной мере поддерживают иерархическое структурирование системы доверия, использующее ЦС для удостоверения сертификатов.)
Сертификат Х.509 -- это набор стандартных полей, содержащих сведения о пользователе или устройстве, и их соответствующий открытый ключ. Стардарт Х.509 определяет, какие сведения входят в сертификат и как они кодируются (формат данных).
Сертификат Х.509 содержит следующие сведения:
(Что обозначает Понятное имя субъекта, Электронную почту, Подразделение организации, Органицию и Страну соответственно.)
Существует ряд различий между форматами сертификатов Х.509 и PGP, но наиболее выделяются следующие:
Чтобы получить сертификат Х.509, вы должны попросить ЦС выдать его вам. Вы предоставляется свой открытый ключ, тем самым доказывая, что обладаете соответствующим частным, а также некоторые идентифицирующие вас сведения. Затем вы электронно подписываете эти сведения и отправляете весь пакет -- запрос сертификата -- в Центр сертификации. ЦС выполняет определённый процесс по проверке подлинности предоставленной вами информации и, если всё сходится, создаёт сертификат и возвращает его вам.
Вы можете представить сертификат Х.509, как обычный бумажный сертификат или аттестат с прилепленным к нему общественным ключом. На нём написано ваше имя, а также некоторые сведения о вас, плюс подпись лица, выдавшего сертификат.
Рис. Сертификат Х.509
Вероятно, наибольшая польза от сертификатов Х.509, это их применение в Веб-браузерах.
