Петров А.А. Комп без-ть

Протоколы распределения и управления ключевой информацией

НИ

и технически (например, с помощью физически защищенных хранилищ ключей).

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

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

•с использованием масок ключей и изменяющихся ключей;

•на основе подтверждения подлинности ключей;

•с использованием контрольных векторов.

Маски ключей и изменяющиеся ключи

Маска ключа представляет собой битовый вектор или структуру, которая добавляется к ключу и зашифровывается вместе с ним, появляясь в откры­ том виде только в случае расшифрования ключа. Такая маска, кроме кон­ троля, решает также проблему, связанную с криптоанализом ключа.

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

Подтверждение подлинности ключей

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

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

152 Аспекты создания и применения криптографических протоколов

Контрольный вектор

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

Междоменные отношения

Область, обслуживаемая одним доверенным сервером, обычно называется

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

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

Ситуация осложняется, когда два пользователя (А и В) хотят, напри­ мер, установить защищенный канал передачи данных и при этом нахо­ дятся в разных доменах (Б Л и О в), то есть обслуживаются разными дове­ ренными серверами (Т А и Т в). Для этого необходимо, чтобы:

•пользователи разделяли знание симметричного ключа друг с другом;

•пользователи доверяли открытым ключам друг друга.

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

•серверы Т А и Т в имеют доверенные отношения, выражающиеся в раз­ делении знания ключей или в доверенных взаимоотношениях (А, Т А), (Т А, Т в) и (Т в, В);

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

Протоколы распределения и управления ключевой информацией

153

На рис. 2.9 показана общая схема организации междоменных отноше­ ний, при этом содержимое передаваемых сообщений может иметь различ­ ное значение в зависимости от того, на каких ключах (асимметричных или симметричных) построены взаимоотношения.

Рис. 2.9 Схема

доверенных отношений между пользователями разныхдоменов

С использованием симметричных ключей

Если взаимоотношения серверов построены на основе схем распределения симметричных ключей, то последовательность передачи сообщений, пред­ ставленная на рис. 2.10, будет иметь следующие значения:

1. Пользователь А передает запрос серверу Т А на выработку ключа

с пользователем В.

2.Т Л и Т в распределяют между собой симметричный сеансовый ключ К АВ.

3.Т А и Т в передают ключ К АВ пользователям А и В с обеспечением аутен­ тификации и конфиденциальности.

4.Пользователи А и В устанавливают защищенный канал с одновремен­ ной аутентификацией друг друга.

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

С использованием асимметричных ключей

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

1. А запрашивает от Т А открытый ключ пользователя В.

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

154Аспекты создания и применения криптографических протоколов

3.Т А передает пользователю А открытый ключ пользователя В с обеспе­ чением аутентификации.

4.Пользователь А, применяя данный ключ, устанавливает с В защищен­ ный канал передачи данных.

Модели междоменных отношений с использованием нескольких центров сертификации

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

Цепочки сертификатов и сертификационные пути

Цепочки сертификатов создаются в случае, если пользователь А, доверяющий одному СА (открытому ключу данного СА), желает проверить подлинность сертификата пользователя В, подписанного СА, которому пользователь А не доверяет. При этом между данными С А нет доверенных отношений. В этом случае находятся другие СА, которые имеют доверенные отноше­ ния с С А пользователей А и В. Далее устанавливается так называемый

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

Пусть пользователь А доверяет С А 5 (владеет открытым ключом Р5 дан­ ного С А ) и желает проверить подлинность открытого ключа пользователя В, который подписан при помощи С А3. Предположим, что существует путь аутентификации (С А 5, СА4, СА3), тогда обозначая С А 5{С А 4} как сертифи­ кат открытого ключа С А4, выданный С А5, выведем следующую цепочку сертификатов (САДСАД, С А4{С А 3}). Пользователь А сначала проверяет сер­ тификат СА5{С А 4}, получая аутентичный открытый ключ Р4, принадлежа­ щий С А4, затем, используя Р 4, проверяет сертификат С А4{С А 3} и получает аутентичный ключ Р 3, принадлежащий СА. В итоге пользователь А может проверить сертификат С А3, выданный на ключ Р в.

Изолированные друг от друга домены

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

Протоколы распределения и управления ключевой информацией

155

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

Модель доверительных отношений, построенная по принципу строгой иерархии

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

а)

б)

в)

Рис. 2.10. Схемы организации междоменных отношений

156 Аспекты создания и применения криптографических протоколов

