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

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

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

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

Альтернативное решение — каждая пара членов группы совместно использу­ет отдельные ключи. Как только один из членов начнет допускать потерю ин­формации, другие члены группы просто прекращают посылать ему сообщения, но продолжают применять для связи друг с другом старые ключи. Однако в от­личие от предыдущего случая с поддержкой одного ключа теперь нужно поддер­живать N(N- 1)/2 ключей, что уже само по себе может быть непросто.

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

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

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

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

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

Смысл защищенных и прозрачно реплицируемых серверов кроется в том, что называется разделением секрета (secret sharing). При разделении секрета ни один из нескольких пользователей (или процессов) не знает секрета целиком, секрет может быть открыт только в случае их совместной работы. Такие схемы могут быть очень удобными. Рассмотрим, например, запуск ракеты с ядерной боего­ловкой. Это действие требует подтверждения как минимум двумя людьми. Каж­дый из них имеет собственный закрытый ключ, причем для пуска он должен ис­пользоваться в паре с другим. Попытка пуска с помощью единственного ключа ни к чему не приведет.

В случае защищенных реплицируемых серверов при поиске ответа максимум k из N серверов могут дать неверный ответ, а из этих k максимум с < k серверов могут быть действительно взломаны злоумышленником. Отметим, что это тре­бование предполагает, что служба устойчива к k ошибкам. Этот вопрос мы обсу­ждали в предыдущей главе. Разница состоит в том, что сейчас серверы, которые работают ошибочно, взломаны намеренно.

Теперь рассмотрим ситуацию, когда серверы активно реплицируются. Други­ми словами, запрос рассылается всем серверам одновременно, после чего обраба­тывается каждым из них. Каждый сервер генерирует ответ, который возвращает­ся клиенту. В случае защищенной реплицируемой группы серверов предполага­ется, что каждый сервер сопровождает свой ответ цифровой подписью. Если г,- — ответ сервера 5„ то пусть md(r_{) обозначает дайджест сообщения, вычисленный сервером 5,-. Этот дайджест подписан закрытым ключом KJ сервера 5,-.

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

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

результат, которому сможет доверять клиент. Каждый сервер 5, посылает ответ г_г вместе со своей подписью sig(Si, г,) = Kj(md(ri)) клиенту. Соответственно, клиент последовательно получает пять триплетов <r„ md(ri), sig(S_i} г,)>, из которых он должен выделить правильные. Эту ситуацию иллюстрирует рис. 8.21.

Рис. 8.21. Разделяемая секретная подпись группы реплицируемых серверов

Каждый дайджест md{r^) вычисляется также и на клиенте. Если ответ г, неве­рен, это обычно можно определить, вычислив K⁺j(Kj(md(ri))), однако, поскольку мы не можем доверять ни одному серверу в отдельности, этот метод применять нельзя. Вместо него клиент использует специальную открытую функцию рас­шифровки Д которая в качестве исходных данных получает набор из трех сигна­тур V= { sig(S, г), sig(S', г'), sig(S", г")}, а в качестве результата генерирует един­ственный дайджест:

dout = D(V) = D(sig(S, г), sig(S\ г'), sig(S", г")).

Детали о функции расшифровки D можно найти в [376]. Существует 5!/(3!2!) = 10 комбинаций трех подписей, которые клиент может получить в ка­честве результата D. Если одна из этих комбинаций даст правильный дайджест md(ji) для некоторого результата г„ клиент может считать ответ г, правильным. В частности, он может считать, что этот результат дан как минимум тремя пра­вильно работающими серверами.

Для повышения прозрачности репликации в [376] предлагается, чтобы каж­дый сервер Si рассылал свой результат г, остальным серверам вместе с соответст­вующей подписью sig(Su г,). Когда сервер получит как минимум с + 1 подобных сообщений, включая его собственное, он сможет вычислить правильную подпись для одного из ответов. Если, например, это вычисление для ответа г и набора V из с + 1 подписей будет успешным, он пересылает г и У клиенту одним сообще­нием. Клиент после этого проверяет корректность г путем проверки подписи, то есть того, что md(r) = D( V).

Описанный нами алгоритм известен как т,п-пороговая схема (m,n-threshold sche­me), где, в случае нашего примера, m = c + l,a??=N (число серверов). В 7?2,я-порого-вой схеме сообщение делится на п частей, известных под названием теней (shadows). Для воссоздания исходного сообщения могут быть использованы любые т теней, но любых т - 1 теней для этого будет недостаточно. Существует несколь­ко способов построения т,я-пороговых схем. Подробности можно найти в [404].