Таненбаум Э. Распределенные системы. Принципы и парадигмы

Подождите немного. Документ загружается.

8.2.

Защищенные каналы

481

Поскольку

он не

знает ключа

КА,В,

ЭТО

шифрование может произвести только

сам

Боб,

и это

именно

то, на чем Чак

должен надуть Боба.

Атаку иллюстрирует рис.

8.13. Чак

начинает

посылки сообщения, содержа-

щего уведомление

якобы

от

Алисы вместе

запросом Re.

Боб

возвращает свой

запрос

RB и

ответ

KA,B(RC)

ОДНОМ

сообщении. После этого Чак должен показать,

что

он

знает секретный ключ, вернув Бобу

KA,B{RB)' К

сожалению,

него

нет

ключа

КА,В'

НО

ОН

может установить второй канал связи

Бобом, чтобы

тот сам

зашифровал

ему

свой запрос.

го

A.RcJ

'^В'^А.В^^с)

A.RBJ

^вг-КАзС^в)

К- ^(^л

*A,ev

"В/

Первый

сеанс

Второ

й сеанс

\ Первый сеанс

Рис.

8.13.

Атака на отражении

Таким образом,

Чак

отсылает

i?/?

одном сообщении,

как и

раньше,

но те-

перь притворяется,

что ему

нужен второй канал.

На

рис.

8.13

этому соответству-

ет сообщение

3. Боб, не

понимая,

что он сам

использовал ранее RB

качестве

запроса, отвечает, посылая

KA,B(RB)

И другой запрос,

RB2y

как

это показано

сооб-

щении

4. В

этот момент

Чак

получает

KA,B{RB) И

заканчивает первый сеанс

по-

сылкой сообщения

содержащего отклик

KA,B(RB)y

который

является ответом

на запрос, присланный

ему в

сообщении

Как было показано

[228],

одна

из

ошибок, сделанных

при

адаптации ориги-

нального протокола, состояла

в том, что две

стороны

новой версии протокола

могут использовать одинаковые запросы

двух разных версиях протокола. Луч-

ше было

бы,

если

бы

инициатор

и его

корреспондент использовали разные

за-

просы.

Так,

например, если Алиса всегда использует нечетные числа,

а Боб

—

четные.

Боб

смог

бы

догадаться,

что

задумал какой-то хитрец, приславший

ему в

качестве запроса

сообщении

(СМ.

рис.

8.13).

сожалению,

как

показано

[404],

такое решение неустойчиво

другим типам атак, например,

так

называе-

мым атакам посредника. Вообще, позволять двум сторонам, вовлеченным

орга-

низацию защищенного канала, проделывать какие-то вещи одинаковым обра-

зом

—

не

лучшая идея.

Другой момент, который делает адаптированный протокол непригодным,

—

то,

что Боб

отправляет важную информацию

виде отклика,

KA,B{RB)^ не

будучи

уверенным

в том,

кому

он ее

посылает. Этот момент

исходном протоколе

от-

сутствует, ведь Алиса должна сначала подтвердить себя,

только после этого

Боб пошлет

ей

зашифрованную информацию.

Существуют

другие принципы,

пониманию которых постепенно,

за

много

лет, пришли разработчики криптографических систем.

Мы

рассмотрим некото-

482 Глава 8. Защита

рые

из них при

обсуждении других протоколов. Один

из

важных уроков состоит

в том,

что

разрабатывать протоколы защиты, которые делают то,

на что они

рас-

считаны, часто значительно труднее,

чем

кажется. Итак,

как мы

только

что

видели,

упрощая существующие протоколы

целью поднятия

их

производительности,

можно легко сделать

эти

протоколы непригодными. Дополнительную информа-

цию

принципах разработки протоколов можно получить

из [1].

Аутентификация

использованием центра

распространения ключей

Одна

из

проблем, возникающих

при

работе

общим секретным ключом,

—

это

проблема масштабируемости. Если распределенная система включает

себя Л^

хостов

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

N-

хостами, система

целом вынуждена содержать

N(N- 1)/2

ключей,

каж-

дый хост

—

поддерживать

iV-

из них. При

больших Л''это становится пробле-

мой. Альтернативой является подход

использованием

центра распространения

ключей

{Key

Distribution

Center,

KDC). KDC позволяет каждому

из

хостов приме-

нять собственный ключ,

при

этом

ни

одной паре хостов специальный секретный

ключ не требуется. Другими словами, при наличии KDC требуется поддерживать

только

ключей вместо

N(N- 1)/2, а это уже

явное улучшение.

Когда Алиса хочет установить защищенный канал связи

Бобом,

она

может

сделать

это при

помощи доверенного центра KDC. Основная идея состоит

в том,

что

KDC

поддерживает ключи Алисы

Боба, которые

они

могут использовать

при обмене сообщениями,

что и

показано

на

рис.

8.14.

А.В

'^A.KDC(^^A,B)

со

KB.KDC(KA,B)

Рис.

8.14.

Принцип

использования

КОС

Сначала Алиса посылает

центр

KDC

сообщение

о том, что она

хочет свя-

заться

Бобом.

KDC

отвечает Алисе, посылая сообщение, содержащее общий

секретный ключ

КА,В^

который

она

может задействовать

для

этой цели. Сообще-

ние зашифровано секретным ключом

КА,КОСУ

который Алиса использует совме-

стно

с KDC.

Кроме того,

KDC и

Бобу посылает ключ

КА,ВУ

НО

зашифрованный

теперь

уже

секретным ключом

KB,KDCI

который используется центром совместно

с Бобом.

Основой минус такого подхода состоит

в том, что

Алиса может захотеть

на-

чать организацию защищенного канала связи

Бобом раньше,

чем Боб

получит

их общий ключ

от KDC.

Кроме того,

KDC

может потребовать поставить Боба

8.2.

Защищенные каналы

483

в цикл ожидания для получения им ключа. Эти проблемы можно обойти, если

KDC просто вернет

KB,KDC(KA,B)

Алисе и возложит на нее всю ответственность за

дальнейшую организацию связи с Бобом. Это приведет нас к протоколу, показан-

ному на рис. 8.15. Сообщение

KB,KDC(KA,B)

также известно под названием талона

(ticket).

Дело Алисы передать этот талон Бобу. Отметим, что Боб

—

единствен-

ный, кто может осмысленно использовать этот талон, поскольку он

—

единствен-

ный, кроме центра KDC, кто знает, как расшифровать это сообщение и извлечь

из него полезную информацию.

А.В

'^A.KDC(KA,B)' ^B.KDCC^A.B)