имеет и доверяет только открытому ключу СА, находящемуся в корне де­ рева сертификации. Несмотря на тот факт, что сертификат открытого клю­ ча пользователя Е} подписывается СА,, данный пользователь доверяет только С А5, находящемуся в корне. Доверительные отношения между СА, и пользователем Е{ устанавливаются только через С А5 и через лежащие между ними С А (в нашем случае - С А 3) на основе использования цепочки сертификатов. Недостатки данного метода заключаются в следующем:

•любые доверительные отношения в системе строятся через корневой узел;

•цепочка сертификатов создается даже в том случае, когда два пользо­ вателя зарегистрированы в одном СА;

•в случае глубокого дерева цепочка сертификатов будет иметь большую длину.

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

Реверсивные сертификаты и модель доверия

на основе ориентированного графа

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

Модель доверительных отношений на основе ориентированного графа яв­ ляется примером распределенной модели доверительных отношений, а при­ веденные схемы являются моделями децентрализованных доверительных

Специфические криптографические протоколы

157

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

2.4. Специфические криптографические протоколы

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

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

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

•безопасные выборы;

•совместная подпись контракта;

•групповая подпись;

•доверенная подпись;

•неоспариваемая подпись;

•слепая подпись;

•забывающая передача;

•подбрасывание монеты по телефону;

•разделение знания секрета.

2.4Л . Безопасные выборы

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

158______ Аспекты создания и применения криптографических протоколов

неотслеживаемость нужно решать скорее техническими мерами, чем орга­ низационно-административными, поскольку клиент должен иметь воз­ можность действовать анонимно: байкам или его партнерам нельзя иден­ тифицировать действия клиента. Проблема неотслеживаемости актуальна в связи с применением 1Шегпе1; в повседневной жизни. Так, злоумышлен­ ник может оценить сферу интересов того или иного пользователя, произ­ водя отслеживание посещаемых данным пользователем серверов, конфе­ ренций и т.д.

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

•гарантию того, что только законные избиратели могут подать голос;

•невозможность в ходе голосования узнать выбор, сделанный тем или иным пользователем;

•условие, чтобы ни один пользователь не мог иметь больше одного го­ лоса;

•право каждого избирателя убедиться в том, что его голос был правиль­ но учтен при подведении итогов голосования.

Протокол безопасного голосования основывается иа использовании двух доверенных сторон - агентства по проверке голосующ его ( 1) на

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

щему разрешено голосовать, то отправляет голосующ ему значение

ЕД1), являющееся идентификатором голосующего, и фиксирует факт об­ ращения (участия в выборах). Далее голосующий вычисляет значения Е2(1) (секретный идентификатор) и Е3(1) (результат голосования) и по­ сылает Т 2 (ЕД1), Е2(1), Е3(1)). Т 2 проверяет, существует ли Е ^ ) в списке разрешенных идентификаторов голосующих; если существует, то добав­ ляет Е2(1) к списку голосующих за Е3(1). Преобразования Е 1; Е2 и Е3 мо­ гут носить необратимый характер, либо здесь могут использоваться асим­ метричные алгоритмы. Приведенный протокол будет уязвим в случае, если Т) и Т 2 состоят в сговоре. Усиление данного протокола возможно в случае использования его вместе с протоколом забывающей передачи данных.

Специфические криптографические протоколы

159

2.4.2. Совместная подпись контракта

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

1.Участник А подписывает копию контракта и направляет ее арбитру.

2.Участник В подписывает свою копию контракта и направляет ее ар­ битру.

3.Арбитр направляет сообщения участникам А и В, информирующие их о том, что оба подписали контракт.

4.Участник А подписывает две копии контракта и посылает их участ­ нику В.

5.Участник В подписывает обе копии контракта, одну из которых остав­ ляет себе, а другую отправляет участнику А.

6.Участники А и В информируют арбитра о том, что они оба подписали контракт.

7.Арбитр уничтожает обе копии контракта, имеющие по одной подписи.

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

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

1.Оба участника (А и В) случайным образом выбирают 2п ключа для алгоритма БЕЗ, разбитые на пары.

2.Оба участника генерируют п пар сообщений (где Ь, - левая часть пары сообщений, а - правая часть пары сообщений) и зашифровывают их на парах ключей БЕЗ (левая часть пары сообщений зашифровыва­ ется на левой части пары ключей и т.д.).

160Аспекты создания и применения криптографических протоколов

3.Оба участника направляют друг другу свои зашифрованные сообще­ ния, указывая при этом, какие сообщения половинами каких пар яв­ ляются.

4.Участники посылают друг другу по одному ключу из каждой пары.

5.Участники расшифровывают те половины сообщений, которые за­ шифрованы на полученных половинах пар ключей, и убеждаются, что расшифрование прошло успешно.

6.Оба участника посылают друг другу первые биты всех 2п ключей БЕЗ, далее - вторые биты всех 2п ключей ОЕЗ и т.д.

7.Участники расшифровывают оставшиеся части сообщений, и в случае успешного расшифрования считается, что контракт подписан.

8.Участники обмениваются секретными ключами и проверяют, что в ходе выполнения протокола не было мошенничества.

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

2.4.3. Групповая подпись

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

Групповые подписи обладают следующими свойствами:

•только члены группы могут подписывать сообщения;

•получатель подписи может убедиться, что это правильная подпись группы;

•получатель подписи не может определить, кто именно из членов груп­ пы подписал документ;

•при споре подпись будет раскрыта для определения личности подпи­ савшего.