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

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

8.1.

Общие вопросы защиты 461

Шифрование

—

фундамент компьютерной защиты. Шифрование трансфор-

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

словами, шифрование

—

это средство реализации конфиденциальности. Кроме

того,

шифрование позволяет нам проверить, не изменялись ли данные, давая

возможность контролировать целостность данных.

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

ля,

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

что до начала работы службы с клиентом служба должна определить подлин-

ность клиента. Обычно пользователи аутентифицируют себя при помощи паро-

ля,

однако существуют и другие способы аутентификации клиента.

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

он право на проведение запрашиваемых действий. Типичным примером являет-

ся доступ к базе данных с медицинской информацией. В зависимости от того,

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

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

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

он это делает. Хотя средства аудита не защищают от угроз защите, журналы ауди-

та постоянно используются для анализа «дыр» в системах защиты с последую-

щим принятием мер против нарушителей. Поэтому нарушители всеми силами

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

вести к их раскрытию. До известной степени именно благодаря протоколирова-

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

Пример

—

архитектура защиты Globus

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

блюдении этих правил, часто лучше объяснять на конкретном примере. Рассмот-

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

[100].

Globus

—

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

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

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

[148].

Ресурсы

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

торые могут находиться в разных частях света.

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

административных доменов, важность защиты резко возрастает. Чтобы разрабо-

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

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

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

bus вытекают из следующих восьми умозаключений

[147].

4 Среда состоит из множества административных доменов.

