Стеганографическая файловая система. , StegFS. Идея обалденная!

ПРЕДУПРЕЖДЕНИЕ.
1. Все нижеприведенные заклинания имеют высокую степень сложности. Если Вы не уверены в том, что Вам
это понадобится, НЕ ДЕЛАЙТЕ этого! Если Вы уверены в том, что Вам это понадобится, то сохраните
все важные данные с тем, чтобы при полной переустановке системы, Вы могли бы восстановить и данные.
2. Сложность заклинаний обусловлена тем, что Вам придется по месту дорабатывать ядро напильником.
3. Все, что производилось, делалось на ext2fs, как и описано в соответствующем документе. См.
ниже.


Все-таки правильнее -- StegFS, но я для краткости пишу здесь и далее SFS. Не путайте!
Это разные вещи!!!

На данный момент SFS -- "академический релиз", #1.1.4, вышедший в 1999г. С тех пор нет новых релизов и
неизвестно ведется ли работа над новыми. Я "развлекался" со всем этим, т.к. в силу моих извращенных
интересов, мне интересно все, что так или иначе связано с защитой/криптографией/сетями/UNIX-миром. И
я то же изучаю системы. Не более. Так что, хоть и защищать-то нечего, но вот уж больно
идея-то красивая!

Вообще говоря, это файловая система, устанавливаемая в Linux, в задачи которой входит "невидимая"
шифрация и размещение данных на диске. Т.е. любой зашифрованный файл (или файловая система в целом) имеют
только один и весьма существенный недочет -- слабость парольной защиты. Самый криптостойкий
алгоритм, невзламываемый методами линейного или диффиренциального криптоанализа имеет одно слабое
звено -- людей, которые его используют.

Т.е., скажем, если Ваш диск попал в руки некоторой структуре (и совсем не силовой -- у них все еще
проще), которую очень сильно интересует что же там записано. Вы всерьез думаете что кто-то будет
стараться прочесть Ваши данные, применяя супералгоритмы, реализованные на суперкомьютере типа Cray
или Fujitsu?

Могу Вас утешить. Есть более дешевые способы. К примеру, всего лишь стоваттный паяльник, стоящий
неизмеримо меньше суперкомпьютера способен вытворять такие чудеса с Вашим языком, о которых Вы и
не подозреваете. А всего-то... Вставить куда надо и включить. И никаких расходов на суперкомпьютеры...

В случае применения SFS все немного сложнее -- скрывается сам факт обладания информацией.
В руки "врагов" попадает диск, имеющий стндартную линуксовую ФС. Ничего секретного там нет -- все как
всегда. Дело в том, что SFS ставится поверх существующей ФС, (опробовалось на ext2fs с
размером inode в 1024 байта) и размещает данные не в пределах основных разделов существующих ФС,
а в пределах незаполненных блоков "поверх" раздела native, используя заведомо свободные сектора жесткого
диска. Кстати сказать, данные, в дополнение ко всему, еще и шифруются с применением 128-битного ключа.
Для полного счастья, так сказать. Нетрудно посчитать, что для "лобового" вскрытия пароля в этом случае
Вам понадобится перебрать все пространство ключей и проверить этот очередной "сим-сим". Всего-навсего
2^128... Нееееет... уж лучше паяльничком... :D

Кстати. Применяемый алгоритм -- CBC (Chipher Block Chaining). Для каждого блока данных вычисляется свой
хэш, причем, для инициализации алгоритма (для каждого блока данных) применяется своя кодовая последовательность
(см. ниже про безопасность). Эта последовательность (вектор инициализации) для каждого блока своя, длиной
16 бит (иначе все будет совсем долго). Хранится как элемент ФС в соотв. структуре SFS.

Таким образом, даже если диск попадает "в кроватку" для посекторного чтения данных (что маловероятно,
но пусть так будет) то на диске будут явственно видны данные, своп, и какой-то цифровой shit в свободном
пространстве диска. Как если бы туда что-то писалось, там что-то удалялось и не единажды.

При всем при том. Вы можете работать в нормальном режиме как с той, так и с другой ФС. Т.е. Вы можете
не обращаться к скрытому разделу, работая со стандартной ФС. Ок. В этом случае, если системе, скажем,
будет необходимо создать новый файл(-ы), она может просто затереть скрытые файлы. Ну и здорово. Для
этих целей в SFS есть некторая избыточность, вводимая самим пользователем. Т.е. скрываемый файл хранится
не в одном, а в двух или более экземплярах. Кстати сказать, если Вы заполнили на 100% диск в ext2fs, то
тем самым Вы "грохнули" все данные в StegFS, т.к. ext2fs ничего не знает и знать не хочет ни о чем.

