8.6. Пример — sesame

Давайте теперь рассмотрим другую систему защиты, которая похожа на Kerberos, но в ней используется комбинация криптографии с открытым ключом и общих секретных ключей. Проект SESAME был начат по совместной инициативе не­скольких крупных европейских компаний с целью разработки стандартов защи­ты открытых систем. SESAME — это акроним слов Secure European System for Application in a Multi-vendor Environment (Европейская система защиты приложе­ний, работающих в разнородной среде). Первая реализация SESAME была созда­на в 1991 году, четвертая и наиболее известная существует с 1995 года и известна также под названием SESAME V4. Мы начнем с обзора основных компонентов, затем обсудим процесс авторизации, выполняемый при помощи сертификатов атрибутов. Вместо того чтобы рассматривать в деталях все алгоритмы, мы сосре­доточим наше внимание на общих вопросах взаимодействия между компонента­ми, которые иллюстрируют архитектуру защищенных систем. Обзор системы SESAME можно найти в [342].

8.6.1. Компоненты системы sesame

SESAME может рассматриваться как система клиент-сервер, в которой клиенты имеют доступ к приложениям, выполняющимся на удаленных серверах. Подоб­ная организация служит причиной разделения компонентов SESAME на три группы, как показано на рис. 8.39. Эти три группы, соответственно — общие ком­поненты защиты, компоненты защиты клиента и компоненты защиты сервера. Их мы и обсудим далее.

Общие компоненты защиты

Общие компоненты защиты отвечают за аутентификацию, авторизацию и рас­пространение ключей. Эти компоненты обычно размещаются на отдельной ма­шине, известной под названием сервера защиты домена (Domain Security Server, DSS).

Сервер аутентификации (Authentication Server, AS) отвечает за аутентифика­цию пользователей (людей) и приложений (программ). В случае приложений аутентификация происходит при помощи секретных ключей, хранимых в отдель­ной базе данных, называемой информационной базой управления защитой (Security Management Information Base, SMIB). База SMIB реализована в виде набора от­дельных файлов и хранит также информацию, относящуюся к другим компонен­там, входящим в сервер защиты домена. Пользователи аутентифицируются при помощи секретного ключа, порождаемого, как и в системе Kerberos, из пароля, введенного пользователем. Однако если пользователь имеет закрытый ключ, то для аутентификации используется этот ключ.

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

Основное назначение сервера атрибутов привилегий (Privilege Attribute Server, PAS) — выдавать сертификаты атрибутов со списками прав доступа клиента к приложениям. Возвращаясь к Алисе, это означает, что она должна передать сер­веру PAS полученный при аутентификации талон.

Алиса также посылает PAS запрос на определенные права доступа к одному или более приложениям, с которыми она собирается работать. Этот запрос со­провождается так называемой криптографической пломбой (cryptographic seal), которая представляет собой хэш, рассчитанный, исходя из запрашиваемого спи­ска прав [168]. Пломба позволяет PAS проверить, не подправил ли кто-то этот список. Сам список не шифруется. После получения запроса PAS проверяет, можно ли предоставить Алисе запрашиваемые права, и если это так, собирает их в сертификате атрибутов привилегий (Privilege Attribute Certificate, РАС). Более детально мы поговорим о РАС чуть ниже. Кроме возвращения сертификата РАС (который также запечатан), сервер атрибутов также создает новый сеансовый ключ, который Алиса может использовать для связи с KDS. Эта информация со­храняется в еще одном талоне.

Отметим, что если никакого общего ключа для связи между клиентом и сер­вером в дальнейшем не требуется, Алиса может не связываться с сервером рас­пространения ключей (Key Distribution Server, KDS). Однако при работе с прило­жениями, использующими симметричные ключи, Алиса может задействовать свой талон KDS для того, чтобы потребовать от KDS создать сеансовые ключи для организации защищенной связи с серверными приложениями. В SESAME сервер KDS может быть реализован с помощью сервера TGS системы Kerberos.

Компоненты клиента

В системе SESAME имеется три клиентских компонента защиты. Во-первых, для конечного пользователя SESAME предоставляет программу для входа в систему, которая называется спонсор пользователя (user sponsor). Эта программа позволя­ет пользователю входить в систему, выходить из нее и изменять роли. Она вы­полняется как отдельное приложение и предполагает, что пользователь уже рабо­тает в локальной операционной системе. При входе пользователь должен ввести пароль, по которому будет создан общий секретный ключ, используемый для свя­зи с сервером защиты домена. Эта процедура входа соответствует аналогичной процедуре системы Kerberos. С другой стороны, пользователь может иницииро­вать строгий вход, в этом случае будет взят и использован, как описано выше, ло­кально хранящийся закрытый ключ пользователя.

В зависимости от той роли, с которой пользователь подсоединился к системе, он получает определенные стандартные привилегии, позднее, после аутентифи­кации, передаваемые в форму РАС. Также соответствующие привилегии можно запросить во время соединения.

Клиент доступа к аутентификации и привилегиям (The Authentication and Privilege Access Client, АРА Client) — это не что иное, как библиотека, содержащая простые процедуры, которые предоставляют пользователю интерфейс, а клиент­ским приложениям — доступ к серверу защиты домена. Отметим, что эта биб­лиотека при необходимости поддерживает также аутентификацию клиентских приложений.

Третий компонент — это система управления контекстом защиты (Secure Association Context Management, SACM). Этот компонент отвечает за инициали­зацию и поддержку информации, необходимой для клиента при связи с выпол­няющимся на сервере приложением. Так, например, SACM, как и РАС, может локально сохранять сеансовые ключи, полученные при входе пользователя в сис­тему и пр. Таким образом, SACM позволяет клиентским приложениям совмест­но использовать любую информацию по защите, необходимую для связи с сер­верными приложениями.

Функциональность SACM традиционно поддерживается многими системами защиты, в том числе и SESAME, и может быть реализована в разных системах по-разному. Поэтому вместо того, чтобы поддерживать специальный интерфейс, SACM реализует стандартный обобщенный интерфейс программ службы защиты (Generic Security Service Application Program Interface, GSS-API), определенный в [267].

Компоненты сервера

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

SACM сервера отвечает за передачу в систему проверки РАС (РАС Validation Facility, PVF) входящей информации, связанной с защитой. PVF извлекает из входящих запросов всю необходимую информацию и проверяет ее. Так, напри­мер, она может расшифровать сообщение и извлечь из него сеансовый ключ или после проверки подписи сертификата РАС извлечь из него права доступа. Или, например, после того как система PVF идентифицирует пользователя, она мо­жет передать информацию обратно в систему SACM, которая, в свою очередь, передаст клиенту сообщение для аутентификации сервера.

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