Распределение ключей в асимметричных криптосистемах

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

Задача защиты ключей от подмены решается с помощью сертификатов. Сертификат позволяет удостоверить заключённые в нём данные о владельце и его открытый ключ подписью какого-либо доверенного лица. В централизованных системах сертификатов (например PKI) используются центры сертификации, поддерживаемые доверенными организациями. В децентрализованных системах (например PGP) путём перекрёстного подписывания сертификатов знакомых и доверенных людей каждым пользователем строится сеть доверия.

Инфраструктура безопасности для распространения открытых ключей, управления электронными сертификатами и ключами пользователей получила название инфраструктуры открытых ключей - Public Key Infrastructure (PKI).

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

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

Управлением ключами занимаются центры распространения сертификатов. Обратившись к такому центру пользователь может получить сертификат какого-либо пользователя, а также проверить, не отозван ли ещё тот или иной открытый ключ.

Управление открытыми ключами может быть организовано с помощью оперативной или автономной службы каталогов. Основными проблемами являются аутентичность, целостность и достоверность. Аутентичность позволяет убедиться, что это ключ именно этого пользователя.

Во всех случаях обмена ключами должна быть обеспечена подлинность сеанса связи, которая обеспечивается с помощью: механизма «запрос-ответ» (процедура «рукопожатие» = установка виртуального канала); механизма отметки времени.

Задача распределения ключей сводится к построению протокола распределения, обеспечивающего:

1. Взаимное подтверждение подлинности участников сеанса.
2. Подтверждение достоверности сеанса механизмом «запрос-ответ» или отметки времени.
3. Использование минимального числа сообщений при обмене ключами.
4. Возможность исключения злоупотребления со стороны ЦРК (вплоть до отказа от его услуг).
5. Целесообразно отделить процедуру подтверждения подлинности партнеров от собственно процедуры распределения ключей.

Метод достижения одновременно аутентичности и целостности при распределении открытых ключей заключается в использовании сертификатов.

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

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

Например: сертификат открытого ключа для пользователя А, обозначаемый С_А, содержит отметку времени Т, идентификатор Id_A, открытый ключ K_A, зашифрованный секретным ключом ЦРК К_црк :

С_А = Е К_црк (Т, Id_A, K_A)

Отметка времени Т используется для подтверждения актуальности сертификата и тем самым предотвращает повторы прежних сертификатов. Секретный ключ К_црк известен только менеджеру ЦРК, а открытый ключ ЦРК известен всем абонентам

Центр сертификации или Удостоверяющий центр (УЦ, англ. Certification authority, CA) — это организация или подразделение организации, которая выпускает сертификаты ключей электронной цифровой подписи, это компонент глобальной службы каталогов, отвечающий за управление криптографическими ключами пользователей.

Открытые ключи и другая информация о пользователях хранится удостоверяющими центрами в виде цифровых сертификатов, имеющих следующую структуру:

• серийный номер сертификата;

• объектный идентификатор алгоритма электронной подписи;

• имя удостоверяющего центра;

• срок годности (время действия сертификата);

• имя владельца сертификата (имя пользователя, которому принадлежит сертификат);

• открытые ключи владельца сертификата (ключей может быть несколько);

• объектные идентификаторы алгоритмов, ассоциированных с открытыми ключами владельца сертификата;

• электронная подпись, сгенерированная с использованием секретного ключа удостоверяющего центра (подписывается результат хэширования всей информации, хранящейся в сертификате).

Программное обеспечение удостоверяющего центра обеспечивает следующую функциональность:

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

— Первое издание сертификата подписи абонентов происходит в УЦ вместе с генерацией секретного ключа для него.

— Издание и регистрация сертификатов ЭЦП по запросу абонентов сети. Запрос на сертификат представляет собой шаблон сертификата, содержащий информацию об абоненте, его новый открытый ключ подписи, предполагаемый срок действия сертификата, а также другие параметры, соответствующие стандарту X.509. Запрос может быть зарегистрирован или автоматически или в результате действий администратора УЦ. Запрос может быть отклонен. После заполнения полей сертификата сертификат через Центр управления отправляется к пользователю на компьютер.

