Разработка архитектуры КриптоФС

Планирую написать программу для шифрования файловой системы на уровне файлов, Windows аналог линуксовым CryptoFS и EncFS, и столкнулся с рядом проблем архитектурного плана. Нужно разработать архитектуру, позволяющую соблюсти баланс между требованиями безопасности, производительности и простоты реализации. Хотелось бы, чтобы результат обладал следующими свойствами:

1 – Высокая производительность. Без этого проект не стоит и затевать, ибо есть дико тормознутый windows порт EncFS.
2 – Шифрование имён, атрибутов и содержимого файлов.
3 – Прозрачная защита от модификации зашифрованных файлов.
4 – Защита от ватермаркинг атак (возможно ли?).
5 – Возможность прозрачной многопользовательской работы (возможно ли?).

Модель безопасности будем строить исходя из предположения, что файлы нашей КриптоФС лежат на удаленном сервере злоумышленника, и он может их читать, модифицировать, наблюдать за нашими запросами ввода/вывода, и.т.д, нам нужно чтобы атакующий мог получить как можно меньше информации о содержимом КриптоФС, и не мог спровоцировать компрометацию зашифрованных данных.

Итак, проблема №1 – выбор режима шифрования. Все потоковые режимы сразу отпадают, т.к. любой участок любого файла может быть многократно перезаписан произвольными данными. Требуется обеспечить неповторяемость шифртекстов блоков хранящих одинаковый плейнтекст, неповторяемость шифртекстов одинаковых файлов и неповторяемость шифртекстов для одинаковых имён файлов лежащих по разным путям. Для этого разделим наш файл на блоки фиксированного размера, и будем работать с ним поблочно, каждый раз перешифровывая весь блок. Если забыть об аутентификации, то оптимален режим CBC, с IV формируемым из номера блока и IV файла. Проблемы начинаются когда мы хотим ввести аутентификацию. HMAC прост и хорош, но сразу отпадает по требованиям производительности, т.к. требует вычисления хэша данных, что сразу увеличивает затраты на шифрование в 2 раза. Режимы шифрования с аутентификацией CCM, CWC, EAX и GCM отпадают, т.к. используют в своей основе потоковый CTR, режим OCB на первый взгляд подходит. Жду вашего мнения по этому вопросу.

Комментарии

—	*Гость* (27/09/2009 16:15) <#>

Ещё можно поглядеть на наработки eCryptfs.

—	*Гость* (27/09/2009 16:46) <#>

Насчёт 3,4,5: костяк идеи, полагаю, тот же, что и при разработке стандартных криптоФС. Нужно лишь обобщить те идеи на случай пофайлового шифрования. Например, как с вотермаркингом борятся в стандартных шифрованных файловых системах? Почему тот способ нельзя поиспользовать и здесь?

—	*Гость* (28/09/2009 00:03) <#>

А к Gmail можно будет приспособить? ;)

—	unknown (28/09/2009 10:14, исправлен 28/09/2009 10:16) профиль/связь <#> комментариев: 9796 документов: 488 редакций: 5664

Это вы отсюда выбирали?

НИСТ ещё грозиться добавить XTS-AES к этому списку.

Эти режимы ещё не утверждены официально и находятся в стадии разработки/рассмотрения.

—	*Гость* (28/09/2009 13:56) <#>

нужно чтобы атакующий мог получить как можно меньше информации о содержимом КриптоФС

Если это будет выглядеть как набор зашифрованных архивов (например, 7-zip), будет труднее догадаться, что это КриптоФС и у "злоумышленника" будет меньше оснований удалять такие файлы.

—	unknown (28/09/2009 14:56, исправлен 28/09/2009 14:57) профиль/связь <#> комментариев: 9796 документов: 488 редакций: 5664

> Если это будет выглядеть как набор зашифрованных архивов

... то это будет "Security through obscurity".

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

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

>аналог линуксовым CryptoFS и EncFS

Спишитесь с их авторами — как они планировали прикручивать аутентификацию и с какими трудностями они этом столкнулись.

—	*Гость* (28/09/2009 21:36) <#>

это будет "Security through obscurity"

Ну хорошо, а если это и будет именно набор зашифрованных файлов :)

Защита нужна не от удаления файлов на недоверяемой стороне (а она и невозможна)

Как это невозможна? Хозяйн-барин, особенно если аккаунт бесплатный. Впрочем, достаточно просто блокировать аккаунт – для пользователя это равнозначно удалению.

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

Кому это нужно? Не лучше ли просто уменьшить "раскрываемость"?

—	*Гость* (29/09/2009 02:29) <#>

Защита нужна не от удаления файлов на недоверяемой стороне (а она и невозможна)

Как это невозможна? Хозяйн-барин, особенно если аккаунт бесплатный. Впрочем, достаточно просто блокировать аккаунт – для пользователя это равнозначно удалению.

Извиняюсь, померещилось "удаление невозможно" :)

—	ntldr (30/09/2009 10:01, исправлен 30/09/2009 10:02) профиль/связь <#> комментариев: 371 документов: 19 редакций: 20

Ещё можно поглядеть на наработки eCryptfs

Посмотрел, всё убого, уныло и не совсем безопасно. EncFS и то лучше.

А к Gmail можно будет приспособить? ;)

КриптоФС работает поверх другой ФС, неважно каким образом она организована. Если Gmail можно смонтировать как ФС, то да.

НИСТ ещё грозиться добавить XTS-AES к этому списку.

Аутентификация в XTS-AES? Вы ничего не путаете?

Если это будет выглядеть как набор зашифрованных архивов (например, 7-zip)

Бессмысленная затея.

Спишитесь с их авторами — как они планировали прикручивать аутентификацию и с какими трудностями они этом столкнулись

eCryptfs – никак, EncFS – используется некриптографическая контрольная сумма, CryptoFS пока не смотрел.

—	unknown (30/09/2009 13:05, исправлен 30/09/2009 13:11) профиль/связь <#> комментариев: 9796 документов: 488 редакций: 5664

CryptoFS была под FUSE, поэтому её разработка — не мэйнстрим, в отличие от того, что включают в ядро.

>Аутентификация в XTS-AES? Вы ничего не путаете?

Верное замечание, не аутентификация, а защита от watermarking, относительно лёгкой подмены без знания ключа и др. "malleability" — в режимах дискового/контейнерного шифрования вместо строгой аутентификации, расходующей место и ресурсы, используется этот термин и режимы с соответствующими свойствами — CBC-ESSIV, LRW, XTS.

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

—	SATtva (30/09/2009 13:10) профиль/связь <#> комментариев: 11558 документов: 1036 редакций: 4118

... И пройдёт к тому времени лет 10-15 (если полагаться на опыт стандартов посекторного шифрования).

—	*Гость* (30/09/2009 15:57) <#>

А какие приемущества будут у данной системы перед хранением криптоконтейнеров truecrypt или dmcrypt на NFS сервере?

—	*Гость* (30/09/2009 15:59) <#>

Ах да! Возможность прозрачной многопользовательской работы... Было бы весьма неплохо!
И всётаки насколько это безопастно монтировать такие контейнеры?

—	unknown (30/09/2009 17:10, исправлен 30/09/2009 17:14) профиль/связь <#> комментариев: 9796 документов: 488 редакций: 5664

Такие вопросы неоднократно обсуждались. Например обсуждалось здесь и даже вынесено в FAQ.

Ваша оценка документа [показать результаты]