Systemicus чаcть 3: OMFS3 и Liberte

    В этой части хотел бы поделится опытом создания файловой системы OMFS3 для ОС Systemicus. Главная цель ее создания — надежное шифрование данных.

    image



    Предыдущие части:
    Первое публичное выступление RTOS Systemicus
    Systemicus чаcть 2: GUI


    Сразу хочу отметить, почему я решил написать свою ФС, а не прикрутить, к примеру, FAT, NTFS (форкнуть код NTFS Kolibri) или ext2/3. Я хотел, чтобы изначально она была проста в реализации, при этом расширяема и безопасна.

    Простота. Она заключается в отсутствии журналирования на базовом уровне. Всё устроено достаточно просто — есть большие кластеры (по 64 килобайта, т.к. malloc в OS Systemicus тоже выделяет по 64k), в одних кластерах содержится информация о файлах и вложенных каталогах, в других — собственно данные. Первый кластер зарезервирован под информацию о разделе + много места для будущих расширений (сейчас в нем используется только первые 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 GUI, т.к. компилировать раздел каждый раз вручную неудобно как-то… да и в самой ФС шифрования пока кроме ГОСТ+RC4 нету (и те временно отключены, на время разработки). Поэтому, надо писать.

    Выбрал Delphi (не злитесь, не люблю C/C++, или не умею ;-) ). За 2,5 дня управился, функции шифрования делал всё-таки на fasm как отдельную dll и просто прикрутил ее к моему приложению. Нужно отметить, что с Blowfish и IDEA пока происходят непонятные жуткие вещи, поэтому я их отключил в этой версии, лично мне хватает ГОСТ+RC6.
    Так вот, программку обозвал Liberte и по своей сути это получилась не только просмотрщик моей файловой системы, но и криптоконтейнер :-) Сам уже пользуюсь, делал ранее для себя такую штуку — Wolfram, но там было шифрование отдельных файлов и было не удобно. Теперь для моих важных данных использую Liberte.

    Не сетуйте на скорость шифрования — я сам в шоке, но всё впереди.
    Даю ссылку на скачивание — nebka.ru/files/Liberte_0.1c.7z
    Нет, вот еще одна, а то в прошлой статье ругались что сервер неправильно что-то отдает: http://yadi.sk/d/1up9km3cSBPvE

    Ругайте) т.к. сам хочу довести ее до ума. Формат контейнера стабильный, а программку можно доделывать.

    Similar posts

    AdBlock has stolen the banner, but banners are not teeth — they will be back

    More
    Ads

    Comments 18

      0
      Клон трукрипта?
        0
        можно было бы, но пока не знаю как сделать из контейнера подключаемый диск, как у трукрипта…
        0
        Правильно ли я понимаю, что для шифрования кластеров вы используете stream-шифры одним и тем же ключом для кодирования блоков одинакового размера? Без CBC?
          0
          нет, только RC4 это как вариант. Я знаю, что этто не пруф. Поэтому сам использую RC6 (он блочный).
          Но вообще-то, я делаю упор на ГОСТ, шифр Б нужен в основном для как раз, чтоб «зачистить следы» за ГОСТом, с таким же успехом можно было бы сначала сжать данные (например LZO) а потом их зашифровать ГОСТом, думаю стойкость была бы не ниже.

            0
            P.S. ГОСТ с гаммированием с обратной связью.
              0
              А вектор инициализации для кластеров разный? Т.е. если есть два кластера с одинаковым содержимым, в зашифрованном виде они будут одинаковые или есть зависимость от номера кластера?

              И не совсем понятен выбор алгоритмов. Зачем шифры с 64-битными блоками ГОСТ, IDEA, Blowfish? Почему не заюзать более современные 128-битные, AES, Camelia, Twofish, Serpent, CAST-256?
                0
                Спасибо за указание, забыл совсем сделать — надо при создании контейнера шифровать пустое место действительно с применением случайной последовательности для пустых кластеров. Исправлюсь)

                А именно с данными — то да, если два одинаковых — то и зашифрованные будут одинаковые. Но тут думаю это не критично, т.к. не зная пары открытый/заыкрытый текст это ничего не даст, а предположить открытый текст нельзя, т.к. список файлов и др тоже зашифровано…
                Хотя, можно будет подумать над этим… просто а смысл, если известен номер кластера, то это же уже открытый известный дополнительный ключ, всё-равно что сделать дополнительный XOR к ключу на известный параметр…

                Про алгоритмы: ГОСТ считаю до сих пор неуязвимым и очень расширяемым (атака проведенная недавно — это только в теории, на практике она не реализуема). Например, если задать на выбор еще и таблицу замен (т.е. атакующий не будет знать, какая таблица замен использовалась), то это уже не 256-битный ключ, а гараздо сильнее. Стоек с 89 года, а вот AES гараздо моложе, но на него уже придуманы гараздо эффективные атаки.
                У него очень много приемуществ, единственный недостаток — скорость. Из перечисленных Вами, хочу добавить как шифр Б только Twofish, т.к. Б.Шнаеру можно доверять)

                  +1
                  просто а смысл, если известен номер кластера, то это же уже открытый известный дополнительный ключ

                  Смысл точно такой, как и в том для чего вообще придумали вектор инициализации, чтобы одинаковые данные не давали одинаковые зашифрованные данные на выходе. И с файловой системой нельзя говорить, что неизвестен открытый текст, легко может быть файл с нулевыми байтами (ну например, недокачанный торрент файл).
                  Стоек с 89 года, а вот AES гараздо моложе, но на него уже придуманы гараздо эффективные атаки.

                  Ну стоек он примерно по тем же причинам, как в неуловимый джо. Просто международным стандартом его так и не приняли, а поэтому тратить время на его анализ значительно меньше желающих.

                  У AES, Twhofish и Camelia плюс в том, что они значительно быстрее того же ГОСТ и IDEA, не говоря о том, что для AES есть еще и специальные инструкции в современных процессорах.

                  И кстати как именно получается ключ из пароля пользователя, просто хэш или PBKDF2? Как проверяется, правильный ключи ввёл пользователь или нет? Насколько понял заголовок (первый кластер), и остальные кластеры шифруются одинаковыми ключами.
                    0
                    AES как инструкция — не доверяю) ЦРУ там закладок понаставило. По той же причине TrueCrypt пользуюсь только 5-й версией, т.к. по-моему с 6-й там для AES используются процессорные инструкции.

                    Про скорость — это да, согласен на все 100%. ГОСТ медленный, но я согласен на потерю скорости ради надежности. Скажем так, ГОСТ-у (при хорошей реализации, при использовании нескольких таблиц замен) я доверяю на 99.99%, остальным — меньше, AES — вообще никакого доверия. IDEA тоже замечателен, как сказал Брюс Шнаер — это один из самых надежных шифров, но опять же медленный.
                    Вобщем, поэтому и два уровня шифрования, второй — на выбор пользователя, сегодня добавил Camellia (на MMX), хочу еще Trivium и MARS

                    Ключи — 256-битный хеш по ГОСТ 34.11-2012 простым хешированием, не вижу преимуществ PBKDF-а. Если ГОСТ ненадежен разве что… но когда это будет доказано, тогда и сменю хеш…
                    Первые два кластера не шифруются, в них из криптоинформации ничего нету (это только для операционки нужно), кроме двух CRC32 сумм. Вот они и используются для проверки правильности пароля. Сразу оговорюсь, я знаю, что это не криптофункция. Проверка идет по принципу is CheckCRC == crc32(crc32(pass1) * crc32(pass2)). Т.к. у CRC32 множество коллизий (опять же, из-за того что не криптофункция), то по этим проверочным суммам невозможно восстановить исходный пароль, даже теоретически. Да, есть вероятность, что человек введет два таких пароля, что он пройдет проверку. Ну… в таком случе просто данные будут неправильно расшифрованы и он получит набор мусора. Это не критично.
                      +1
                      AES как инструкция — не доверяю

                      Ну это уже из разряда тараканов в голове :)

                      Если ГОСТ ненадежен разве что… но когда это будет доказано, тогда и сменю хеш…

                      Вы похоже не совсем понимаете, для чего нужен PBKDF2, там вполне может и ГОСТ использоваться в качестве хэш-функции. Задача замедлить перебор паролей, так как в данном случае пробить по словарям хэши значительно проще, чем пытаться найти уязвимости в шифрах или хэшах.
                      Потому в принципе в большинстве решений которые смотрел на эту тему. С помощью пароля введенного пользователем генерится ключ с помощью PBKDF2 (количество итераций, от нескольких тысяч до сотен тысяч), которым шифруются заголовок, в заголовке сохраняются ключи которые представляют случайный набор символов, кроме того проверку желательно делать с использованием HMAC, а то так и радужные таблицы можно использовать. Кроме того плюс отдельного зашифрованного заголовка — может быть несколько паролей пользователей (например возможность расшарить файлы для другого пользователя), или при смене пользовательского пароля не перекодировать весь контейнер.

                      P.S. Я просто тоже делаю криптоконтейнер, правда для целей бэкапа, так что как раз изучаю тему и популярные решения.
                        0
                        хм… так вот оно как TrueCrypt меняет пароли… учту, надо будет подумать об этом… спасибо. век живи — век учись, буду копать в этом направлении…
                      0
                      P.S. Спасибо за конструктивные вопросы, подумаю еще над этим всем...)
              0
              Плохо что произвольный доступ не реализован. Лучше организовывать кластеры как дерево страниц, а не как связный список.
                0
                а в чем преимущество? в двух словах? (я не в спор, просто интересуют преимущества, относительно возможных недостатков)… ведь так придется выделять больше памяти на хранение того же дерева, а т.к. система нацелена на малое ее потребление…
                  0
                  Если вам понадобится хранить, например, базы данных большого (больше сотни мегабайт) объема — ваша текущая схема просто не справится. Можно использовать оба способа, нужный разрешить выбирать пользователю (так было сделано в одной старой-старой ОС — Nova RDOS). Также, мой способ зачастую более эффективен для представления свободных кластеров, чем битовая карта — и даже не будет никакого оверхеда, т. к. кластеры с деревом можно будет использовать как свободные.
                    0
                    это надо будет поэксперементировать…
                    Наверное Вы правы, но всё-таки специфика моей ОС такова, что огромных данных там не будет или будет мало… а вот экономия кода и памяти очень важна…
                    на крайняк — будет возможность подключить стороннюю ФС, например ext3…
                0
                А что за кодировка в программе? Wine показывает только знаки вопроса.
                  0
                  а кто его знает, по идее 1251, Delphi 7 же в ней работает. Я как уберу все замечания, что сам придумал и которые здесь были, добавлю все алгоритмы и т.п. — сделаю на Lazarus сборку и под Linux (т.к. сам часто пользуюсь Debian)

                Only users with full accounts can post comments. Log in, please.