Разработка архитектуры КриптоФС
Планирую написать программу для шифрования файловой системы на уровне файлов, Windows аналог линуксовым CryptoFS и EncFS, и столкнулся с рядом проблем архитектурного плана. Нужно разработать архитектуру, позволяющую соблюсти баланс между требованиями безопасности, производительности и простоты реализации. Хотелось бы, чтобы результат обладал следующими свойствами:
1 – Высокая производительность. Без этого проект не стоит и затевать, ибо есть дико тормознутый windows порт EncFS.
2 – Шифрование имён, атрибутов и содержимого файлов.
3 – Прозрачная защита от модификации зашифрованных файлов.
4 – Защита от ватермаркинг атак (возможно ли?).
5 – Возможность прозрачной многопользовательской работы (возможно ли?).
Модель безопасности будем строить исходя из предположения, что файлы нашей КриптоФС лежат на удаленном сервере злоумышленника, и он может их читать, модифицировать, наблюдать за нашими запросами ввода/вывода, и.т.д, нам нужно чтобы атакующий мог получить как можно меньше информации о содержимом КриптоФС, и не мог спровоцировать компрометацию зашифрованных данных.
Итак, проблема №1 – выбор режима шифрования. Все потоковые режимы сразу отпадают, т.к. любой участок любого файла может быть многократно перезаписан произвольными данными. Требуется обеспечить неповторяемость шифртекстов блоков хранящих одинаковый плейнтекст, неповторяемость шифртекстов одинаковых файлов и неповторяемость шифртекстов для одинаковых имён файлов лежащих по разным путям. Для этого разделим наш файл на блоки фиксированного размера, и будем работать с ним поблочно, каждый раз перешифровывая весь блок. Если забыть об аутентификации, то оптимален режим CBC, с IV формируемым из номера блока и IV файла. Проблемы начинаются когда мы хотим ввести аутентификацию. HMAC прост и хорош, но сразу отпадает по требованиям производительности, т.к. требует вычисления хэша данных, что сразу увеличивает затраты на шифрование в 2 раза. Режимы шифрования с аутентификацией CCM, CWC, EAX и GCM отпадают, т.к. используют в своей основе потоковый CTR, режим OCB на первый взгляд подходит. Жду вашего мнения по этому вопросу.
Ещё можно поглядеть на наработки eCryptfs[link1].
Насчёт 3,4,5: костяк идеи, полагаю, тот же, что и при разработке стандартных криптоФС. Нужно лишь обобщить те идеи на случай пофайлового шифрования. Например, как с вотермаркингом борятся в стандартных шифрованных файловых системах? Почему тот способ нельзя поиспользовать и здесь?
А к Gmail можно будет приспособить? ;)
Это вы отсюда[link2] выбирали?
НИСТ ещё грозиться добавить XTS-AES к этому списку.
Эти режимы ещё не утверждены официально и находятся в стадии разработки/рассмотрения.
Если это будет выглядеть как набор зашифрованных архивов (например, 7-zip), будет труднее догадаться, что это КриптоФС и у "злоумышленника" будет меньше оснований удалять такие файлы.
... то это будет "Security through obscurity".
Нужно исходить из того, что злоумышленник обо всём догадался и пытаться наивным образом "не привлекать его внимание" уже поздно.
Защита нужна не от удаления файлов на недоверяемой стороне (а она и невозможна), а от анализа трафика — попытки сопоставить содержимое зашифрованных файлов с какими-либо известными обычными и сделать вывод с некоторой вероятностью больше случайной в пользу той или иной гипотезы.
Спишитесь с их авторами — как они планировали прикручивать аутентификацию и с какими трудностями они этом столкнулись.
Ну хорошо, а если это и будет именно набор зашифрованных файлов :)
Как это невозможна? Хозяйн-барин, особенно если аккаунт бесплатный. Впрочем, достаточно просто блокировать аккаунт – для пользователя это равнозначно удалению.
Кому это нужно? Не лучше ли просто уменьшить "раскрываемость"?
Извиняюсь, померещилось "удаление невозможно" :)
Посмотрел, всё убого, уныло и не совсем безопасно. EncFS и то лучше.
КриптоФС работает поверх другой ФС, неважно каким образом она организована. Если Gmail можно смонтировать как ФС, то да.
Аутентификация в XTS-AES? Вы ничего не путаете?
Бессмысленная затея.
eCryptfs – никак, EncFS – используется некриптографическая контрольная сумма, CryptoFS пока не смотрел.
CryptoFS была под FUSE, поэтому её разработка — не мэйнстрим, в отличие от того, что включают в ядро.
Верное замечание, не аутентификация, а защита от watermarking, относительно лёгкой подмены без знания ключа и др. "malleability" — в режимах дискового/контейнерного шифрования вместо строгой аутентификации, расходующей место и ресурсы, используется этот термин и режимы с соответствующими свойствами — CBC-ESSIV, LRW, XTS.
А вот режимы FS пофайлового шифрования не проработаны ни на уровне стандартов, ни даже теоретически. Теоретики видимо ждут, когда напишут криптонесекьюрные программы в этом формате, они получат широкое распространение, исследователи сначала напишут работы о том, какие в них кучи криптоуязвимостей, затем придумают под это дело специальные крипторежимы (из которых половину успешно и радостно сами же и поломают) и только затем НИСТ озадачится криптостандартами.
... И пройдёт к тому времени лет 10-15 (если полагаться на опыт стандартов посекторного шифрования).
А какие приемущества будут у данной системы перед хранением криптоконтейнеров truecrypt или dmcrypt на NFS сервере?
Ах да! Возможность прозрачной многопользовательской работы... Было бы весьма неплохо!
И всётаки насколько это безопастно монтировать такие контейнеры?
Такие вопросы неоднократно обсуждались. Например обсуждалось здесь[link3] и даже вынесено в FAQ[link4].