На самом деле, это сильно упрощенная модель, т.к. хранится и важен для системы не столько "файл"
сам по себе, сколько информация об inodes этого файла. Т.е. здесь необходимо знать именно
структуру ФС. Почитайте что-нибудь об inodes, структурах, таблицах блоков, суперблоках, применяемых
в ФС и Вы меня поймете.

Открыв доступ к SFS, Вы в программах сможете применять стандартные методы чтения/записи данных, т.к.
в SFS будет Вам представлена как почти стандартная FS.

Все дело в том, что SFS базируется на концепции VFS (виртуальных ФС), в рамках которой может быть
реализована любая, самая фантастическая ФС, причем, в результате такй реализации получится ФС,
доступ к которой для приложения будет абсолютно стандартен и прозрачен. "Разделяй и властвуй" в чистом
виде. И, кстати сказать, никто не мешает Вам разработать свою ФС. Весьма возможно, что она будет
просто супер.

Чуть не забыл. В случае реализации через VFS, есть еще и открытый буффер для возвращаемых данных,
в котором данные (в случае применения SFS) хранятся так же в зашифрованном виде.

Ладно, оставим детали реализации и поговорим о безопасности SFS. Она предусматривает до 15 контекстов
или уровней безопасности (внимание! пользовательские контексты считаются не от "0", а от "1", а то
будете искать нулевой контекст и, не дай Бог найдете, т.к. нулевой контекст чистит всю скрытую партицию от
файлов). Т.е. Вы можете задавать до 15 паролей, открывая пользователям или группам пользователей на основе
их паролей, уровни доступа. Необходимо учесть, что здесь действует правило вложенности уровней. Т.е. пароль
уровня 1 дает доступ ко всем 15-ти уровням. Пароль к уровню 13 -- к уровням 13,14,15. Аккуратнее с
нулевым контекстом, повтораяю!!!

Где все это добро взять -- ftp://ftp.kerneli.org/pub/kerneli/net-source/StegFS/
http://ban.joh.cam.ac.uk/~adm36/StegFS/
http://www.cl.cam.ac.uk/~mgk25/stegfs/

Если будете качать -- не забудьте прихватить документацию! Уверяю Вас -- это не те
"заклинания", при которых Вы можете пренебречь грамотным "описаловом". Дока -- в .pdf, читается легко.
Там же разложены по полочкам основы, идеи реализации, примеры использования. Приведены данные
тестов, говорящие о том, что не так уж задержки и велики. Приведены статистические показатели. И,
на закуску, приведен список библиографических ссылок, который ценен сам по себе. Авторы проделали
огромную работу, поверьте.

Теперь о скорбном. Уффф.... Дело в том, что сама по себе идея, конечно же красива, но драйвер этой ФС
безпроблемно (почти) интегрируется только в ядро 2.2.19, для которой все это и писалось. Дело
в том, что Вам нужно будет наложить патч на ядро (он есть в соотв. каталоге сырцов). По этой причине,
если Вы уже скомпилили ядро и не оставили свои конф. файлы и исходные файлы в архиве, то... Если патч
пойдет криво, Вам не останется ничего иного, как переставлять сырцы ядра... Как минимум.

Так что до наложения патча сделайте архив сырцов ядра и поправьте perl'овые скрипты в
каталогах ./mkpatch и ./kernel. Кроме того, на этом же этапе просмотрите те файлы, которые
будут... Нет, в конце-то концов! Что мне здесь пошаговый guide что-ли расписывать?!?

Там есть:
- README, FAQ.txt -- читайте, думайте.
- У Вас, в Вашем комплекте для жизни есть голова. Напрягайте. В конце-то концов, если сырцы, руки и голова
на месте и хотите это поставить -- флаг Вам в руки. Сделайте это. Это возможно.
- Ковыряться в Вашем ядре я не желаю -- у меня свое есть.

И еще. Не все так гладко -- существуют "демаскирующие" признаки -- для работы с FS требуется ряд утилит --
они, хоть и могут быть переименованы, но если анализирующий знает что он хочет найти -- найдет. ФС должна быть
"известна" системе, файл btab (сам по себе), который хранит список блоков -- то же не укроется от
внимательного человека. Но это и понятно -- это же академический релиз!

Успехов! И... не забудьте что я там про паяльничек говорил... Не искушайте господа Бога своего...
Это совет. Просто совет.

Такой же метод (стенография) используется для защиты прав на изображения, текст с правами на копирования "подмешивается" в изображение по определённому алгоритму
извсетному только автору картинки, и далее в случае необходимости он "проявляется".