WWW.DISSERS.RU

БЕСПЛАТНАЯ ЭЛЕКТРОННАЯ БИБЛИОТЕКА

   Добро пожаловать!

Pages:     | 1 ||

Для чтения файла пользователь запрашивает в системе файл с заданным FID, при этом указывая либо конкретную транзакцию (версию) файла, либо последнюю (по времени). На полученных в ответ на запрос нулевых блоках пользователь находит идентификаторы подписавших транзакции пользователей Ui, проверяет, содержится ли запись об Ui в списке “Writer list” ACL. Если такая запись найдена, необходимо при помощи ключа для проверки ЭЦП VkUi пользователя Ui проверить, действительно ли подпись на нулевом блоке была сгенерирована Ui. В случае положительного ответа пользователь запрашивает блоки с необходимыми BID и TID. Получив запрошенные блоки файла, пользователь сверяет значения хэш-функции от зашифрованных блоков со значениями, содержащимися в нулевом блоке. Если значения совпали, необходимо расшифровать блоки. Если пользователь имеет право на чтение файла, то в ACL к файлу для данного пользователя содержится ключ PrivF.

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

Утверждение1: для того, чтобы пользователь мог прочитать содержимое файла, необходимо и достаточно, чтобы у пользователя было право на чтение файла (пользователь должен знать ключ PrivF ).

Доказательства к данному и следующим ниже утверждениям из-за ограничения объема статьи мы, к сожалению, привести не можем, однако, они почти очевидны, если принять во внимание предположения, подразумевающие «невзламываемость» шифров и «невозможность» найти коллизии для хэш-функций: для того, чтобы прочитать зашифрованный текст, необходимо знать ключ для расшифрования, по открытому ключу «невозможно» определить секретный и т.д.

Утверждение2: право на запись в файл не дает права на чтение.

2.3.2. Модификация файла (известны FID и ACL) Поскольку пользователь (с идентификатором U ) записывает новую транзакцию уже j существующего файла, то ему не нужно делать запись в директорию, содержащую данный файл и, соответственно, не нужно права записи в директорию. Пользователь генерирует KT случайным образом ключ транзакции, шифрует блоки транзакции на данном ключе и вычисляет значение хэш-функции на каждом из блоков. После этого список идентификторов (BID) блоков транзакции и значения хэш-функции на зашифрованных блоках помещаются в KT PubF нулевой блок транзакции вместе с ключом, зашифрованным на ключе. Нулевой блок подписывается при помощи ключа пользователя для генерации ЭЦП SkUj.

Электронный журнал «ИССЛЕДОВАНО В РОССИИ» 2162 http://zhurnal.ape.relarn.ru/articles/2004/203.pdf Зашифрованные блоки файла записываются в систему, после чего записывается нулевой блок.

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

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

2.3.3. Чтение и модификация директории с заданными FID и ACL Директория хранится в системе как обычный файл, поэтому чтение и модификация директории происходит как указано в п. 2.3.1, 2.3.2. Заметим, что при модификации директории не нужно модифицировать содержимое вышестоящей директории. Таким образом, при модификации файла/директории не нужно полномочий на модификацию всех директории вплоть до корневой.

2.3.4. Чтение директории по заданному пути к ней VkRootDir Проверка ЭЦП Директория “/” Служебная информация директории “/” Расшифрование содержимого FIDdir1 FID1 ACLVkdir1 Проверка ЭЦП PrivdirFIDСлужебная информация директории “/dir1” Директория dir2 FID2 ACL“/dir1” Рис. Предположим, пользователю необходимо прочитать содержимое директории /dir1/dir2/dir3/dir4. Для этого пользователь должен сначала восстановить на своем компьютере файл корневой директории “/”, FID которой является предопределенным в системе. При помощи известного всем пользователям системы ключа VkRootDir Электронный журнал «ИССЛЕДОВАНО В РОССИИ» 2163 http://zhurnal.ape.relarn.ru/articles/2004/203.pdf пользователь проверяет ЭЦП на (нулевом блоке) корневой директории. Поскольку корневая директория открыта на чтение для всех, пользователь считывает FID и ACL для директории dir1.

Предположим, у пользователя есть право на чтение директорий dir1, dir2 и dir4, но нет права на чтение dir3. Пользователь проверяет ЭЦП dir1 расшифровывает содержимое dir1, получает FID и ACL для директории dir2. Затем он проверяет ЭЦП dir2, расшифровывает dir2, получает FID и ACL для dir3. Но у пользователя нет права на чтение dir3, соответственно, он не может расшифровать dir3 и получить FID и ACL для dir4.

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

2.3.5. Создание (запись) нового файла Для создания нового файла пользователю нужно:

• cгенерировать FID и создать ACL для данного файла • модифицировать содержимое файла директории, в которую пользователь помещает данный файл (добавить туда запись, содержащую имя, FID и ACL для данного файла).

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

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

2.3.7. Разрешение чтения файла (директории) Пользователь, обладающий правом чтения файла (знающий ключ PrivF ) и правом записи в директорию, в которой содержится файл, может разрешить доступ на чтение файла другому пользователю ( ). Для этого нужно добавить зашифрованный открытым ключом Ui asymm пользователя ключ PrivF (запись вида {Ui | EPub (PrivF )}) в “Reader list” в ACL для Ui данного файла. Поскольку ACL содержится в файле директории, для модификации ACL необходимо модифицировать файл директории, т.е. нужно обладать правами на запись в файл директории.

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

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

• иметь право на чтение данного файла;

2.3.8. Разрешение записи в файл (директорию) Пользователь, обладающий правом записи в файл и правом на запись в директорию, в которой содержится данный файл, может разрешить запись в этот файл другому Электронный журнал «ИССЛЕДОВАНО В РОССИИ» 2164 http://zhurnal.ape.relarn.ru/articles/2004/203.pdf пользователю, добавив соответствующую запись в список “Writer list” в ACL для данного файла.

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

• иметь право на запись этого файла;

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

Тем не менее, пользователь, обладающий правом на запись в директорию, в которой находится файл, может полностью поменять ключи доступа к файлу и сгенерировать новый 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. Аутентификация пользователей системы Для того, чтобы дать некоторому пользователю право доступа к информации, хранящейся в системе, необходимо знать его идентификатор и открытый ключ для шифрования. Возникает задача сопоставления идентификаторов пользователей и их открытых ключей. Для этих целей, в принципе, можно воспользоваться любой Электронный журнал «ИССЛЕДОВАНО В РОССИИ» 2165 http://zhurnal.ape.relarn.ru/articles/2004/203.pdf инфраструктурой открытых ключей (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.(находится в редакции)

Pages:     | 1 ||



© 2011 www.dissers.ru - «Бесплатная электронная библиотека»

Материалы этого сайта размещены для ознакомления, все права принадлежат их авторам.
Если Вы не согласны с тем, что Ваш материал размещён на этом сайте, пожалуйста, напишите нам, мы в течении 1-2 рабочих дней удалим его.