А. KB.KDQC^A.B)

Рис.

8.15.

Использование

талона и передача Алисе права

на

установление

контакта с Бобом

Протокол, показанный на рис. 8.15, на самом деле является одним из вариан-

тов протокола аутентификации с использованием KDC, известного под названием

протокола аутентификации Нидхема—Шредера {Needham—Schroeder authentication

protocol),

названного так по имени его создателей

[311].

Другой вариант этого про-

токола используется в системе Kerberos, которую мы рассмотрим чуть позднее.

Протокол Нидхема—Шредера

—

это многоканальный протокол запрос/ответ, ра-

ботающий следующим образом (рис. 8.16).

RAIAB

^A,KDC(^AI'^»*^A.B'^B,KDC('^'^A,B))

'^A,B('^A2)'KB,KDC(A.KA,B)

КА.В(^^А2~

''''^В)

^А.вС^В

~ '')

Рис.

8.16. Протокол

аутентификации

Нидхема—Шредера

Когда Алиса собирается организовать защищенный канал связи с Бобом, она

посылает KDC сообщение, содержащее запрос

RA,

вместе со своим идентифика-

тором А и, разумеется, идентификатором Боба. KDC отвечает на этот запрос, вы-

давая ей талон

KB,KDC(KA,B)

вместе с секретным ключом

КА,ВУ

который она далее

будет использовать совместно с Бобом.

484 Глава 8. Защита

Запрос

RAU

который Алиса посылает KDC вместе со своим требованием на

создание канала связи с Бобом, также известен под названием попсе и представ-

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

задача этого «одноразового» случайного числа

—

единственным образом привя-

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

—

связать сообщения 1

и 2. В частности, при включении

RAI

сообщение 2 Алиса будет твердо знать,

что сообщение 2 отправлено в ответ на сообщение

и не является, например, от-

ветом на другое, более старое сообщение.

Чтобы как следует понять проблему, допустим, что мы не используем случай-

ное число, а Чак ухитрился стянуть один из старых ключей Боба, назовем его

K'B^KDO

Кроме того, Чак перехватил старый ответ

KA,KDC(B,

КА,ВУ

K^B,KDC(A

КА,В))У

который вернул центр KDC в ответ на предыдущий запрос Алисы на организа-

цию связи с Бобом. Тем временем Боб договорился с KDC об использовании но-

вого общего секретного ключа. Однако Чак терпеливо ожидает того момента, ко-

гда Алиса вновь начнет организовывать защищенный канал связи с Бобом.

этот

момент он воспроизводит старый ответ и обманывает Алису, заставляя ее пове-

рить,

что она действительно общается с Бобом, поскольку ее талон расшифро-

ван,

а значит, он доказал, что знает их общий секретный ключ

КА,В-

Включив в сообщение случайное число, мы делаем подобную атаку невоз-

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

В частности, случайное число ответа не совпадет со случайным числом исходно-

го сообщения.

Сообщение 2 также содержит В, идентификатор Боба. Путем включения В в

сообщение центр KDC защищает Алису от очередной атаки. Предположим, что

идентификатор В в сообщении 2 отсутствует. Чак может модифицировать сооб-

щение 1, заменив идентификатор Боба своим идентификатором, скажем,

С.

После

этого KDC решит, что Алиса хочет создать защищенный канал с Чаком и отве-

тит в соответствии с этим предположением. Как только Алиса захочет пообщать-

ся с Бобом, Чак будет перехватывать ее сообщения и обманывать Алису, застав-

ляя ее поверить, что она связана с Бобом. При копировании идентификатора из

сообщения 1 в сообщение 2 Алиса немедленно обнаружит, что ее запрос был из-

менен.

После того как KDC передаст Алисе талон, можно организовывать защищен-

ный канал между Алисой и Бобом. Алиса начинает этот процесс с посылки сооб-

щения 3, которое содержит талон для Боба и запрос /?л2, зашифрованный их об-

щим ключом

КА,В>

который только что был создан KDC. Боб расшифровывает

талон, чтобы получить общий ключ, и возвращает отклик,

RA2

- 1, вместе с за-

просом

Алисе.

Следует сделать по поводу сообщения 4 следующее замечание. Вообще гово-

ря,

возвращая отклик

RA2

- 1, а не просто /?л2, Боб не только доказывает, что он

знает общий секретный ключ, но также и то, что он действительно расшифровал

запрос. И вновь это связывает сообщение 4 с сообщением 3, таким же образом,

как случайное число

связывало сообщение 2 с сообщением 1. Таким образом,

протокол становится более защищенным от повторного воспроизведения сооб-

щений.

8.2.

Защищенные каналы 485

Однако в этом конкретном случае может быть достаточно вернуть

КА,В{КЛ2У

RB)

ПО

ТОЙ

простой причине, что это сообщение нигде ранее в протоколе не ис-

пользуется. Отклик

KA,B{RA2,

RB) всегда доказывает, что Боб в состоянии рас-

шифровать запрос, присланный ему в сообщении 1. Сообщение 4, так как оно

приведено на рис. 8.16, сохранено по историческим причинам.

У приведенного здесь алгоритма Нидхема—Шредера имеется одно слабое ме-

сто.

Если Чаку каким-то образом удастся завладеть старым ключом

КА,В,

ОН

мо-

жет просто повторить посылку сообщения 3, требуя от Боба установки канала.

Боб может поверить, что он общается с Алисой, хотя на самом деле на другом

конце канала будет Чак. В этом случае мы должны соотнести сообщение 3 с со-

общением 1, то есть сделать так, чтобы ключ зависел от исходного запроса, посы-

лаемого Алисой для организации канала связи с Бобом. Это решение представ-

лено на рис. 8.17.

KB,KDc(f^Bl)

Рд^Л

B,KBKDC(RBI)

^A.KDCe^AI'^'KA.B'^B.KDcCA.KA.B'^Bl))

KA,B('^A2)'KB,KDC(A.KA,B.RBI

)

*^А.в(^^А2"'''^В2)

