УПРАВЛЕНИЕ КРИПТОГРАФИЧЕСКИМИ КЛЮЧАМИ ДЛЯ СИММЕТРИЧНЫХ ШИФРОВ

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

  • - генерация ключей;
  • - хранение ключей;
  • - распределение ключей.

Генерация ключей должна производиться таким образом, чтобы предугадать значение ключа (даже зная, как он будет генерироваться) было практически невозможно. В идеальном случае, вероятность выбора конкретного ключа из множества допустимых равна 1/N, где N — мощность ключевого множества (число его элементов).

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

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

Рекомендуется регулярно проводить замену ключей, используемых в системе. В некоторых случаях вместо замены допустимо использовать процедуру модификации. Модификация кчюча — генерация нового ключа из предыдущего значения с помощью односторонней функции (т. е. такой функции, для которой обратное преобразование вычислить практически невозможно, более подробно см. раздел 2.5). Но в этом случае надо учитывать, что новый ключ безопасен в той же мерс, что и прежний, т. к. противник может повторить всю цепочку модификаций.

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

  • - главный ключ;
  • - ключ шифрования ключей;
  • - ключ шифрования данных (сеансовый ключ).

Сеансовые ключи — нижний уровень иерархии — используются для шифрования данных и аутентификации сообщений. Для защиты этих ключей при передаче или хранении используются ключи шифрования ключей, которые никогда не должны использоваться как сеансовые. На верхнем уровне иерархии располагается главный кчюч (или мастер-ключ). Его применяют для защиты ключей второго уровня. Для защиты главного ключа в системах, использующих только симметричные шифры, приходится применять не криптографические средства, а, например, средства физической защиты данных (ключ записывается на съемный носитель, который после окончания работы изымается из системы и хранится в сейфе, и т. п.). В относительно небольших информационных системах может использоваться двухуровневая иерархия ключей (главный и сеансовые ключи).

При распределении ключей необходимо выполнить следующие требования:

  • - обеспечить оперативность и точность распределения ключей;
  • - обеспечить секретность распределения ключей.

Распределение ключей может производиться:

  • - с использованием одного или нескольких центров распределения ключей (централизованное распределение);
  • - прямым обменом сеансовыми ключами между пользователями сети (децентрализованное распределение ключей).

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

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

Протокол Kerberos был разработан в Массачусетском технологическом институте в середине 1980-х годов и сейчас являегся фактическим стандартом системы централизованной аутентификации и распределения ключей симметричного шифрования. Поддерживается операционными системами семейства Unix, Windows (начиная с Win- dows’2000), есть реализации для Mac OS.

Протокол Kerberos обеспечивает распределение ключей симметричного шифрования и проверку подлинности пользователей, работающих в незащищенной сети. Реализация Kerberos — это программная система, построенная по архитектуре «клиент-сервер». Клиентская часть устанавливается на все компьютеры защищаемой сети, кроме тех, на которые устанавливаются компоненты сервера Kerberos. В роли клиентов Kerberos могут, в частности, выступать и сетевые серверы (файловые серверы, серверы печати и т. д.).

Серверная часть Kerberos называется центром распределения ключей (англ. «Key Distribution Center», сокр. KDC) и состоит из двух компонент:

- сервер аутентификации (англ. «Authentication Server», сокр.

AS);

- сервер выдачи разрешений (англ. «Ticket Granting Server», сокр. TGS).

Каждому субъекту сети сервер Kerberos назначает разделяемый с ним ключ симметричного шифрования и поддерживает базу данных субъектов и их секретных ключей. Схема функционирования протокола Kerberos представлена на рис. 2.14.

Протокол Kerberos

Рис. 2.14. Протокол Kerberos

Пусть клиент С собирается начать взаимодействие с сервером SS (от англ. «Service Server» — сервер, предоставляющий сетевые сервисы). В несколько упрощенном виде протокол предполагает следующие шаги [ 10,111-

1) . C->AS: {с}.

Клиент С посылает серверу аутентификации AS свой идентификатор с (идентификатор передается открытым текстом).

2) . AS->C: {{TGT}Kas_TCs, Kc_tgs}K0 где Кс— основной ключ С;

Kc_tgs — ключ, выдаваемый С для доступа к серверу выдачи разрешений TGS;

(TGTj -билет на доступ к серверу выдачи разрешений (англ.

«Ticket Granting Ticket»); {TGT)={c, tgs, t, p, Kc_tgsЛ где tgs — идентификатор сервера выдачи разрешений, ц — отметка времени, р — период действия билета. Запись {...}КХ здесь и далее означает, что содержимое фигурных скобок зашифровано на ключе Кх.

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

Получить доступ к содержимому билета TGT не может не только нарушитель, но и клиент С, так как билет зашифрован на ключе, который распределили между собой сервер аутентификации и сервер выдачи разрешений.

3) . C->TGS: {TGT)KAs_tGs, IAut j Kc_tcs> HD),

