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

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

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

Идею о защите связи между клиентами и серверами можно изложить в поня­тиях организации между сообщающимися сторонами защищенного канала (secu­re channel) [479]. Защищенные каналы оберегают отправителя и получателя от перехвата, модификации и подделки сообщения. Обычно нет необходимости вво­дить защиту от прерывания связи. Защита сообщений от перехвата выполняется путем гарантированной конфиденциальности: защищенные каналы гарантируют, что сообщения в них не могут быть подсмотрены злоумышленниками. Защита сообщений от модификации или поделки производится при помощи протоколов взаимной аутентификации и целостности сообщений. Далее мы сначала обсудим различные протоколы аутентификации на основе криптосистем как с симмет­ричными, так и с открытыми ключами. Детальный разбор логических построе­ний, лежащих в основе аутентификации, можно найти в [254]. Мы рассмотрим отдельно вопросы конфиденциальности сообщений и их целостности.

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

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

Боб может быть уверен, что сообщение т отправила Алиса. Однако, если Боб не может получить гарантии, что сообщение т в ходе пересылки не изменялось, что ему толку в знании того факта, что исходную версию сообщения отправила имен­но Алиса?

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

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

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

Аутентификация на основе общего секретного ключа

Начнем с того, что рассмотрим протокол аутентификации на основе секретного ключа, который используется Алисой и Бобом постоянно. Как эти двое могут в реальности безопасным образом получить общий ключ, мы обсудим чуть позже. В описании протокола мы сократим Алису и Боба соответственно до А и 5, а со­вместно используемый ими ключ обозначим как К_лв. Обычно запрос одной из сторон вызывает ответ другой, который будет верен только в том случае, если эта другая сторона знает общий секретный ключ. Такие решения известны под назва­нием протоколов запрос-ответ (challenge-response protocols).

В случае аутентификации на базе общего секретного ключа протокол работа­ет так, как показано на рис. 8.11. Сначала Алиса посылает Бобу свой идентифи­катор (сообщение 1), показывая, что она хочет установить между ними канал связи. После этого Боб посылает Алисе запрос R_B, обозначенный как сообще­ние 2. От Алисы требуется зашифровать запрос секретным ключом К_Л>В, который она использует совместно с Бобом, и вернуть этот запрос Бобу. Ответ, показан­ный на рисунке в виде сообщения 3, содержит K_AB(R_B).

Когда Боб получит ответ K_A>B(R_B) на свой запрос R_B} он должен расшифро­вать сообщение, снова применяя общий ключ, чтобы убедиться, что в сообщении содержится запрос R_B. Если это так, то он считает, что на другой стороне канала

находится Алиса, иначе кто же еще мог зашифровать запрос Rg с использовани­ем ключа К_А>в? Другими словами, Боб теперь уверен, что действительно общает­ся с Алисой. Однако отметим, что Алиса пока еще не уверена в том, что на дру­гой стороне канала действительно Боб. Поэтому она посылает запрос R_A (сообщение 4), на который Боб отвечает, возвращая K_a,b(Ra), сообщение 5. Когда Алиса расшифрует его при помощи ключа Ка,в и обнаружит в нем запрос Ra, она поймет, что общается с Бобом.

Один из наиболее сложных моментов в обеспечении защиты — создание дей­ствительно работающих протоколов. Чтобы показать, как простые решения мо­гут привести к ошибке, рассмотрим «оптимизацию» протокола аутентификации, в которой число сообщений сокращено с пяти до трех, как показано на рис. 8.12. Основная идея состоит в том, что если Алиса, в конце концов, все равно захочет отправить Бобу запрос, она вполне может отправить его вместе со своим уведом­лением при создании канала. Точно так же и Боб, возвращая свой ответ на этот запрос, объединяет его в одно сообщение с собственным запросом.

Рис. 8.12. Аутентификация на базе общего секретного ключа с тремя, а не пятью сообщениями

К сожалению, долго этот протокол не проработает. Он с легкостью будет вскрыт при помощи так называемой атаки на отражении (reflection attack). Чтобы по­нять, что представляет из себя эта атака, предположим, что злоумышленника зо­вут Чак, мы будем обозначать его в нашем протоколе как С. Цель Чака — устано­вить канал связи с Бобом и сделать так, чтобы Боб поверил, что разговаривает с Алисой. Чак может сделать это, если ему удастся правильно ответить на запрос Боба, например, вернув зашифрованную версию числа, присланного Бобом.

