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

Для чтения файла пользователь запрашивает в системе файл с заданным 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 Зашифрованные блоки файла записываются в систему, после чего записывается нулевой блок.

Утверждение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 пользователь проверяет ЭЦП на (нулевом блоке) корневой директории. Поскольку корневая директория открыта на чтение для всех, пользователь считывает 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 пользователю, добавив соответствующую запись в список У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 инфраструктурой открытых ключей (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 ( 5. KazAA ( 6. 7. 8. 9. Обернихин В.А., Тормасов А.Г. Схема контроля доступа для распределенной одноранговой файловой системы (TorFS) // Безопасность информационных технологий.

Вып. 4. 2004.(находится в редакции) Pages:     | 1 | 2 |    Книги по разным темам