Добавил:
Upload Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:
KMZI_otvety.doc
Скачиваний:
13
Добавлен:
17.04.2019
Размер:
3.29 Mб
Скачать

Вопрос 48 pki: классическая конструкция, сертификат открытого ключа. Формат сертификата открытого ключа согласно X.509.

Д ля того чтобы обеспечить возможность проверки достоверности открытого ключа предложена технология сертификатов. Сертификат открытого ключа – цифровой документ, который связывает открытый ключ с его владельцем (человеком, приложением или сервисом). Этот сертификат создается и подписывается центром доверия, называемым Удостоверяющим центром (УЦ, Центром сертификации, Certificate Authority, CA) с помощью его закрытого ключа цифровой подписи.

С ростом числа приложений, использующих криптографию, с увеличением количества ее пользователей возрастает количество разнородных сертификатов. Требуется единообразная организация сервиса управления сертификатами: Public Key Infrastructure, PKI. Инфраструктура открытых ключей – это набор служб, которые призваны обеспечить работу криптографических методов с открытыми ключами.

Структура PKI, основанная на сертификатах формата X.509 [0].

Сертификация является основной функцией всех PKI. Это есть средство публикации значения открытого ключа и информации, относящейся к нему.

Наиболее традиционно под термином цифровой сертификат понимается цифровой документ, который связывает открытый ключ с именем его владельца, иногда он называется сертификатом тождества (Identity Certificate) или сертификатом открытого ключа. Связь открытого ключа с именем владельца закрепляется с помощью электронной цифровой подписи, которую ставит Удостоверяющий центр.

Вопрос 49 Многоуровневые pki. Иерархия удостоверяющих центров, корневой удостоверяющий центр.

Некоторые PKI используют общую иерархию, показанную на рисунке 1. На этом рисунке кругами показаны Удостоверяющие центры, а прямоугольниками – конечные пользователи. Стрелками указываются объекты сертификации. В общей иерархии каждый УЦ удостоверяет своих родителей и детей. На рисунке 2 штриховыми стрелками показаны перекрестные сертификаты, которые не допустимы в строгих иерархиях.

Рисунок 3 – Пример общей иерархии с перекрестными сертификатами

Некоторые PKI используют вариант общей иерархии известный как нисходящая иерархия, показанная на рисунке 4. Здесь УЦ удостоверяют только свои дочерние (в смысле дерева иерархии) узлы, и УЦ верхнего уровня является началом всех путей сертификации.

Также существуют PKI, не имеющие структуры. Здесь каждый УЦ является собственным корневым УЦ.

Рисунок 5 – Нисходящая иерархия УЦ

Функции глобальной PKI должны пропорционально увеличиваться с увеличением числа пользователей. При этом пути сертификации должны быть легко доступными и не должны быть слишком длинными. Средняя длина пути в глобальной сети сертификации составляет 6 или 7. Доступ к УЦ при этом может быть затруднён.

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

Общая иерархия позволяет любому УЦ быть корневым. В общей иерархии большое количество путей сертификации проходит через УЦ A. Это вынуждает пользователей PKI неявно доверять УЦ А. Если секретный ключ УЦ А был когда-либо скомпрометирован, то это может использоваться для подлога сообщения между объектами, которые полагаются на путь сертификации, включающий УЦ A. Так как много путей сертификации проходит через A, он становится очень привлекательной целью для атак.

Пути сертификации в общей иерархии, как правило, довольно длинные. При перекрестной сертификации сокращаются длины путей, но увеличивается сложность нахождения пути сертификации.

Ф ормат сертификата открытого ключа

Certificate version - версия стандарта Х.509, которой соответствует сертификат; Certificate serial number- уникальный номер, приписываемый сертификату Удостоверяющим центром при издании; CA’s signature algorithm ID -идентификатор алгоритма, который УЦ использовал для подписи сертификата; CA’s X.500 name имя УЦ, выпустившего данный сертификат (в формате Х.500); Validity period срок действия сертификата, то есть время, в течение которого УЦ обязуется отслеживать статус сертификата; Subject’s X.500 name имя владельца сертификата в формате Х.500; Subject’s public key information информация, содержащая открытый ключ владельца сертификата и идентификатор алгоритма, с которым этот ключ используется; Issuer unique identifier строка бит, вычисляемая на основе имени УЦ в формате Х.500; это поле вводится для однозначной идентификации УЦ,; Subject unique identifier строка бит, однозначно идентифицирующая владельца сертификата; действительно только для версии 2. В версии 3 были проведены значительные изменения в процедуре издания сертификатов и в формате списков отозванных сертификатов (CRL). Х.509 получила инструменты, способные самостоятельно определять содержание сертификата. Были введены средства, позволяющие ограничить сертификационные пути. Сертификаты Х.509 теперь могут содержать дополнительную информацию. Это достигается с помощью так называемых расширений. (Они располагаются между Subject unique identifier и ЦП, и содержат поля: тип, критичность, значения). С помощью введённых расширений стало возможно выполнение новых функций. Пример: Key Usage Это расширение определяет цель использования открытого ключа, содержащегося в сертификате. Subject alternative name Определяет дополнительное имя владельца сертификата.