Поскольку он не знает ключа K_AtB, это шифрование может произвести только сам Боб, и это именно то, на чем Чак должен надуть Боба.

Атаку иллюстрирует рис. 8.13. Чак начинает с посылки сообщения, содержа­щего уведомление А якобы от Алисы вместе с запросом R& Боб возвращает свой запрос Rg и ответ K_A>B(Rc) в одном сообщении. После этого Чак должен показать, что он знает секретный ключ, вернув Бобу K_a,b(Rb)- К сожалению, у него нет ключа К_А>в. Но он может установить второй канал связи с Бобом, чтобы тот сам зашифровал ему свой запрос.

Рис. 8.13. Атака на отражении

Таким образом, Чак отсылает А и R_B в одном сообщении, как и раньше, но те­перь притворяется, что ему нужен второй канал. На рис. 8.13 этому соответству­ет сообщение 3. Боб, не понимая, что он сам использовал ранее R_B в качестве запроса, отвечает, посылая K_a>b(Rb) и другой запрос, R_B2, как это показано в сооб­щении 4. В этот момент Чак получает K_AB(R_B) и заканчивает первый сеанс по­сылкой сообщения 5, содержащего отклик K_a>b(Rb), который и является ответом на запрос, присланный ему в сообщении 2.

Как было показано в [228], одна из ошибок, сделанных при адаптации ориги­нального протокола, состояла в том, что две стороны в новой версии протокола могут использовать одинаковые запросы в двух разных версиях протокола. Луч­ше было бы, если бы инициатор и его корреспондент использовали разные за­просы. Так, например, если Алиса всегда использует нечетные числа, а Боб — четные, Боб смог бы догадаться, что задумал какой-то хитрец, приславший ему в качестве запроса в сообщении 3 R_B (см. рис. 8.13). К сожалению, как показано в [404], такое решение неустойчиво к другим типам атак, например, так называе­мым атакам посредника. Вообще, позволять двум сторонам, вовлеченным в орга­низацию защищенного канала, проделывать какие-то вещи одинаковым обра­зом — не лучшая идея.

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

Существуют и другие принципы, к пониманию которых постепенно, за много лет, пришли разработчики криптографических систем. Мы рассмотрим некото­рые из них при обсуждении других протоколов. Один из важных уроков состоит в том, что разрабатывать протоколы защиты, которые делают то, на что они рас­считаны, часто значительно труднее, чем кажется. Итак, как мы только что видели, упрощая существующие протоколы с целью поднятия их производительности, можно легко сделать эти протоколы непригодными. Дополнительную информа­цию о принципах разработки протоколов можно получить из [1].

Аутентификация с использованием центра распространения ключей

Одна из проблем, возникающих при работе с общим секретным ключом, — это проблема масштабируемости. Если распределенная система включает в себя N хостов и каждый хост должен использовать секретный ключ совместно с другими N- 1 хостами, система в целом вынуждена содержать N(N- 1)/2 ключей, а каж­дый хост — поддерживать N - 1 из них. При больших N это становится пробле­мой. Альтернативой является подход с использованием центра распространения ключей (Key Distribution Center, KDC). KDC позволяет каждому из хостов приме­нять собственный ключ, при этом ни одной паре хостов специальный секретный ключ не требуется. Другими словами, при наличии KDC требуется поддерживать только N ключей вместо N(N- 1)/2, а это уже явное улучшение.

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

Рис. 8.14. Принцип использования KDC

Сначала Алиса посылает в центр KDC сообщение о том, что она хочет свя­заться с Бобом. KDC отвечает Алисе, посылая сообщение, содержащее общий секретный ключ К_А>В, который она может задействовать для этой цели. Сообще­ние зашифровано секретным ключом K_a>kdc, который Алиса использует совме­стно с KDC. Кроме того, KDC и Бобу посылает ключ К_А>В, но зашифрованный теперь уже секретным ключом K_b,kdc> который используется центром совместно с Бобом.

