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 (розмір кластера) = 4294967296 байт, тобто 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
 
Лайте) т.к. сам хочу довести її до пуття. Формат контейнера стабільний, а програмку можна доробляти.
    
Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.