4 Локальные операции (то есть операции, протекающие в пределах одного

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

4 Глобальные операции (то есть операции, в которые включается несколько

доменов) требуют инициатора, известного во всех вовлеченных в опера-

цию доменах.

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

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

юдная идентификация.

4 Глобальная аутентифр1кация стоит выше локальной.

Контроль доступа к ресурсам относится к компетенции локальной иденти-

фикации.

Пользователи могут делегировать свои права процессам.

4 Группа процессов в одном домене может использовать свои идентифика-

торы совместно.

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

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

щиты. Предполагается, что локальные правила не изменятся только из-за того,

что система входит в Globus. Глобальные правила Globus, кроме того, не изменя-

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

Globus ограничена лишь операциями, в которые вовлечены несколько доменов.

В соответствии с этим моментом в Globus считается, что операции, целиком

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

защиты этого домена. Другими словами, если операция инициирована и проис-

ходит в пределах одного домена, все действия производятся с использованием

только локальных мер защиты. Globus не предпринимает на этот счет никаких

дополнительных действий.

Правила защиты Globus определяют, что запросы на операцию должны ини-

циироваться

—

глобально или локально. Инициатор, которым является пользо-

ватель или процесс, работающий от имени пользователя, должен быть известен

во всех доменах, участвующих в операции. Так, например, пользователь может

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

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

мена.

Один из важных принципов состоит в том, что операции между сущностями

в разных доменах требуют обоюдной аутентификации. Это означает, например,

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

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

мо провести аутентификацию пользователя. Не менее важно, чтобы пользова-

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

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

позже.

Эти два правила комбинируются в следующее требование защиты. Если лич-

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

домене, то в этом домене он может считаться прошедшим аутентификацию. То

есть Globus полагает, что при получении доступа к ресурсам удаленного домена

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

пользователь уже аутентифицирован в этом удаленном домене (если он там извес-

тен).

Дополнительная аутентификация в этом удаленном домене уже не нужна.

Как только пользователь (или процесс, работающий по его заданию) аутенти-

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

8.1.

Общие вопросы защиты 463

сурсам. Так, например, пользователь, желающий изменить файл, должен сначала

пройти аутентификацию, после чего следует проверить, действительно ли этот

пользователь имеет право изменять этот файл. Правила защиты Globus предпо-

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

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

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

ровать свои права процессам, рассмотрим мобильного агента системы Globus,

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

в различных доменах. Подобному агенту для выполнения своей работы может

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

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

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

процессам. Соответственно, при аутентификации агента с последующей провер-

кой его прав система Globus должна иметь возможность разрешить агенту ини-

циировать операции, не связываясь с владельцем агента.

В качестве последнего правила Globus требует, чтобы группы процессов, вы-

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

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

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

открывает дорогу масштабируемым решениям аутентификации за счет отказа от

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

номочий.

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

шении общих проблем защиты. Предполагая, что каждый домен поддерживает

собственные правила защиты, разработчрши Globus сосредоточивают свои уси-

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

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

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

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

ханизмах междоменной аутентификации и объявления пользователя в удален-

ных доменах.

Для этой цели вводятся два типа представителей.

Заместитель пользователя

{user proxy) представляет собой процесс, которому дано право действовать от лица

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

заместителей ресурсов.

Заместитель

ресурса

{resource

proxy)

—

это процесс, ра-

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

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

кальных правил защиты. Так, например, заместитель пользователя обычно при-

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

ресурсам.

Архитектура защиты системы Globus в основном состоит из различных сущ-

ностей, таких как пользователи, заместители пользователей, заместители ресур-

сов и процессы общего назначения. Эти сущности размещены в доменах и взаи-

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

различных протокола взаимодействия, показанных на рис. 8.1

[148].

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

Домен

Протокол 3.

Выделение ресурсов

для процесса

в удаленном домене

Домен

Заместитель создает

процесс

Процесс К--[

Заместитель

ресурса

Процесс г4--

Процесс

Локальные

правила

и механизмы

защиты

Отображение

глобальных

локальные

Заместитель

ресурса

Локальные

правила

и механизмы

безопасности

Отображение

глобальных

локальные

Процесс

порождает

дочерний

процесс

Протокол 4.

. Объявление

пользователя

в удаленном домене

у—

Пользователь должен быть

объявлен

домене

Домен

-<.

Заместитель

пользователя

Пользователь

Протокол 1.

Создание

пользовательского

заместителя

Протокол 2.

Выделение пользователю

ресурсов

удаленном

домене

Рис. 8.1. Архитектура защиты Globus

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

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

зволить заместителю действовать по заданию пользователя, этот пользователь

передает ему соответствующий набор полномочий.

Второй протокол определяет, как заместитель пользователя может запросить

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

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

аутентификации. Этот процесс представляет пользователя (как это ранее делал

заместитель пользователя), но работает в том же домене, что и запрошенные ре-

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

ступа, принятым в этом домене.

Процесс, созданный в удаленном домене, может инициировать дополнитель-

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

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

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

заместитель пользователя. Процессу просто разрешается иметь собственный за-

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

ответствии со вторым протоколом.

8.1.

Общие вопросы защиты 465

Четвертый и последний протокол в архитектуре защиты Globus

—

это способ,

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

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

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

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

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

в локальные права в локальной таблице отображений домена.

Конкретные подробности каждого из протоколов описаны в

[148].

Самый

важный момент во всем этом заключается в том, что архитектура защиты Globus

соответствует описанным ранее правилам защиты. Механизмы реализации этой

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

распределенных систем и будут обсуждаться далее в этой главе. Трудность раз-

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

защиты, сколько с тем, как использовать эти механизмы для обеспечения защи-

ты.

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

8.1.2. Вопросы разработки

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

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

зовать различные правила защиты. При реализации служб защиты общего назна-

чения следует учитывать несколько моментов. Ниже мы рассмотрим три таких

важных момента: фокус управления, многоуровневую организацию механизмов

защиты и простоту

[172].

Фокус управления

Организуя защиту приложений (в том числе и распределенных), можно исполь-

зовать три основных подхода, которые иллюстрирует рис. 8.2. Первый вариант

—

это защита непосредственно ассоциированных с приложением данных. Под «не-

посредственно» мы имеем в виду, что независимо от того, какие операции могут

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

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

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

сти,

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

ных

[466].

Второй вариант

—

это защита путем точного указания того, кто и как может

использовать операции доступа к данным или ресурсам. В этом случае фокус

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

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

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

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

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

ляемому объектом, или собственно объекту. Этот подход также используется

с целью детализации управления доступом.

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

Данные защищены от неверной

или ошибочной операции

Метод

Состояние

Объект

Данные защищены от обращения

неавторизованных агентов

5^ 5-И^

Данные защищены путем

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

Рис. 8.2. Три подхода к противодействию угрозам защите. Защита от неверных операций (а).

Защита от неавторизованных обращений (б). Защита от неавторизованных

пользователей (е)

Третий вариант

—

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

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

независимо от операций, которые они собираются производить. Так, например,

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

всем, кроме высшего управленческого персонала. Другой пример: во многих

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

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

ности управление сведено к определению ролей (roles) пользователей. После

подтверждения соответствующей роли ей предоставляется или запрещается дос-

туп к соответствующим ресурсам. Процесс разработки системы защиты состоит,

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

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

лей. Мы еще поговорим о ролях в следующей главе.

Многоуровневая организация механизмов защиты

Важным моментом при разработке систем защиты является решение о том,

сколько уровней должны иметь механизмы защиты. Уровень в данном контексте

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

сети часто построены из нескольких уровней, в соответствии с некоторой эталон-

ной моделью, о чем мы говорили в главе 2. В главе

мы вводили понятие о такой

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

8.1.

Общие вопросы защиты

467

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

ядра операционной систе-

мы.

Комбинируя многоуровневые структуры компьютерных сетей

распреде-

ленных систем, мы получаем схему, представленную

на

рис. 8.3.

Прикладной уровень

Промежуточный уровень

Службы

ОС

Ядро

ОС

Аппаратура

Транспортный

Сетевой

Канальный

Физический

1 Сеть

Протоколы верхнего уровня

Протоколы нижнего уровня

Прикладной уровень

Промежуточный уровень

Службы

ОС

Транспортный

Сетевой

Канальный

Физический

Ядро

ОС

Аппаратура

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

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

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

по

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

и, в

частности,

для

пред-

ставления

доверии. Разница между доверием

защитой очень важна. Система

может быть или

не

быть защищенной, особенно принимая

во

внимание различ-

ные случайности, но мнение клиента

том, что система защищена

—

это вопрос

доверия

[351].

Уровень,

на

котором размещается механизм защиты, зависит

от

доверия клиента

защите служб этого уровня.

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

нескольких

географически удаленных друг от друга местах, которые соединены коммуника-

ционной службой, такой

как

коммутируемая мультимегабитная служба данных

(Switched Multi-megabit Data Service, SMDS). Сеть SMDS можно рассматривать

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

том числе

и разнесенные

пространстве, как это показано на рис. 8.4 (дополнительную ин-

формацию по SMDS можно найти

[238]).

Шифрующее устройство

Рис. 8.4. Несколько сайтов, связанных глобальной службой магистрали

Защиту можно обеспечить путем установки шифрующего устройства на каж-

дом маршрутизаторе SMDS, как показано на рисунке. Эти устройства автомати-

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

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

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

локальной сети. Если Алиса из сети А посылает сообщение Бобу в сеть Б и бес-

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

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

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

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

вмешательства в работу шифрующих устройств.

Допустим теперь, что Алиса не доверяет защите трафика с удаленными сетя-

ми.

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

защиты транспортного уровня, такую как служба SSL

(Secure Socket

Layer

—

уро-

вень защищенных

сокетов),

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

сылки почты по соединениям TCP. Мы более подробно рассмотрим SSL в гла-

ве 11, когда будем обсуждать защиту в Web. Важно отметить, что SSL позволит

Алисе установить защищенное соединение с Бобом. Все сообщения транспорт-

ного уровня будут зашифрованы

—

и на уровне SMSD тоже, но Алисе это не

важно. В данном случае Алиса доверяет своей службе SSL. Другими словами,

она верит, что SSL ее защитит.

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

жуточном уровне. Если Алиса не доверяет SSL, она может пожелать использо-

вать локальную службу защиты RPC. И опять-таки она должна доверять этой

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

чек информации и верно идентифицирует клиенты и серверы.

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

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

лагаются, также защищены. Так, например, если служба защиты RFC реализова-

на частично на основе SSL, доверие к службе RFC зависит от того, насколько вы

доверяете SSL. Если вы не доверяете защите SSL, то не можете доверять и уров-

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

Распределение механизмов защиты

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

дове-

рентой вычислительной базы

(Trusted

Computing

Base,

TSB). TSB

—

это набор всех

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

осуществления правил защиты. Чем меньше TSB, тем лучше. Если распределен-

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

вующей сетевой операционной системой), ее защита может зависеть от защиты

базовых локальных операционных систем. Другими словами, TSB в распределен-

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

ных хостов.

FaccMOTpHM файловый сервер в распределенной файловой системе. Этот сервер

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

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

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

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

8.1.

Общие вопросы защиты 469

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

поэтому доверия к локальной операционной системе, под управлением которой

они работают. Если такого доверия нет, часть функциональности локальной опе-

рационной системы должна быть встроена в саму распределенную систему. Рас-

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

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

В этом случае, например, стандартная файловая система может быть полностью

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

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

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

пределенную систему промежуточного уровня распределенной операционной

системой, о которой мы говорили в главе 1.

Этому подходу будет соответствовать отделение служб защиты от прочих ви-

дов служб путем распределения этих служб по различным машинам в соответст-

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

щенной распределенной файловой системы можно отделить файловый сервер от

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

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

система. Клиенты и их приложения могут быть размещены на машинах, не вы-

зывающих доверия.

Подобное разделение эффективно уменьшает размер ТСВ до относительно

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

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

ной системы может быть еще увеличено. Предотвращение прямого доступа кли-

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

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

ограниченпого интерфейса

защищенным системным

компонен-

там {Reduced Interfaces for Secure System

Components,

RISSC), как описано в

[316].

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

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

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

казано на рис. 8.5. Клиенты и их приложения работают на различных машинах и

могут взаимодействовать с защищенным сервером только через эти сетевые ин-

терфейсы.

Прямая связь с другими

Серверы с защищенными службами машинами отсутствует

/^и

ж.

W>^

Устройство

управления доступом

Клиенты

Незащищенный сервер

Рис. 8.5. Применение принципов RISSC к защищенным

распределенным системам

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

Простота

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

ет разместить механизмы защиты,

—

это простота. Разработка защищенных компь-

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

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

в которых легко разобраться и правильную работу которых легко гарантировать.

К сожалению, простых механизмов для реализации правил защиты часто не-

достаточно. Рассмотрим снова эпизод, когда Алиса посылает письмо Бобу. Мы

обсуждали его чуть раньше. Шифрование на канальном уровне

—

это простой и

легко

П0НЯТНЫР1

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

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

что еще. Она нуждается в службах аутентификации пользовательского уровня,

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

работают. Поэтому аутентификация пользовательского уровня может потребо-

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

ленных механизмов, таких как сертификация, даже несмотря на то, что многие

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

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

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

включаются сложные протоколы защиты, являются цифровые платежные систе-

мы,

которые мы рассмотрим далее в этой главе. Сложность цифровых платежей

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

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

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

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

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

ствии «прорех» в системе защиты.

8.1.3. Криптография

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

фии. Основная идея этих приемов проста. Рассмотрим отправителя 5, который

хочет переслать сообщение т получателю R. Чтобы обезопасить сообщение от уг-

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

ние т', после чего посылает это т' получателю R. R, в свою очередь, должен рас-

шифровать полученное сообщение и получить оригинал, то есть сообщение т.

Шифрование и расшифровка осуществляются путем применения криптогра-

фических методов с использованием ключей, как показано на рис. 8.6. Исходная

форма посылаемого сообщения, называемая

простым текстом

(plaintext), обо-

значена на рисунке как Р, его зашифрованный вариант, известный как

шифро-

ванный

текст

(ciphertext), обозначен как С.

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

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

го текста, шифрованного текста и ключей. В соответствии с общими соглаше-