Книги по разным темам Pages:     | 1 | 2 | Электронный журнал ИССЛЕДОВАНО В РОССИИ 2156 Контроль доступа с протоколированием изменений в распределенной децентрализованной файловой системе (TorFS) Обернихин В.А.( obernikhin@8ka.mipt.ru), Тормасов А.Г.

Исследовательское подразделение Компании SWSoft, Inc., USA Аннотация В данной статье предложена модель системы контроля доступа c протоколированием изменений для распределенной одноранговой файловой системы TorFS [1-3]. В основе модели лежит использование криптографических средств и фактически контроль доступа к файлам и директориям осуществляется на локальной машине пользователя. В системе ведется протоколирование изменений файлов и директорий пользователями системы.

Введение В последнее время появляется все больше распределенных одноранговых1 файловых систем (можно привести в качестве примера [4-8] и др.). Часто для обеспечения отказоустойчивости данные в таких системах хранятся с избыточностью - используются либо реплики - копии файлов на разных лузлах сети, либо пороговая (n,k) -схема, в этом случае файл делится на n частей так, что любых k ( k n ) из них достаточно, чтобы восстановить файл. Если некоторый пользователь решил сделать свой компьютер частью распределенной одноранговой файловой системы и хранить в ней свои файлы, то для обеспечения отказоустойчивости файлы должны храниться не только на компьютере пользователя, но и на других лузлах системы. При необходимости обеспечения контроля доступа к файлам в условиях отсутствия надежного центра, который проверял бы полномочия доступа к ним, нужно использовать средства криптографии.

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

Однако при сколь-нибудь значительном количестве файлов подобное распределение ключей становится неудобным. В данной работе предлагается модель распределения ключей доступа к файлам, интегрированная с распределенной файловой системой TorFS[1-3]. В отличие от предложенной авторами ланонимной модели [9], в данной модели системы контроля доступа ведется протоколирование изменений файлов и директорий.

1. Структура распределенной одноранговой файловой системы TorFS Структура распределенной децентрализованной файловой системы TorFS подробно описана в [1-3]. Приведем краткое описание.

Термин лодноранговая система часто используется в качестве перевода на русский язык термина Уpeer-to-peer systemФ и подразумевает систему без выделенного сервера. Насколько известно авторам, самого понятия ранг по отношению к распределенным системам не вводится.

Электронный журнал ИССЛЕДОВАНО В РОССИИ 2157 Файловая система TorFS позволяет пользователям сохранять с задаваемой избыточностью файлы в системе - части файла располагаются на различных узлах сети, и даже если некоторые из этих узлов становятся недоступными, можно восстановить файл с помощью информации на оставшихся доступными узлах системы. Для разделения файла, а точнее - блоков файла (см.

ниже), на части используется пороговая (n, k) -схема.

Относительно системы TorFS все компьютеры в сети Интернет можно разделить на:

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

б) компьютеры, с которых пользователи считывают или записывают файлы в систему - компьютеры пользователей;

в). все остальные компьютеры.

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

Топологический сервер отвечает за связь лузла сети с несколькими (лближайшими) лузламисоседями. Директорный сервер выполняет преобразование текстового пути к файлу в числовой идентификатор FID. Файлы записываются в систему в виде блоков. Каждый блок имеет идентификатор (BID), уникальный в пределах одного файла. В свою очередь, блоки файла делятся с использованием пороговой (n,k) -схемы на более мелкие части (лслайсы), которые и записываются на файловые серверы различных узлов системы. Хотелось бы отметить, что система не является распределенным блочным устройством, т.е. работает на уровне файлов, а не на уровне блоков. Блоки вводятся лишь для оптимизации работы системы.

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

2. Контроль доступа в файловой системе TorFS 2.1. Требования к распределенной файловой системе TorFS, касающиеся защиты информации:

2.1.1. Работоспособность в условиях отсутствия доверия к программному обеспечению распределенной файловой системы, работающему не на локальном компьютере пользователя. Контроль доступа должен обеспечиваться в предположении, что каждый пользователь доверяет только программному обеспечению (ПО), работающему на локальном компьютере пользователя. Любой другой файловый/директорный/кэш- и т.д. сервер системы потенциально может быть взломан и/или принадлежать нарушителю.

2.1.2. Контроль доступа. В системе должна предусматриваться возможность разрешать доступ только определенным пользователям к файлам/директориям.

Электронный журнал ИССЛЕДОВАНО В РОССИИ 2158 2.1.3. Обеспечение целостности и аутентичности данных. Система должна обеспечивать целостность и аутентичность хранящихся в ней данных.

2.2. Обеспечение работоспособности файловой системы Вследствие требования 2.1.1 в системе не может быть использован единый сервер контроля доступа. Вместо этого для контроля доступа используются криптографические средства и фактически контроль доступа перенесен на локальную машину пользователя.

Всё содержимое файлов и часть служебной информации подвергается шифрованию. Для каждого файла генерируется пара2 лоткрытый ключ/секретный ключ для шифрования/расшифрования файла и формируется список пользователей, которым разрешена запись в файл. Для выполнения операции чтения необходим секретный ключ для расшифрования файла и открытые ключи для проверки ЭЦП пользователей, которым разрешена запись в файл.

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

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

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

2.2.1. Файл Каждый файл в системе TorFS имеет уникальный числовой идентификатор (FID). В директорной записи (см. ниже) к данному файлу расположен список контроля доступа (accesscontrol list, ACL), содержащий пару лоткрытый ключ/секретный ключ для шифрования/расшифрования данного файла ( PubF / PrivF ) и список пользователей, которым разрешена запись в файл.