КА.В(^^В2~'')

Рис.

8.17. Защита от злонамеренного повторного использования сгенерированного ранее

сеансового

ключа в протоколе Нидхема—-Шредера

Фокус состоит в том, чтобы включить случайное число в ответ, посылаемый

Алисе из KDC. Причем случайное число должно прийти от Боба

—

это уверит

Боба, что тот, кто пытается установить с ним защищенный канал связи, получил

соответствующую информацию от KDC. Таким образом, Алиса сначала просит

Боба послать ей случайное число

RBU

зашифрованное ключом, который сов-

местно используется Бобом и KDC. Алиса включает это случайное число в свой

запрос к центру KDC, который расшифровывает его и помещает результат в

создаваемый талон. Тем самым Боб убеждается в том, что сеансовый ключ свя-

зан с исходным требованием Алисы на организацию связи с Бобом.

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

с открытым ключом

Обсудим теперь аутентификацию на основе криптосистем с открытым ключом,

которым не нужен центр KDC. Давайте снова рассмотрим тот случай, когда Али-

са хочет организовать защищенный канал связи с Бобом, причем оба они владеют

486 Глава 8. Защита

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

криптосистем с открытым ключом показан на рис. 8.18.

< 2

KS(A.RA)

Кд(Рд,Рв)Кдв