— Отзыв сертификатов, приостановление действия сертификатов, возобновление действия сертификатов ЭЦП абонентов сети. Эти действия выполняются администратором УЦ. Справочник отозванных сертификатов рассылается абонентам сети.

Регистрация справочников сертификатов ЭЦП главных абонентов других УЦ.

— Регистрация справочников отозванных сертификатов ЭЦП из других УЦ.

— Издание и регистрация сертификатов ЭЦП для внешних пользователей выполняется только по запросу из Центра регистрации. Запрос может быть зарегистрирован или отклонен.

— Отзыв сертификатов, приостановление действия сертификатов, возобновление действия сертификатов ЭЦП внешних пользователей может происходить по запросу из ЦР, или самим Администратором УЦ без запроса из ЦР. Справочники отозванных сертификатов рассылаются по узлам сети.

— Просмотр запросов и сертификатов ЭЦП. В программе УЦ возможен просмотр любых запросов, сертификатов, действующих списков отзыва, сохранение их в файл или вывод на печать.

— Сервисные функции УЦ.

УЦ информирует администратора об истечении сроков действия различных сертификатов за заданное число дней до этого срока путем формирования соответствующих списков.

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

Обеспечивает различные режимы функционирования УЦ.

· Российские удостоверяющие центры

· Удостоверяющий Центр ЗАО "ПФ "СКБ Контур"

· Удостоверяющий Центр ФГУП НИИ "Восход"

· Удостоверяющий Центр DIP

· ООО Межрегиональный Удостоверяющий Центр

· НП "Национальный Удостоверяющий центр"

· ЗАО «АНК»

· ООО ПНК

· ЗАО Удостоверяющий Центр (Нижний Новгород)

· ЗАО Удостоверяющий Центр (Санкт-Петербург)

· ООО "Компания «Тензор»

· ОАО «Электронная Москва»

· Центр сертификации «Стандарт Тест»

· Всероссийский центр сертификации

· Удостоверяющий центр ЗАО "Сервер-Центр" (Владивосток)

· Удостоверяющий центр "ДСЦБИ "МАСКОМ" (Хабаровск )

Аутентификация при помощи сертификатов

В том случае, когда пользователи имеют сертификаты открытых ключей, необходимость в ЦРК отпадает. Это не означает, что отпадает необходимость в доверии и третьих сторонах; просто доверенной третьей стороной становится УЦ. Однако УЦ не участвует в обмене протоколами, и в отличие от ситуации с ЦРК, если УЦ недоступен, аутентификация по-прежнему может быть выполнена.

Аутентификацию при помощи сертификатов обеспечивают несколько распространенных протоколов, в частности, наиболее известный и широко распространенный протокол Secure Socket Layer (SSL), который применяется практически в каждом web-браузере. Помимо него применяются протоколы Transport Layer Security (TLS), Internet Key Exchange (IKE), S/MIME, PGP и Open PGP. Каждый из них немного по-своему использует сертификаты, но основные принципы - однии те же.

Рисунок иллюстрирует типичный обмен сообщениями при аутентификации на базе сертификатов, использующий ЭЦП. Обмен соответствует стандарту аутентификации субъектов на основе криптографии с открытыми ключами. Во многих протоколах предусматривается, что клиент направляет запрос серверу для того, чтобы инициировать аутентификацию. Такой подход, характерный, например, для дополнений аутентификации и шифрования к протоколу Internet File Transfer Protocol, гарантирует, что и пользователь, и сервер поддерживают один и тот же механизм аутентификации. Некоторые протоколы не требуют этого подготовительного шага.

Если сервер В поддерживает метод аутентификации, запрашиваемый пользователем А, то начинается обмен сообщениями. Сообщение Token ID уведомляет о том, что будет выполняться взаимная аутентификация, а также содержит номер версии протокола и идентификатор протокола. Хотя этот идентификатор не обязателен, он намного упрощает процедуру и поэтому обычно используется. Пользователь А ожидает сообщение Token ВА1 от сервера В.

Идентификатор протокола в Token ID позволяет пользователю А удостовериться, что сервер В отправляет ожидаемое сообщение. Token ВА1 состоит только из случайного числа ran B, это - своего рода запрос, корректным ответом должна быть цифровая подпись числа ran B. Пользователь А подписывает ответ и отправляет свой сертификат ключа подписи, для того чтобы сервер В при помощи открытого ключа мог выполнить валидацию подписи.

