В этой части я хотел бы поделиться своим опытом создания файловой системы OMFS3 для ОС Systemicus. Основная цель его создания — надежное шифрование данных.
Предыдущие части: Первое публичное исполнение RTOS Systemicus Systemicus, часть 2: графический интерфейс
Сразу хочу отметить, почему я решил написать свою ФС, а не пристраивать, например, FAT, NTFS (форк кода NTFS Kolibri) или ext2/3. Изначально я хотел, чтобы его было легко реализовать, но при этом расширять и безопасно.
Простота.
Она заключается в отсутствии логирования на базовом уровне.
Все устроено довольно просто — есть большие кластеры (по 64 килобайта, поскольку malloc в OS Systemicus тоже выделяет 64к), одни кластеры содержат информацию о файлах и подкаталогах, другие содержат сами данные.
Первый кластер зарезервирован для информации о разделах + достаточно места для будущих расширений (в настоящее время он использует только первые 64 байта).
Второй кластер я выделил для кода ядра своей ОС.
Это было сделано из соображений безопасности самой системы.
Во-первых, это значительно сокращает код загрузчика (так как нет необходимости писать поиск файлов по всей системе), во-вторых, скрывает ядро от пользователя, а значит ни он, ни пользовательская программа не смогут повредить ядро.
код (т.к.
формально этот кластер не входит в видимое пространство файловой системы).
+ на универсальность это никак не влияет, 2-й кластер может быть и не занят, но он всегда один и есть там код или нет не важно.
Имеется еще один системный кластер (или кластеры, если размер диска большой).
Его адрес больше не фиксирован, а указывается в параметрах раздела.
Это байтовая карта раздела, где каждый байт указывает, свободен соответствующий кластер или нет. Почему не укусил? Так проще + по опыту знаю, что что-то может пригодиться в будущем, например указать и другие состояния кроме 0 и 1, например поврежденный, только для чтения и т.д. Один кластер с байтовой картой обеспечивает покрытие 65 536 (количество записей в карте на один кластер) * 65 536 (размер кластера) = 4 294 967 296 байт, т.е.
4 гигабайта дискового пространства.
На мой взгляд, это вполне приемлемо.
Как организовано хранение данных? Никаких специальных структур я не создавал, просто в конце каждого кластера указаны 2 dword: размер значимых данных в текущем кластере (в принципе, можно было бы обойтись и без этого значения, так как размер всего файла равен известный через его запись inode) и адрес следующего кластера с данными текущего файла.
Если адрес равен 0, то это последний кластер в цепочке данных.
Все просто и логично — при чтении файла мы обращаемся к диску последовательно, не переключаясь каждый раз на отдельную структуру расположения данных.
Наиболее вкусный Собственно, поэтому мы и написали свою ФС.
Итак, шифрование в ФС устроено на низком уровне, т.е.
шифруется каждый кластер индивидуально, а не файл.
Те.
на уровне драйвера файловой системы.
Шифрование происходит в 2 этапа с использованием двух разных ключей.
Для начала из пароля пользователя получаем через 256-битную версию ГОСТ 34.11-2012 256-битный ключ (точнее, пару, по одному на пароль).
Кластер шифруется первым ключом по алгоритму ГОСТ 28147-89 (я использую «тестовую» таблицу замены, ту, которую использует ЦБ РФ).
Кластер снова шифруется вторым ключом, но алгоритм задается пользователем при создании самой файловой системы (форматировании) — на выбор RC4, RC6, IDEA (медленное заражение) или Blowfish-256. ВАЖНЫЙ! Первые два кластера зашифрованы, почему (для чего они используются) читайте выше.
Далее отдельно можно зашифровать отдельный файл на высоком уровне, но всё же на уровне файловой системы.
Те.
Помимо этих двух шифровок, которые, напомню, применяются не к файлу, а к кластеру, можно зашифровать и сам файл.
Такая возможность записана, но я ее пока не реализовал (проблема во времени, а не в сложности).
О расширяемости Во-первых, основные параметры хранятся в 64-битных версиях, т.е.
проблем с размерами не будет (а учитывая, что адресация посекторная, а кластеры по 64 килобайта, адресовать можно очень много :-)), так как а также с отметками времени (тоже 64 бита).
Еще остается место для дополнительных файловых флагов (доступ, права,.
).
Также имеется много места (см.
1-й кластер) для других расширений.
В принципе, логирование можно реализовать в будущем, ничего противоречивого не вижу; лог может записываться в отдельный специальный файл или цепочку кластеров.
При шифровании тоже тип алгоритма хранится в байтовой переменной, т.е.
помимо этих 4-х можно добавить еще 252 других алгоритма шифрования и хеширования) булочка Давно хотел сделать свой аналог Графический интерфейс LeanFS , потому что каждый раз компилировать раздел вручную как-то неудобно.
да и в самой ФС нет другого шифрования, кроме ГОСТ+RC4 (а те временно отключаются при разработке).
Поэтому нужно писать.
Я выбрал Delphi (не сердитесь, я не люблю C/C++, или не умею ;-) ).
Справился за 2,5 дня, все равно сделал функции шифрования на фасме отдельной dll и просто прикрутил ее к своему приложению.
Следует отметить, что с Blowfish и IDEA до сих пор происходят странные и ужасные вещи, поэтому в этой версии я их отключил; лично мне достаточно ГОСТ+RC6. Итак, я назвал программу Liberte и по сути она оказалась не только просмотрщиком моей файловой системы, но и криптоконтейнером :-) Сам ею уже пользуюсь, раньше делал себе такую штуку - Вольфрам , но там было шифрование отдельных файлов и это было не удобно.
Теперь я использую Liberte для хранения важных данных.
Не жалуйтесь на скорость шифрования - я сам в шоке, но все впереди.
Даю ссылку на скачивание - nebka.ru/files/Liberte_0.1c.7z Нет, вот еще, а то в прошлой статье ругались, что сервер что-то неправильно отдает: http://yadi.sk/d/1up9km3cSBPvE Ругайте) потому что хочу сам довести до ума.
Формат контейнера стабилен, и программу можно доработать.
Теги: #omegicus #systemicus #ГОСТ 28147-89 #rc4 #RC6 #Криптография #файловые системы #Криптография #программирование
-
Простой Способ Провалить Тест
19 Oct, 24 -
Билл Гейтс Утверждает, Что Клавиатуры Мертвы
19 Oct, 24