КА.В(^В)

Рис. 8.18. Взаимная аутентификация

криптосистемах с открытым ключом

Алиса начинает с того, что посылает Бобу запрос /?л, зашифрованный его от-

крытым ключом К\. Дело Боба расшифровать это сообщение и вернуть Алисе

свой запрос. Поскольку Боб

—

единственный, кто в состоянии расшифровать это

сообщение (используя закрытый ключ, соответствующий открытому ключу Али-

сы),

Алиса будет знать, что общается с Бобом. Отметим важность того, что Али-

са гарантированно использует открытый ключ Боба, а не кого-то другого, кто

притворяется Бобом. Как можно получить эту гарантию, мы обсудим чуть

позже.

Когда Боб получает от Алисы требование на создание канала, он возвращает

расшифрованный запрос вместе со своим собственным запросом

ДЛЯ

аутенти-

фикации Алисы. Кроме того, он создает сеансовый ключ

КА,В^

который можно

будет использовать для дальнейшей работы. Ответ Боба на запрос Алисы, его

собственный запрос и сеансовый ключ помещаются в сообщение, которое шиф-

руется открытым ключом К\, принадлежащим Алисе (сообщение 2). Только Али-

са в состоянии расшифровать это сообщение, используя закрытый ключ

К'А,

со-

ответствующий открытому ключу К\.

И, наконец, Алиса возвращает свой ответ на запрос Боба, используя сеансо-

вый ключ

КАЗ^

созданный Бобом. Таким образом, она показывает, что в состоя-

нии расшифровать сообщение 2, а значит, та, с кем общается Боб,