Пользователь А подписывает последовательность из трех элементов: свой запрос ran A, запрос сервера ran B и имя сервера name B. Получив ответ Token АВ от пользователя А, сервер В проверяет, совпадает ли значение ran B с соответствующим значением в сообщении Token ВА1, а по значению name В устанавливает, действительно ли пользователь А желает пройти аутентификацию сервера В. Если какая-либо из проверок дает отрицательный результат, то и аутентификация завершается неудачно. В противном случае сервер В проверяет подлинность сертификата пользователя А и его цифровую подпись, если сертификат и подпись валидны, то аутентификация пользователя А сервером В прошла успешно. Ответ сервера В пользователю А завершает взаимную аутентификацию.

Ответ сервера Token ВА2 состоит из заверенной цифровой подписью последовательности трех элементов: ran A, ran B и name A, где ran A - запрос, сгенерированный А, ran B - исходный запрос сервера В, а name A - имя пользователя А. Получив ответ сервера, пользователь А убеждается, что ran A имеет то же самое значение, что и в сообщении Token АВ, а проверяя значение name A - что сервер В намерен аутентифицировать именно его (пользователя А). Если какая-либо из проверок дает отрицательный результат, то и аутентификация завершается неудачно. В противном случае пользователь А проверяет подлинность сертификата сервера В и его цифровой подписи. Если они валидны, то пользователь А аутентифицировал сервер В, и взаимная аутентификация выполнена.

Итак, механизмы аутентификации при помощи сертификатов поддерживают аутентификацию в открытой сети, на многих удаленных серверах, и обеспечивают взаимную аутентификацию. В отличие от системы Kerberos. протоколы аутентификации на базе сертификатов не требуют активного участия третьих сторон. Для успешной аутентификации должны быть доступны только пользователь и сервер.

Ответ сервера Token ВА2 состоит из заверенной цифровой подписью последовательности трех элементов: ran A, ran B и name A, где ran A - запрос, сгенерированный А, ran B - исходный запрос сервера В, а name A - имя пользователя А. Получив ответ сервера, пользователь А убеждается, что ran A имеет то же самое значение, что и в сообщении Token АВ, а проверяя значение name A - что сервер В намерен аутентифицировать именно его (пользователя А). Если какая-либо из проверок дает отрицательный результат, то и аутентификация завершается неудачно. В противном случае пользователь А проверяет подлинность сертификата сервера В и его цифровой подписи. Если они валидны, то пользователь А аутентифицировал сервер В, и взаимная аутентификация выполнена.

Итак, механизмы аутентификации при помощи сертификатов поддерживают аутентификацию в открытой сети, на многих удаленных серверах, и обеспечивают взаимную аутентификацию. В отличие от системы Kerberos. протоколы аутентификации на базе сертификатов не требуют активного участия третьих сторон. Для успешной аутентификации должны быть доступны только пользователь и сервер.

Ответ сервера Token ВА2 состоит из заверенной цифровой подписью последовательности трех элементов: ran A, ran B и name A, где ran A - запрос, сгенерированный А, ran B - исходный запрос сервера В, а name A - имя пользователя А. Получив ответ сервера, пользователь А убеждается, что ran A имеет то же самое значение, что и в сообщении Token АВ, а проверяя значение name A - что сервер В намерен аутентифицировать именно его (пользователя А). Если какая-либо из проверок дает отрицательный результат, то и аутентификация завершается неудачно. В противном случае пользователь А проверяет подлинность сертификата сервера В и его цифровой подписи. Если они валидны, то пользователь А аутентифицировал сервер В, и взаимная аутентификация выполнена.

Итак, механизмы аутентификации при помощи сертификатов поддерживают аутентификацию в открытой сети, на многих удаленных серверах, и обеспечивают взаимную аутентификацию. В отличие от системы Kerberos. протоколы аутентификации на базе сертификатов не требуют активного участия третьих сторон. Для успешной аутентификации должны быть доступны только пользователь и сервер.

Схема обмена

Дата добавления: 2014-01-06