Основой минус такого подхода состоит в том, что Алиса может захотеть на­чать организацию защищенного канала связи с Бобом раньше, чем Боб получит их общий ключ от KDC. Кроме того, KDC может потребовать поставить Боба в цикл ожидания для получения им ключа. Эти проблемы можно обойти, если KDC просто вернет Kb,kdc(Ka,b) Алисе и возложит на нее всю ответственность за дальнейшую организацию связи с Бобом. Это приведет нас к протоколу, показан­ному на рис. 8.15. Сообщение K_b,kdc(Ka,b) также известно под названием талона (ticket). Дело Алисы передать этот талон Бобу. Отметим, что Боб — единствен­ный, кто может осмысленно использовать этот талон, поскольку он — единствен­ный, кроме центра KDC, кто знает, как расшифровать это сообщение и извлечь из него полезную информацию.

Рис. 8.15. Использование талона и передача Алисе права на установление контакта с Бобом

Протокол, показанный на рис. 8.15, на самом деле является одним из вариан­тов протокола аутентификации с использованием KDC, известного под названием протокола аутентификации Нидхема—Шредера (Needham—Schroeder authentication protocol), названного так по имени его создателей [311]. Другой вариант этого про­токола используется в системе Kerberos, которую мы рассмотрим чуть позднее. Протокол Нидхема—Шредера — это многоканальный протокол запрос/ответ, ра­ботающий следующим образом (рис. 8.16).

Рис. 8.16. Протокол аутентификации Нидхема—Шредера

Когда Алиса собирается организовать защищенный канал связи с Бобом, она посылает KDC сообщение, содержащее запрос R_A, вместе со своим идентифика­тором А и, разумеется, идентификатором Боба. KDC отвечает на этот запрос, вы­давая ей талон Kb,kdc(Ka,b) вместе с секретным ключом K_AtB, который она далее будет использовать совместно с Бобом.

Запрос R_Au который Алиса посылает KDC вместе со своим требованием на создание канала связи с Бобом, также известен под названием попсе и представ­ляет собой случайное число, которое используется только однажды. Основная задача этого «одноразового» случайного числа — единственным образом привя­зать одно сообщение из пары к другому, в данном случае — связать сообщения 1 и 2. В частности, при включении R_A\ в сообщение 2 Алиса будет твердо знать, что сообщение 2 отправлено в ответ на сообщение 1 и не является, например, от­ветом на другое, более старое сообщение.

Чтобы как следует понять проблему, допустим, что мы не используем случай­ное число, а Чак ухитрился стянуть один из старых ключей Боба, назовем его K^>lb^dkd& Кроме того, Чак перехватил старый ответ K_a,kdc(B, K_AtB, K°b,kdc(A, Ка,в))> который вернул центр KDC в ответ на предыдущий запрос Алисы на организа­цию связи с Бобом. Тем временем Боб договорился с KDC об использовании но­вого общего секретного ключа. Однако Чак терпеливо ожидает того момента, ко­гда Алиса вновь начнет организовывать защищенный канал связи с Бобом. В этот момент он воспроизводит старый ответ и обманывает Алису, заставляя ее пове­рить, что она действительно общается с Бобом, поскольку ее талон расшифро­ван, а значит, он доказал, что знает их общий секретный ключ К_А,в-

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

Сообщение 2 также содержит J5, идентификатор Боба. Путем включения В в сообщение центр KDC защищает Алису от очередной атаки. Предположим, что идентификатор В в сообщении 2 отсутствует. Чак может модифицировать сооб­щение 1, заменив идентификатор Боба своим идентификатором, скажем, С. После этого KDC решит, что Алиса хочет создать защищенный канал с Чаком и отве­тит в соответствии с этим предположением. Как только Алиса захочет пообщать­ся с Бобом, Чак будет перехватывать ее сообщения и обманывать Алису, застав­ляя ее поверить, что она связана с Бобом. При копировании идентификатора из сообщения 1 в сообщение 2 Алиса немедленно обнаружит, что ее запрос был из­менен.