—

действи-

тельно Алиса.

8.2.2. Целостность и конфиденциальность

сообщений

Кроме аутентификации защищенный канал должен также предоставлять гарантии

целостности и конфиденциальности сообщений. Под целостностью сообщений

мы подразумеваем защищенность сообщений от изменения, конфиденциаль-

ность означает, что сообщения не могут быть перехвачены и прочитаны посто-

ронними лицами. Конфиденциальность легко реализуется путем обычного шиф-

рования сообщений перед их посылкой. Шифрование может производиться как

секретным ключом, совместно используемым отправителем и получателем, так и

открытым ключом получателя. Однако, как мы увидим далее, защита сообщений

от модификации

—

дело более сложное.

8.2. Защищенные каналы

487

Цифровые подписи

Целостность сообщений часто не ограничивается собственно передачей сообще-

ний по безопасному каналу. Рассмотрим ситуацию, когда Боб продает Алисе какие-

то цифровые фотографии в коллекцию за 500 долларов. Вся сделка совершается

по

электронной почте. В конце Алиса посылает Бобу сообщение, подтверждающее,

что она покупает фотографии за 500 долларов. Помимо аутентификации для под-

держания целостности сообщения важно соблюдать еще как минимум два момента.

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

сумму в 500 долларов, указанную в ее сообщении, на большую и утвер-

ждать, что она обещала ему больше 500 долларов.

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

ложения после посылки сообщения, например, передумав.

Эти два момента можно обеспечить, если Алиса поставит свою

цифровую

под-

пись {digital signature)

под этим документом, однозначно связав ее с содержимым

письма. Уникальная связь между сообщением и подписью под ним приведет к

тому, что внесение изменений в сообщение не останется незамеченным. Кроме

того,

если подлинность подписи Алисы может быть подтверждена, ей не удастся

в дальнейшем отрицать тот факт, что сообщение подписала именно она.

Существует несколько способов поставить под документом цифровую под-

пись.

Один из наиболее популярных вариантов

—

использование криптосистем с

открытым ключом, таких как RSA (рис. 8.19). Когда Алиса посылает сообщение

Бобу, она шифрует его своим закрытым ключом

КХ

и пересылает. Если она хо-

чет вдобавок сохранить содержимое письма в тайне, она может воспользоваться

также и открытым ключом Боба и послать Кв(т,

КХ{т)),

объединив в письме со-

общение т и его экземпляр, зашифрованный Алисой.

т^->-

Компьютер Алисы

^—

Закрытый

ключ

Алисы,

к;

Открытый

ключ Боба,

>\ 1

1 / . 1

1 ' 1 1

1 ' 1

it!

1 I /

1 \/ ^^1

1 i

Компьютер Боба

W ^ 1

Закрытый

ключ Боба,

Открытый

ключ

Алисы,

«;

-• m

К;(т)

K^(m.K-(m))

K~(m)

Рис. 8.19. Цифровая подпись сообщения

шифрование

открытым ключом

Когда сообщение дойдет до Боба, он сможет расшифровать его, используя от-

крытый ключ Алисы. Если он будет уверен, что открытый ключ действительно

принадлежит Алисе, то расшифровка подписанной версии сообщения т и успеш-

ное сравнение его с исходной версией сообщения т будет означать, что оно дейст-

врггельно пришло от Алисы. Алиса защищена от любых умышленных изменений т,

вносимых Бобом, поскольку Бобу всегда придется доказывать, что модифициро-

ванная версия т также была подписана Алисой. Другими словами, расшифро-

ванное сообщение само по себе не может считаться доказательством. Кроме того.

488 Глава 8. Защита

в интересах Боба хранить подписанную версию т с целью защитить себя от по-

пыток Алисы отказаться от своего предложения.

Этой схеме присущи определенные проблемы, хотя сам протокол абсолютно