Нулевой блок хранит служебную информацию, в частности: TID, список блоков, записанных в результате данной транзакции, а также список значений хэш-функции от шифротекстов данных блоков.

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

Вместо использования одной пары лоткрытый ключ/секретный ключ возможен вариант с двумя парами ключей:

( PubF / PrivF ) и (VkF / SkF ) для каждого файла, одна - для шифрования/расшифрования, другая - для проверки/генерации ЭЦП. В этом случае для контроля аутентичности файла используется ЭЦП, созданная при помощи ключа SkF. Подобную модель можно назвать ланонимной, поскольку после записи файла неизвестно, кто из пользователей, обладающих правом записи в файл, в действительности произвел её. Данная модель рассмотрена в [9].

Электронный журнал ИССЛЕДОВАНО В РОССИИ 2159 FID TID K Блоки транзакции шифруются на ключе транзакции, который T BID = BIDгенерируется заново для каждой транзакции. Каждый блок файла Hash from идентифицируется двумя числами: BID и TID. Таким образом, для того, encrypted чтобы воссоздать файл на локальной машине, пользователь собирает block BIDблоки файла, проверяет их аутентичность, после чего расшифровывает BID = BIDих и получает файл.

Hash from encrypted block BIDРис. 1. Структура служебного блока транзакции, в результате которой были asymm EPub (KT ) изменены блоки с BID = BID1 и BID = BID2.

F Ui Digital Signature 2.2.2. Структура директории Директории предназначены для сопоставления текстового пути к файлу и FID.

Содержимое директории хранится в виде файла. Файл директории состоит из записей вида:

УFileName|FID|ACLФ, то есть списки ACL для файлов хранятся в директорных записях для данного файла. Каждая запись представляет из себя отдельный блок файла директории для удобства операций добавления/удаления директорных записей.

Служебная информация директории TID BID = Hash from encrypted BlockBID = Hash from encrypted BlockBID = Hash from encrypted Blockasymm Зашифрованные EPub (KT ) F блоки файла директории ЭЦП BID = Директория FileName1 FiD1 ACLTID /dir1/dirBID = FileName1 FiD2 ACLTID Файл /dir1/dir2/FileNameBID = FileName3 FiD3 ACLTID Служебная информация файла FID3 File Рис. 2. Структура содержимого файла директории Электронный журнал ИССЛЕДОВАНО В РОССИИ 2160 2.2.3. Структура ACL Контроль доступа к файлу (директории) осуществляется при помощи пары лоткрытый ключ/секретный ключ (для реализации доступа типа чтение ) и ЭЦП (для реализации доступа типа запись). ЭЦП генерируется пользователями, которым разрешена запись в файл. Список контроля доступа (ACL ) состоит из двух списков: а). УReader listФ - записи о пользователях, обладающих правом чтения файла; б). УWriter listФ - записи о пользователях, обладающих правом записи в файл.

Если пользователю с идентификатором Ui1 разрешено чтение файла, то в списке УReader asymm listФ есть элемент: {Ui1 | EPub (PrivF )}, содержащий идентификатор пользователя и секретный Uiключ PrivF, зашифрованный открытым ключом пользователя PubUi.

Для пользователя с идентификатором Uj1, обладающего правом записи в файл, в списке asymm УWriter listФ есть элемент {Uj1 | EPub (PubF )}, содержащий идентификатор пользователя и Ujзашифрованный открытым ключом пользователя открытый ключ PubF.

Хотелось бы отметить, что asymm Reader list {Ui1|EPubUi (PrivF)} Access info for поскольку одна и та же информация Readerшифруется открытыми ключами Access info for различных пользователей, необходимо Readerвводить рандомизацию или использовать...

криптосистемы с открытым ключом, в asymm Writer list {Uj1|EPubUj (PubF)} которых она заложена в конструкцию Access info for (например, криптосистему Эль-Гамаля).

WriterAccess info for Модифицировать ACL могут Writer... пользователи, обладающие правом на запись в директорию, в которой находится Рис. 3. Структура ACL директорная запись с данным ACL3. Таким образом, пользователь с правом записи в директорию может получить полный контроль над файлом, модифицировав ACL и записав новую версию данного файла (фактически, удалив старый файл и создав новый с таким же названием). Если к тому же пользователь знал содержимое файла, то для некоторых пользователей такая смена привилегий доступа к файлу может пройти незаметно - при условии, что для них привилегии не были изменены. Привилегия записи в директорию является достаточно опасной, давать ее пользователям нужно с большой осторожностью.

2.2.4. Корневая директория FID для корневой директории У/Ф является предопределенным, а. ACL для нее - отсутствует. Для проверки ЭЦП (транзакций) корневой директории в системе имеется специальный ключ VkRootDir, который должен быть известен всем пользователям системы.

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

Электронный журнал ИССЛЕДОВАНО В РОССИИ 2161 Администратора системы. Таким образом, содержимое корневой директории открыто для чтения всем пользователям, но осуществлять запись в корневую директорию может только Администратор.

2.3. Примеры основных операций в системе Детальное описание основных операций в системе можно найти в [1]. Ниже приводятся фрагменты операций, модифицированные с учетом механизма контроля доступа.

2.3.1. Чтение файла по известному FID и ACL.

Pages:     | 1 | 2 |    Книги по разным темам