После того как KDC передаст Алисе талон, можно организовывать защищен­ный канал между Алисой и Бобом. Алиса начинает этот процесс с посылки сооб­щения 3, которое содержит талон для Боба и запрос R_a2, зашифрованный их об­щим ключом К_л,в, который только что был создан KDC. Боб расшифровывает талон, чтобы получить общий ключ, и возвращает отклик, Ra2~ 1, вместе с за­просом R_B к Алисе.

Следует сделать по поводу сообщения 4 следующее замечание. Вообще гово­ря, возвращая отклик R_a2 - 1, а не просто /?л2, Боб не только доказывает, что он знает общий секретный ключ, но также и то, что он действительно расшифровал запрос. И вновь это связывает сообщение 4 с сообщением 3, таким же образом, как случайное число R_A связывало сообщение 2 с сообщением 1. Таким образом, протокол становится более защищенным от повторного воспроизведения сооб­щений.

Однако в этом конкретном случае может быть достаточно вернуть K_a,b(Ra2, R_B) по той простой причине, что это сообщение нигде ранее в протоколе не ис­пользуется. Отклик K_Ab(Ra2> Rb) всегда доказывает, что Боб в состоянии рас­шифровать запрос, присланный ему в сообщении 1. Сообщение 4, так как оно приведено на рис. 8.16, сохранено по историческим причинам.

У приведенного здесь алгоритма Нидхема—Шредера имеется одно слабое ме­сто. Если Чаку каким-то образом удастся завладеть старым ключом К_А>В, он мо­жет просто повторить посылку сообщения 3, требуя от Боба установки канала. Боб может поверить, что он общается с Алисой, хотя на самом деле на другом конце канала будет Чак. В этом случае мы должны соотнести сообщение 3 с со­общением 1, то есть сделать так, чтобы ключ зависел от исходного запроса, посы­лаемого Алисой для организации канала связи с Бобом. Это решение представ­лено на рис. 8.17.

Рис. 8.17. Защита от злонамеренного повторного использования сгенерированного ранее сеансового ключа в протоколе Нидхема—Шредера

Фокус состоит в том, чтобы включить случайное число в ответ, посылаемый Алисе из KDC. Причем случайное число должно прийти от Боба — это уверит Боба, что тот, кто пытается установить с ним защищенный канал связи, получил соответствующую информацию от KDC. Таким образом, Алиса сначала просит Боба послать ей случайное число Rb\, зашифрованное ключом, который сов­местно используется Бобом и KDC. Алиса включает это случайное число в свой запрос к центру KDC, который расшифровывает его и помещает результат в создаваемый талон. Тем самым Боб убеждается в том, что сеансовый ключ свя­зан с исходным требованием Алисы на организацию связи с Бобом.

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

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

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

Р ис. 8.18. Взаимная аутентификация в криптосистемах с открытым ключом

Алиса начинает с того, что посылает Бобу запрос Ra, зашифрованный его от­крытым ключом Кв. Дело Боба расшифровать это сообщение и вернуть Алисе свой запрос. Поскольку Боб — единственный, кто в состоянии расшифровать это сообщение (используя закрытый ключ, соответствующий открытому ключу Али­сы), Алиса будет знать, что общается с Бобом. Отметим важность того, что Али­са гарантированно использует открытый ключ Боба, а не кого-то другого, кто притворяется Бобом. Как можно получить эту гарантию, мы обсудим чуть позже.

Когда Боб получает от Алисы требование на создание канала, он возвращает расшифрованный запрос вместе со своим собственным запросом Rb для аутенти­фикации Алисы. Кроме того, он создает сеансовый ключ К_л,в, который можно будет использовать для дальнейшей работы. Ответ Боба на запрос Алисы, его собственный запрос и сеансовый ключ помещаются в сообщение, которое шиф­руется открытым ключом Ка, принадлежащим Алисе (сообщение 2). Только Али­са в состоянии расшифровать это сообщение, используя закрытый ключ К а, со­ответствующий открытому ключу Ка.

И, наконец, Алиса возвращает свой ответ на запрос Боба, используя сеансо­вый ключ К_А,в, созданный Бобом. Таким образом, она показывает, что в состоя­нии расшифровать сообщение 2, а значит, та, с кем общается Боб, — действи­тельно Алиса.