где {Aut} — аутентификационный блок — Aut = {c,b}, h — метка времени; ID — идентификатор запрашиваемого сервиса (в частности, это может быть идентификатор сервера SS).

Клиент С на этот раз обращается к серверу выдачи разрешений TGS. Он пересылает полученный от AS билет, зашифрованный на ключе Kas_tgs, и аутентификационный блок, содержащий идентификатор с и метку времени, показывающую, когда была сформирована посылка.

Сервер выдачи разрешений расшифровывает билет TGT и получает из него информацию о том, кому был выдан билет, когда и на какой срок, ключ шифрования, сгенерированный сервером AS для взаимодействия между клиентом С и сервером TGS. С помощью этого ключа расшифровывается аутентификационный блок. Если метка в блоке совпадает с меткой в билете, это доказывает, что посылку сгенерировал на самом деле С (ведь только он знал ключ Kc_tgs и мог правильно зашифровать свой идентификатор). Далее делается проверка времени действия билета и времени оправления посылки 3. Если проверка проходит, и действующая в системе политика позволяет клиенту С обращаться к клиенту SS, тогда выполняется шаг 4.

4) . TGS->C: /{TGS}Ktgs_ss

где Kc_ss — ключ для взаимодействия С и 55, {TGS} — от англ. «Ticket Granting Service» — билет для доступа к 55 (обратите внимание, что такой же аббревиатурой в описании протокола обозначается и сервер выдачи разрешений). {TGSj -{c,ss,t2,p2, Kc_ss }?

Сейчас сервер выдачи разрешений TGS посылает клиенту С ключ шифрования и билет, необходимые для доступа к серверу 55. Структура билета такая же, как на шаге 2: идентификатор того, кому выдали билет; идентификатор того, для кого выдали билет; отметка времени; период действия; ключ шифрования.

5) . С->55: (TGS}KTGs_ss, (Ам2) Kc_ss, где Aut2-(c,t4}.

Клиент С посылает билет, полученный от сервера выдачи разрешений, и свой аутентификационный блок серверу 55, с которым хочет установить сеанс защищенного взаимодействия. Предполагается, что 55 уже зарегистрировался в системе и распределил с сервером TGS ключ шифрования KTcs_ss? Имея этот ключ, он может расшифровать билет, получить ключ шифрования KC_SS и проверить подлинность отправителя сообщения.

6) . SS->C: /t4+l}Kcjs

Смысл последнего шага заключается в том, что теперь уже 55 должен доказать С свою подлинность. Он может сделать это, показав, что правильно расшифровал предыдущее сообщение. Вот поэтому 55 берет отметку времени из аутентификационного блока С, изменяет ее заранее определенным образом (увеличивает на 1), шифрует на ключе Kc ss и возвращает С.

Если все шаги выполнены правильно, и все проверки прошли успешно, то стороны взаимодействия С и 55, во-первых, удостоверились в подлинности друг друга, а во-вторых, получили ключ шифрования для защиты сеанса связи — ключ Kc_ss-

Нужно отметить, что в процессе сеанса работы клиент проходит шаги 1 и 2 только один раз. Когда нужно получить билет на доступ к другому серверу (назовем его 551), клиент С обращается к серверу выдачи разрешений TGS с уже имеющимся у него билетом, т. е. протокол выполняется начиная с шага 3.

При использовании протокола Kerberos компьютерная сеть логически делится на области действия серверов Kerberos. Kerberos- область — это участок сети, пользователи и серверы которого зарегистрированы в базе данных одного сервера Kerberos (или в одной базе, разделяемой несколькими серверами). Одна область может охватывать сегмент локальной сети, всю локальную сеть или объединять несколько связанных локальных сетей. Схема взаимодействия между Kerberos-областями представлена на рис. 2.15.

Взаимодействие между Kerberos-областями

Рис. 2.15. Взаимодействие между Kerberos-областями

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

После установки взаимных соглашений, клиент из области 1 (пусть это будет А) 0 может установить сеанс взаимодействия с клиентом из области 2 (например, К2). Дш этого Ки должен получить у своего сервера выдачи разрешений билет на доступ к Kerberos- сервсру, с клиентом которого он хочет установить взаимодействие (на рис. 2.15 это сервер KDC2). Полученный билет содержит отметку о том, в какой области зарегистрирован владелец билета. Билет шифруется на ключе, разделенном между серверами KDC1 и KDC2. При успешной расшифровке билета удаленный Kerberos-сервер может быть уверен, что билет выдан клиенту Kerberos-области, с которой установлены доверительные отношения. Далее протокол работает, как обычно.

Кроме рассмотренных, Kerberos предоставляет еще ряд дополнительных возможностей. Например, указанный в структуре билета параметр р (период времени) задается парой значений «время начала действия» — «время окончания действия», что позволяет получать билеты отложенного действия.

Имеегся тип билега «с правом передачи», что позволяет, например, серверу выполнять действия от имени обратившегося к нему клиента.

 
Посмотреть оригинал
< Пред   СОДЕРЖАНИЕ   ОРИГИНАЛ     След >