корректен. Во-первых, подпись Алисы действительна только до тех пор, пока за-

крытый ключ Алисы содержится в секрете. Если Алиса захочет пересмотреть ус-

ловия сделки уже после посылки Бобу подтверждения, ей достаточно будет объ-

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

Другая проблема возршкает в том случае, если Алиса решит изменить свой

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

ние ключа, выполняемое время от времени, обычно способствует усилению за-

щиты. Однако раз Алиса изменила свой ключ, догтюр, отправленный Бобу, те-

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

служба авторизации, которая будет отслеживать изменения ключей и отметки

времени подписания сообщений.

Еще одной проблемой подобной схемы является то, что Алиса шифрует все

сообщение своим закрытым ключом. Подобное шифрование может потребовать

массы вычислительных ресурсов (или даже оказаться невыполнимым, если мы

предположим, что сообщение интерпретируется как двоичное число с ограни-

ченной максимальной длиной), а это для нас недопустимо. Напомним, что все,

что нам нужно,

—

это однозначно связать подпись с конкретным сообщением.

Гораздо дешевле и значительно элегантнее будет использовать схему с примене-

нием дайджестов сообщений.

Как мы уже говорили, дайджест сообщения

—

это строка битов фиксирован-

ной длины

А,

которая вычисляется из сообщения произвольной длины т посред-

ством криптографической хэш-функции Я. Если т изменяется, получается дру-

гое сообщение, т'. Его хэш, Н(т'), будет отличаться от первоначальной строки

h = Н(т), так что внесенные изменения будет легко обнаружить.

Чтобы подписать сообщение, Алиса должна будет сначала вычислить дай-

джест сообщения, а затем зашифровать этот дайджест своим закрытым ключом

(рис.

8.20). Зашифрованный дайджест пересылается Бобу вместе с сообщением.

Отметим, что само сообщение пересылается открытым текстом и его может про-

честь кто угодно. Если мы нуждаемся в конфиденциальности, сообщение можно

также зашифровать открытым ключом Боба.

Компьютер Алисы

Хэш-функция,

W-

> Г

Открытый

ключ Алисы,

Компьютер Боба

1 W m i

i W

Хэш-функция,

Открытый

ключ Алисы,

Сравнить

^•ок

Н(т)

К-(Н{т))

Н(т)

Рис. 8.20. Цифровая подпись сообщения и использование дайджеста сообщения

8.2. Защищенные каналы 489

Получив сообщение и зашифрованный дайджест, Боб должен просто рас-

шифровать дайджест открытым ключом АЛРТСЫ И независимо вычислить дай-

джест сообщения. Если вычисленный для полученного сообщения дайджест и

расшифрованный дайджест Алисы совпадают, можно предположить, что сооб-

щение было подписано Алисой.

Сеансовые ключи

в ходе организации защищенных каналов после завершения фазы аутентифика-

ции с целью конфиденциальности стороны обычно используют уникальный общий

сеансовый ключ. По окончании использования канала сеансовый ключ аннули-

руется. В качестве альтернативы для конфиденциальности можно ограничиться

тем же ключом, что и при установлении соединения, однако сеансовые ключи да-

ют множество важных преимуществ

[228].

Во-первых, при частом использовании ключа его проще вскрыть. В этом

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

Основная идея здесь состоит в том, что если злоумышленник сможет перехва-

тить большой объем данных, зашифрованных одним и тем же ключом, он смо-

жет построить атаки так, чтобы выявить важные характеристики ключа и, воз-

можно, получить простой текст или даже сам ключ. По этой причине желательно

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

ключи часто меняются при помощи каких-либо медленных внешних механиз-

мов,

например регулярных почтовых отправлений или телефонограмм. Такие

способы обмена ключами должны быть сведены к минимуму.

Другая важная причина генерации отдельного ключа на каждый защищенный

канал состоит в гарантированной защите от атак воспроизведения сообщений.

