CC BY
23Контроль доступа с протоколированием изменений в распределенной децентрализованной файловой
системе (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]. Приведем краткое описание.
1 Термин «одноранговая система» часто используется в качестве перевода на русский язык термина "peer-to-peer system" и подразумевает систему без выделенного сервера. Насколько известно авторам, самого понятия «ранг» по отношению к распределенным системам не вводится.
Файловая система TorFS позволяет пользователям сохранять с задаваемой избыточностью файлы в системе - части файла располагаются на различных узлах сети, и даже если некоторые из этих узлов становятся недоступными, можно восстановить файл с помощью информации на оставшихся доступными узлах системы. Для разделения файла, а точнее - блоков файла (см. ниже), на части используется пороговая (n, k) -схема.
Относительно системы TorFS все компьютеры в сети Интернет можно разделить на:
а) компьютеры, благодаря которым данная система функционирует - «узлы» системы;
б) компьютеры, с которых пользователи считывают или записывают файлы в систему -
«компьютеры пользователей»;
в). все остальные компьютеры.
Существует несколько типов серверов в системе: директорные, топологические, файловые, кэширования, и пользовательские (или «клиентские») серверы. Пользователь взаимодействует с системой, используя «пользовательский» сервер. В минимальной конфигурации именно «пользовательский» сервер, в частности выполняющий операции сборки-разборки файлов на части, должен быть установлен на «компьютере пользователя». На данный сервер и будет возложена задача выполнять криптографические операции над файлами/директориями. Топологический сервер отвечает за связь «узла» сети с несколькими («ближайшими») «узлами»-соседями. Директорный сервер выполняет преобразование текстового пути к файлу в числовой идентификатор FID. Файлы записываются в систему в виде блоков. Каждый блок имеет идентификатор (BID), уникальный в пределах одного файла. В свою очередь, блоки файла «делятся» с использованием пороговой (n, k)-схемы на более мелкие части («слайсы»), которые и записываются на файловые серверы различных узлов системы. Хотелось бы отметить, что система не является распределенным блочным устройством, т.е. работает на уровне файлов, а не на уровне блоков. Блоки вводятся лишь для оптимизации работы системы.
Так как изменение файла подразумевало бы изменение блоков и «слайсов» на разных и, возможно, не все время подключенных к сети компьютерах, была выбрана схема, при которой записанные в систему блоки являются неизменными (immutable). При записи измененного файла в систему записывается новая транзакция (версия) файла. Кроме BID каждый блок несет на себе идентификатор транзакции TID, зависящий от времени. Список измененных блоков вместе с другой служебной информацией хранится в нулевом (служебном) блоке транзакции. При поиске файла в системе пользователь задает диапазон времени модификации файла, либо запрашивает наиболее позднюю версию файла в системе.
2. Контроль доступа в файловой системе TorFS
2.1. Требования к распределенной файловой системе TorFS, касающиеся защиты информации:
2.1.1. Работоспособность в условиях отсутствия доверия к программному обеспечению распределенной файловой системы, работающему не на локальном компьютере пользователя. Контроль доступа должен обеспечиваться в предположении, что каждый пользователь доверяет только программному обеспечению (ПО), работающему на локальном компьютере пользователя. Любой другой файловый/директорный/кэш- и т.д. сервер системы потенциально может быть «взломан» и/или принадлежать «нарушителю».
2.1.2. Контроль доступа. В системе должна предусматриваться возможность разрешать доступ только определенным пользователям к файлам/директориям.
2.1.3. Обеспечение целостности и аутентичности данных. Система должна обеспечивать целостность и аутентичность хранящихся в ней данных.
2.2. Обеспечение работоспособности файловой системы
Вследствие требования 2.1.1 в системе не может быть использован единый сервер контроля доступа. Вместо этого для контроля доступа используются криптографические средства и фактически контроль доступа перенесен на локальную машину пользователя.
Всё содержимое файлов и часть служебной информации подвергается шифрованию. Для каждого файла генерируется пара2 «открытый ключ/секретный ключ» для шифрования/расшифрования файла и формируется список пользователей, которым разрешена запись в файл. Для выполнения операции чтения необходим секретный ключ для расшифрования файла и открытые ключи для проверки ЭЦП пользователей, которым разрешена запись в файл. Для записи в файл необходимо знать открытый ключ для шифрования файла и принадлежать к списку пользователей, которым разрешена запись в файл. Соответствующие ключи и списки должны где-то храниться и быть доступными легальным пользователям - возникает необходимость использования списков контроля доступа (ACL). В предлагаемой модели в ACL открытыми ключами пользователей зашифрованы соответствующие ключи доступа к файлу. Заметим, что если пары ключей двух различных пользователей совпадают, такие пользователи будут неразличимы с точки зрения системы, несмотря на то, что идентификаторы пользователей будут различными.
Тем не менее, это лишь упрощенный взгляд на модель контроля доступа. Поскольку асимметричные криптосистемы, как правило, работают на 2-3 порядка медленнее симметричных систем, шифрование/расшифрование файлов оптимальнее производить с использованием симметричного шифрования на «ключе транзакции» (сессионном ключе), а ключ транзакции шифровать далее с помощью асимметричного шифрования.
2.2.1. Файл
Каждый файл в системе TorFS имеет уникальный числовой идентификатор (FID). В директорной записи (см. ниже) к данному файлу расположен список контроля доступа (access-control list, ACL), содержащий пару «открытый ключ/секретный ключ» для шифрования/расшифрования данного файла (PubF / PrivF) и список пользователей, которым разрешена запись в файл.
Нулевой блок хранит служебную информацию, в частности: TID, список блоков , записанных в результате данной транзакции, а также список значений хэш-функции от шифротекстов данных блоков.
Аутентичность служебного (или «нулевого») блока гарантируется ЭЦП, сгенерированной одним из пользователей,обладающих правом записи в файл. Нулевой блок хранится в открытом виде.
2Вместо использования одной пары «открытый ключ/секретный ключ» возможен вариант с двумя парами ключей: (РыЬР /РпУр) и (Укр /8кр ) для каждого файла, одна - для шифрования/расшифрования, другая - для проверки/генерации ЭЦП. В этом случае для контроля аутентичности файла используется ЭЦП, созданная при помощи ключа 8кр . Подобную модель можно назвать «анонимной», поскольку после записи файла неизвестно, кто из пользователей, обладающих правом записи в файл, в действительности произвел её. Данная модель рассмотрена в
[9].
BID = BID1
Hash from encrypted block BID1
BID = BID2
Hash from encrypted block BID2
„asymm(K ) EPubF (KT)
U.
Блоки транзакции шифруются на «ключе транзакции» KT , который генерируется заново для каждой транзакции. Каждый блок файла идентифицируется двумя числами: BID и TID. Таким образом, для того, чтобы воссоздать файл на локальной машине, пользователь собирает блоки файла, проверяет их аутентичность, после чего расшифровывает их и получает файл.
Рис. 1. Структура служебного блока транзакции, в результате которой были изменены блоки с BID = BID1 и BID = BID2.
Digital Signature
2.2.2. Структура директории
Директории предназначены для сопоставления текстового пути к файлу и FID. Содержимое директории хранится в виде файла. Файл директории состоит из записей вида: "FileName|FID|ACL", то есть списки ACL для файлов хранятся в директорных записях для данного файла. Каждая запись представляет из себя отдельный блок файла директории для удобства операций добавления/удаления директорных записей.
-FID3
Служебная
информация
файла
File
Рис. 2. Структура содержимого файла директории
2.2.3. Структура ACL
Контроль доступа к файлу (директории) осуществляется при помощи пары «открытый ключ/секретный ключ» (для реализации доступа типа «чтение» ) и ЭЦП (для реализации доступа типа «запись»). ЭЦП генерируется пользователями, которым разрешена запись в файл. Список контроля доступа (ACL ) состоит из двух списков: а). "Reader list" - записи о пользователях, обладающих правом чтения файла; б). "Writer list" - записи о пользователях, обладающих правом записи в файл.
Если пользователю с идентификатором Ui разрешено чтение файла, то в списке "Reader
list" есть элемент: {Ui1 | E^b1™ (PrivF)}, содержащий идентификатор пользователя и секретный
и Ui1
ключ PrivF, зашифрованный открытым ключом пользователя Pub^ .
1
Для пользователя с идентификатором Uj , обладающего правом записи в файл, в списке
"Writer list" есть элемент {Uj | E^b1™ (PubF)}, содержащий идентификатор пользователя и
и Ujj
зашифрованный открытым ключом пользователя открытый ключ PubF.
Reader list
Access info for Readerl
Access info for Reader2
Writer list
Access info for Witerl
Access info for Witer2
(Ц! Epm^iPriVp )}
{U1I EpjPubp )}
Хотелось бы отметить, что поскольку одна и та же информация шифруется открытыми ключами различных пользователей, необходимо вводить рандомизацию или использовать криптосистемы с открытым ключом, в которых она заложена в конструкцию (например, криптосистему Эль-Гамаля).
Модифицировать ACL могут пользователи, обладающие правом на запись в директорию, в которой находится директорная запись с данным ACL3. Таким образом, пользователь с правом записи в директорию может получить полный контроль над файлом, модифицировав ACL и записав новую версию данного файла (фактически, удалив старый файл и создав новый с таким же названием). Если к тому же пользователь знал содержимое файла, то для некоторых пользователей такая смена привилегий доступа к файлу может пройти незаметно - при условии, что для них привилегии не были изменены. Привилегия записи в директорию является достаточно опасной, давать ее пользователям нужно с большой осторожностью.
Рис. 3. Структура ACL
2.2.4. Корневая директория
FID для корневой директории "/" является предопределенным, а. ACL для нее -отсутствует. Для проверки ЭЦП (транзакций) корневой директории в системе имеется специальный ключ VkR00Dir, который должен быть известен всем пользователям системы.
Соответствующий секретный ключ для генерации ЭЦП Sk^^ofDir есть только у
3 Возможен вариант, когда модифицировать ACL могут только пользователи из специально заведенных списков.
Администратора системы. Таким образом, содержимое корневой директории открыто для чтения всем пользователям, но осуществлять запись в корневую директорию может только Администратор.
2.3. Примеры основных операций в системе
Детальное описание основных операций в системе можно найти в [1]. Ниже приводятся фрагменты операций, модифицированные с учетом механизма контроля доступа.
2.3.1. Чтение файла по известному FID и ACL.
Для чтения файла пользователь запрашивает в системе файл с заданным FID, при этом указывая либо конкретную транзакцию (версию) файла, либо последнюю (по времени). На полученных в ответ на запрос нулевых блоках пользователь находит идентификаторы подписавших транзакции пользователей Ui, проверяет, содержится ли запись об Ui в списке "Writer list" ACL. Если такая запись найдена, необходимо при помощи ключа для проверки ЭЦП Vkvi пользователя Ui проверить, действительно ли подпись на нулевом блоке была
сгенерирована Ui. В случае положительного ответа пользователь запрашивает блоки с необходимыми BID и TID. Получив запрошенные блоки файла, пользователь сверяет значения хэш-функции от зашифрованных блоков со значениями, содержащимися в нулевом блоке. Если значения совпали, необходимо расшифровать блоки. Если пользователь имеет право на чтение файла, то в ACL к файлу для данного пользователя содержится ключ PrivF.
Пользователь расшифровывает содержащийся в нулевом блоке ключ транзакции KT и расшифровывает полученные блоки файла.
Утверждение 1: для того, чтобы пользователь мог прочитать содержимое файла, необходимо и достаточно, чтобы у пользователя было право на чтение файла (пользователь должен знать ключ PrivF ).
Доказательства к данному и следующим ниже утверждениям из-за ограничения объема статьи мы, к сожалению, привести не можем, однако, они почти очевидны, если принять во внимание предположения, подразумевающие «невзламываемость» шифров и «невозможность» найти коллизии для хэш-функций: для того, чтобы прочитать зашифрованный текст, необходимо знать ключ для расшифрования, по открытому ключу «невозможно» определить секретный и т.д.
Утверждение2: право на запись в файл не дает права на чтение.
2.3.2. Модификация файла (известны FID и ACL)
Поскольку пользователь (с идентификатором U j ) записывает новую транзакцию уже
существующего файла, то ему не нужно делать запись в директорию, содержащую данный файл и, соответственно, не нужно права записи в директорию. Пользователь генерирует
случайным образом ключ транзакции KT , шифрует блоки транзакции на данном ключе и вычисляет значение хэш-функции на каждом из блоков. После этого список идентификторов (BID) блоков транзакции и значения хэш-функции на зашифрованных блоках помещаются в
нулевой блок транзакции вместе с ключом KT , зашифрованным на ключе PubF . Нулевой блок подписывается при помощи ключа пользователя для генерации ЭЦП SkUj .
Зашифрованные блоки файла записываются в систему, после чего записывается нулевой блок.
УтверждениеЗ: если у пользователя нет права записи в директорию, содержащую файл, то для того, чтобы записать валидную транзакцию файла, необходимо и достаточно иметь право на запись данного файла.
Утверждение4: если у пользователя нет права записи в директорию, содержащую файл, то право на чтение не дает права на запись в файл.
2.3.3. Чтение и модификация директории с заданными FID и ACL
Директория хранится в системе как обычный файл, поэтому чтение и модификация директории происходит как указано в п. 2.3.1, 2.3.2. Заметим, что при модификации директории не нужно модифицировать содержимое вышестоящей директории. Таким образом, при модификации файла/директории не нужно полномочий на модификацию всех директории вплоть до корневой.
2.3.4. Чтение директории по заданному пути к ней
Директория
■FIDO-
Проверка ЭЦП
Ук
RootDir
Служебная информация директории "/"
dirl FID1 ACL1 -
-
Расшифрование содержимого
Ук
dirl
Проверка ЭЦП
Priv
dirl
FID1
Директория "/dirl"
Служебная информация директории "/dirl"
ll
dir2 FID2 ACL2
Рис. 4
Предположим, пользователю необходимо прочитать содержимое директории /dir1/dir2/dir3/dir4. Для этого пользователь должен сначала восстановить на своем компьютере файл корневой директории "/", FID которой является предопределенным в системе. При помощи известного всем пользователям системы ключа VkR d-
пользователь проверяет ЭЦП на (нулевом блоке) корневой директории. Поскольку корневая директория открыта на чтение для всех, пользователь считывает FID и ACL для директории dirl.
Предположим, у пользователя есть право на чтение директорий dirl, dir2 и dir4, но нет права на чтение dir3. Пользователь проверяет ЭЦП dirl расшифровывает содержимое dirl, получает FID и ACL для директории dir2. Затем он проверяет ЭЦП dir2, расшифровывает dir2, получает FID и ACL для dir3. Но у пользователя нет права на чтение dir3, соответственно, он не может расшифровать dir3 и получить FID и ACL для dir4.
Таким образом, для получения FID директории или файла по заданному пути пользователь должен иметь право на чтение всех директорий в пути.
2.3.5. Создание (запись) нового файла
Для создания нового файла пользователю нужно:
• сгенерировать FID и создать ACL для данного файла
• модифицировать содержимое файла директории, в которую пользователь помещает данный файл (добавить туда запись, содержащую имя, FID и ACL для данного файла).
• поместить транзакцию данного файла в систему
Таким образом, право создания файла фактически есть право на запись в директорию, в которую помещается файл.
2.3.6. Удаление файла
Для того, чтобы удалить файл, нужно модифицировать директорию, содержащую файл -удалить запись о данном файле. То есть, право на удаление файла - это право на запись в директорию, в которой находится файл.
2.3.7. Разрешение чтения файла (директории)
Пользователь, обладающий правом чтения файла (знающий ключ Privp) и правом записи в
директорию, в которой содержится файл, может разрешить доступ на чтение файла другому пользователю (Ui). Для этого нужно добавить зашифрованный открытым ключом пользователя ключ Privp (запись вида {Ui | Ер^Щ (Privp)}) в "Reader list" в ACL для
данного файла. Поскольку ACL содержится в файле директории, для модификации ACL необходимо модифицировать файл директории, т. е. нужно обладать правами на запись в файл директории.
Утверждение5: для того, чтобы при неизменных ключах доступа к файлу дать другому пользователю право чтения данного файла, необходимо и достаточно одновременно:
• иметь право на запись в директорию, содержащую файл.
• иметь право на чтение данного файла;
2.3.8. Разрешение записи в файл (директорию)
Пользователь, обладающий правом записи в файл и правом на запись в директорию, в которой содержится данный файл, может разрешить запись в этот файл другому
пользователю, добавив соответствующую запись в список "Writer list" в ACL для данного файла.
Утверждениеб: для того, чтобы при неизменных ключах доступа к файлу дать другому пользователю право на запись данного файла, необходимо и достаточно одновременно:
• иметь право на запись этого файла;
• иметь право на запись в директорию, содержащую файл.
Тем не менее, пользователь, обладающий правом на запись в директорию, в которой находится файл, может полностью поменять ключи доступа к файлу и сгенерировать новый ACL. Данная ситуация рассмотрена в п. 2.2.3.
2.3.9. Запрещение записи файла (директории)
Явного запрещения выполнения операций записи/чтения не существует. Пользователь может иметь или не иметь права записи/чтения. Если нужно отозвать у пользователя право на запись файла, следует удалить соответствующий элемент списка "Writer list".
2.3.10. Запрещение чтения файла (директории)
Если нужно отозвать у пользователя право на чтение, то необходимо сменить пару ключей файла для шифрования/расшифрования файла (PubF / PrivF). Изменения ACL и
удаления соответствующего элемента из списка "Reader list" недостаточно, поскольку пользователь мог сохранить у себя ключ для чтения данного файла.
2.3.11. Смена ключа пользователя
Смена ключа пользователя влечет за собой изменение всех ACL, в которых содержатся записи для данного пользователя (в списках Readers/Writers), что является нетривиальной задачей, если не вводить в системе «обратные ссылки»: для каждого пользователя нужны ссылки на файлы, к которым он имеет доступ. В качестве решения можно завести специальный файл, в котором будут храниться пути к файлам, к которым пользователь имеет доступ.
2.3.12. Группы пользователей
В существующей модели группу пользователей можно ввести лишь как одного из пользователей со своей парой ключей. Соответственно, пользователь входит в группу, если у него есть секретный ключ группы. Основная проблема при таком подходе состоит в том, что при удалении пользователя из группы необходимо сменить ключи группы - см. предыдущий пункт.
2.3.13. Аутентификация пользователей системы
Для того, чтобы дать некоторому пользователю право доступа к информации, хранящейся в системе, необходимо знать его идентификатор и открытый ключ для шифрования. Возникает задача сопоставления идентификаторов пользователей и их открытых ключей. Для этих целей, в принципе, можно воспользоваться любой
инфраструктурой открытых ключей (PKI). Как вариант, возможно хранение сертификатов пользователей в самой файловой системе - сделать дерево директорий, совпадающее, например, со структурой DN (distinguished names) сертификатов X.509.
2.3.14. Протоколирование изменений
Поскольку каждое изменений файлов и директорий подписывается пользователем, а его идентификатор Ui хранится в в служебном блоке транзакции, легко восстановить кем было сделано это изменение.
3. Заключение
В данной статье построена модель контроля доступа для распределенной системы хранения данных, в которой отсутствует центр выдачи полномочий. К сожалению, из-за ограничения объема статьи нет возможности привести доказательства гарантий выполнения задаваемых пользователем привилегий доступа к файлам/директориям. Систему можно отнести к классу дискреционных систем контроля доступа. При соблюдении приведенных в Утверждениях условий гарантируется конфиденциальность, аутентичность хранимой информации и контроль доступа к ней. В системе существует протоколирование изменений файлов и директорий.
В построенной системе контроля доступа не требуется безопасности серверов и удаленных систем, требуется только безопасность «клиентов» - локальных машин пользователей.
Литература
1. Хасин М.А. «Модель распределенного хранилища в глобальной сети» // Диссертация на соискание степени кандидата физ.-мат. наук. МФТИ, 2001.
2. Пакулин К. Р. Система распределенного хранения данных на сети Интернет. Оптимизация алгоритмов сервера обслуживания клиентов и локального хранения файлов // Труды 1-ой международной конференции по системам виртуального окружения на кластерах персональных компьютеров, стр.160-182. Протвино, 2001.
3. Ильин Р.Ю. Сервер поддержки топологии распределенной файловой системы TorFS// Труды 1-ой международной конференции по системам виртуального окружения на кластерах персональных компьютеров, сс.138-159, Протвино, 2001.
4. Gnutella (http://www.gnutella.com/)
5. KazAA (http://www.kazaa.com/)
6. http://freenet.sourceforge.net
7. http://oceanstore. cs.berkeley.edu
8. http://research.microsoft.com./sn/Farsite
9. Обернихин В. А., Тормасов А.Г. Схема контроля доступа для распределенной одноранговой файловой системы (TorFS) // Безопасность информационных технологий. Вып. 4. 2004.(находится в редакции)