Используя уникальные сеансовые ключи при каждом открытии защищенного

канала, общающиеся стороны как минимум застрахованы от воспроизведения

всего сеанса. Чтобы защититься от воспроизведения отдельных сообщений из

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

ление к сообщениям отметок времени или последовательных номеров.

Предположим, что целостность и конфиденциальность сообщений достигает-

ся использованием того же ключа, что и для организации сеанса. В этом случае

всякий раз, когда ключ раскрывают, злоумышленник оказывается в состоянии

расшифровать сообщения, передававшиеся в ходе предыдущих сеансов. Понят-

но,

что это нежелательно. Вместо этого гораздо безопаснее использовать сеансо-

вые ключи, поскольку при раскрытии такого ключа можно будет расшифровать

сообщения только одного сеанса. Сообщения, переданные в ходе других сеансов,

останутся конфиденциальными. /

Немного о последнем замечании. Алиса может захотеть обменяться с Бобом

некоторыми конфиденциальными данными, не доверяя ему настолько, чтобы пе\

редавать информацию, зашифрованную ключами длительного действия. Она мо-^

жет пожелать зарезервировать эти ключи для обмена конфиденциальной инфор-

мацией с собеседниками, которым она действительно доверяет. В этом случае ей

лучше использовать относительно дешевые сеансовые ключи.

Вообще говоря, ключи аутентификации часто организованы таким образом,

что их замена

—

достаточно дорогостоящая операция. Таким образом, комбина-

490 Глава 8. Защита

ция из подобных ключей длительного действия и более дешевых и краткосроч-

ных сеансовых ключей

—

нередко лучший выбор при реализации защищенных

каналов обмена данными.

8.2.3. Защищенное групповое взаимодействие

До сих пор наше внимание было сосредоточено на вопросе организации защи-

щенных каналов связи между двумя сторонами. В распределенных системах, од-

нако,

часто необходимо поддерживать защищенную связь между большим коли-

чеством сторон. Типичный пример этого

—

реплицируемый сервер, для которого

все связи между репликами следует защищать от изменения, подделки и перехва-

та так

же,

как защищенный канал между двумя пользователями.

этом подразде-

ле мы поближе познакомимся с вопросами защищенного группового взаимодей-

ствия.

Конфиденциальное групповое взаимодействие

Для начала обсудим проблему защиты взаимодействия в группе из

ЛГ

пользовате-

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

будет совместное использование всей группой одного секретного ключа для шиф-

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

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

группы, необходимо, чтобы все участники верили, что ключ действительно сек-

ретный. Это требование само по себе делает использование одного общего сек-

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

атак по сравнению с двухсторонним защищенным каналом.

Альтернативное решение

—

каждая пара членов группы совместно использу-

ет отдельные ключи. Как только один из членов начнет допускать потерю ин-

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

но продолжают применять для связи друг с другом старые ключи. Однако в от-

личие от предыдущего случая с поддержкой одного ключа теперь нужно поддер-

живать N(N- 1)/2 ключей, что уже само по себе может быть непросто.

Облегчить положение может помочь криптосистема с открытым ключом. То-

гда каждый член группы будет иметь собственную пару (открытый ключ, закры-

тый ключ), в которой открытый ключ будет использоваться всеми членами груп-

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

Л/"

пар ключей. Если один из членов группы перестает внушать доверие, он про-

сто удаляется из группы, при этом другие ключи не затрагиваются.

Защищенная репликация серверов

Теперь обсудим совсем другую проблему: клиента, посылающего запрос группе

реплицируемых серверов. Серверы могут реплицироваться по разным причинам:

для защиты от сбоев, для повышения производительности. Но в любом случае

клиент ожидает, что ответ будет заслуживать доверия. Другими словами, незави-

симо от того, подвержена ли группа серверов византийским ошибкам, которые

мы обсуждали в предыдущей главе, клиент ожидает, что защите возвращенного