Luks шифрование. Шифрование разделов

Каждый из нас хранит на жестком диске изрядное количество конфиденциальной информации. Для кого-то это всего лишь пароли от различных сетевых сервисов, другие ответственны за хранение важной документации, третьи уже не первый год занимаются разработкой инновационной программы. В любом случае, данные необходимо беречь от посторонних, что в нашем мобильном мире сделать довольно проблематично без использования систем шифрования.

Взглянув на список шифрующего ПО для Linux и проанализировав степень популярности и актуальности каждого из них, мы придем к выводу, что есть только четыре безопасные и поддерживаемые криптосистемы для шифрования жестких дисков и других носителей информации на лету:

WARNING

В целях безопасности индексацию зашифрованных разделов лучше отключить, отредактировав конфигурационный файл /etc/updatedb.conf. Файлы, зашифрованные EncFS, не могут иметь жестких ссылок, так как система шифрования привязывает данные не к inode, а к имени файла.

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

UPD: Поскольку этот пост был готов ещё месяц назад, тогда я даже не мог представить настолько странную и неожиданную смерть проекта . Ну да, возможно, он ещё не совсем помер , посмотрим… Тем не менее, в этом тексте я решил оставить все ссылки на TrueCrypt как есть.

Что такое «правдоподобное отрицание»?

Вы можете найти весьма длинное и подробное описание этого понятия в Википедии: http://en.wikipedia.org/wiki/Plausible_deniability . Если коротко, это значит, что вы можете обладать чем-то (или могли сделать что-то), наличие чего не может быть никем заподозрено или доказано (если в этом не признаться самостоятельно, конечно). И впоследствии вы можете отрицать наличие (или факт совершения) этого чего-то, если кто-то захочет вас обвинить, поскольку (повторюсь) этот факт недоказуем. Ну например, если ребёнок пнул под зад своего маленького брата, и брат пошёл искать справедливости у родителей, что в этом случае произойдёт?

Ну… Как бы ничего не произойдёт. Потому что этот чувак будет отнекиваться, а родители, формально говоря, не смогут его поймать за руку (поскольку, во-первых, тупо нет свидетелей, а во-вторых, младший братец может вести свою грязную игру). Таким образом, никого не накажут. Ну или накажут обоих на всякий пожарный. Это как раз был пример использования возможности правдоподобного отрицания ребёнком, склонным к агрессии. Но мы-то с вами, безусловно, белые и пушистые, и будем использовать скрытые контейнеры исключительно в целях защиты своих персональных данных от плохих парней. Так ведь? Безусловно, «что такое „хорошо”, и что такое „плохо”» - это отдельный вопрос… Однако, ближе к делу.

Общая идея реализации

Предположим, мы хотим сохранить некие важные данные внутри зашифрованного файла. В общем случае мы будем использовать какую-то программу криптозащиты, которая будет делать за нас всю грязную работу. Возможно, мы захотим работать с зашифрованным файлом как с виртуальным диском, и это значительно сужает число потенциальных кандидатов. Однако, есть одно «но». Практически все подобные программы работают с файлом как с одним куском зашифрованных данных. Поясню: у пользователя обычно есть один пароль (и, быть может, несколько «запасных») для всех данных внутри контейнера. Это означает наличие как минимум одного слабого звена: пароля на контейнер. Я не хочу упоминать о том, что пароль должен быть криптографически надёжным, поскольку это прописная истина. Я имею в виду, что если пользователь по какой-то причине сдаст этот пароль (например, под давлением), все данные будут прочитаны. И этот факт мне кажется печальным и совершенно неправильным…

Хотя вообще-то надежда есть. :) Например, существует такая программа, как , которая является достаточно умной. Пользователь может создать в одном файле два контейнера: один «подставной» с некоторым количеством «запрещённых», но относительно безопасных файлов, а другой - настоящий, с данными, которые не должны засветиться ни в коем случае. Таким образом, TrueCrypt запрашивает два разных пароля, когда пользователь хочет создать подобный «двойной» контейнер. При работе пользователь вводит только один пароль для «настоящей» части и работает с ней. В том случае, если под давлением внешних обстоятельств пользователь вынужден раскрыть содержимое контейнера третьим лицам, он просто вводит другой пароль, и TrueCrypt открывает «фальшивку». Я подчёркиваю (и это действительно важно), что не существует возможности доказать наличие скрытой части, если исследователь не знает соответствующего пароля.

А теперь давайте быстренько разберёмся, как работает это барахло… На самом деле всё очень просто. Софт делит файл-контейнер на две (вообще говоря, неравные) части. Первая часть, которая может быть относительно небольшой, содержит специально подготовленные данные; вторая - настоящие. Соответственно, программа должна уметь работать с двумя различными заголовками (конфигурациями) для двух разных частей, а также уметь выбирать, какую часть расшифровывать в зависимости от введённого пользователем пароля. А это, надо сказать, не самая тривиальная часть работы. Ну просто потому, что «официально» должна быть видна только одна, «фальшивая», конфигурация: если у контейнера есть стандартный заголовок, это должен быть только «фальшивый» заголовок; если параметры контейнера хранятся в отдельном конфиге, этот конфиг должен позволять расшифровать только «фальшивую» часть. И после расшифровки «фальшивой» части не должно появиться ни одного намёка на наличие реальной. Они должны быть абсолютно независимыми. Более того, когда открыта «фальшивая» часть, софт должен показывать полную ёмкость крипто-контейнера, даже в том случае, когда объём этой части намного меньше.

Так что там про LUKS-то?

Ну тут у нас есть хорошие новости и… эм… ещё боле хорошие новости.

Хорошие новости заключаются в том, что cryptsetup умеет расшифровывать и монтировать тома, созданные TrueCrypt"ом. Только для чтения, впрочем, но это ерунда. Поскольку есть новости и получше. А именно, мы можем создавать «скрытые» контейнеры исключительно средствами cryptsetup "а. Более того, эта утилита позволяет создать любое количество «скрытых» частей. Естественно, в разумных пределах. И вот каким образом это можно сделать.

Но перед тем, как продолжить,

ОГРОМНОЕ ЖИРНОЕ СТРАШНОЕ ПРЕДУПРЕЖДЕНИЕ!!!

• Всё, что описано ниже, может стать причиной необратимой потери данных.
• В вашей стране может быть запрещено использование сильной криптографии, так что вас могут посадить не за реальную информацию, а просто за наличие крипто-контейнера, который найдут на вашем винте.
• Криптография может защитить ваши данные, однако она не защитит вас от пыток. Скрытый контейнер может помочь сохранить ценную информацию, но вы не сможете отрицать его наличие в случае предательства или доноса.
• Ребята, которых заинтересовали ваши зашифрованные данные, могут оказаться не настолько тупыми, как вы ожидали. Даже если они не смогут доказать наличие скрытой части контейнера, они вполне могут запереть вас в одной камере с матёрыми уголовниками, и через пару суток вы вспомните все пароли ко всем скрытым данным.
• Если у вас есть близкие люди (девушка/парень, родственники, друзья), они точно так же могут стать мишенью для жёсткого прессинга. И это наверняка поможет значительно быстрее вспомнить вообще всё, включая то, чего вы даже и не знали.

Так что лучше дважды подумайте, насколько информация ценнее вашей жизни и жизни ваших близких. И сделайте бэкап. Просто на всякий случай.

Так вот, man cryptsetup способен рассказать нам множество интересных подробностей о параметрах командной строки этой утилиты. Ну например, давайте глянем на опцию --header :

Ну и ладненько. Это значит, что теперь у нас может иметься в наличии том данных, забитый случайным мусором, причём совершенно без всяких осмысленных сигнатур. Описание этой опции содержит несколько больше информации, предостережений и предупреждений, однако в сухом остатке это всё, что требуется. И тем не менее, я настоятельно рекомендую прочитать это отличное руководство.

Ещё одна весьма полезная опция - это --align-payload , которая позволяет расположить настоящие данные по определённому смещению относительно начала тома:

И это тоже классно, потому что теперь мы свободно можем сдвигать наши данные в любую часть тома. Идею улавливаете, да?

1. Инициализируем том для шифрования: полностью перезаписываем его случайными данными.
2. Делаем «официальный» зашифрованный том и скидываем на него немножко заражённого вареза, спираченного музла, прона полезных свободных программ, записей вашей любительской рок-группы, фильмов про любовь и т.п., в общем, того, за что вам дадут не больше двух лет условно.
3. Используя указанные выше эзотерические опции cryptsetup "а, создаём скрытый том (внутри «официального») и выносим его заголовок на внешний носитель. Здесь вы можете хранить по-настоящему опасную информацию (типа ваших детсадовских фоток или планов по завоеванию мира).

Собственно, народ, это всё. Никакой магии. Естественно, нельзя забивать «официальный» шифрованный диск под завязку по той простой причине, что часть его пространства отдана под скрытый контейнер. И, как я уже сказал в начале, вы можете, если хотите, создать несколько скрытых дисков, следуя той же логике.

Вот… А если вам всё же нужны подробности, то специально для вас -

Пошаговое руководство

Внимание!

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

Короче, не делайте этого, если не можете придумать осмысленного объяснения тому, как каждый шаг соотносится с вашими целями. И сделайте бэкап. Сейчас же.

Итак, предположим, у нас есть некое устройство с несколькими разделами. Пусть это будет, например, /dev/sdb. И пусть /dev/sdb1 будет относительно небольшим (8ГБ) разделом, предназначенным для шифрования. Мы разделим его 5 к 3, где 5-гиговая часть будет «официальной», а 3-гиговая - скрытой. Положим также, что ключ для зашифрованного диска мы будем держать в /etc/keys, а заголовок скрытого контейнера, соответственно, на внешнем USB-накопителе, который смонтируем в /media/user/ExtUSBStick. Я полагаю, вы уже в курсе, какие разрешения нужно выставить на хранилище ключей, как настроить encfs/ecryptfs для безопасного хранения конфиденциальных данных на небезопасных устройствах, а также о том, что реальные секретные ключи имеет смысл скопировать и хранить в нескольких территориально разделённых сейфах.

Вот и ладушки, завязываю бурчать и перехожу к сути вопроса.

Инициализация устройства /dev/sdb1:

Dd if=/dev/urandom of=/dev/sdb1 bs=16M

Делаем ключ для шифрованного тома. 512 битов (64 байтов) для наших целей выше крыши:

Dd if=/dev/urandom bs=64 count=1 >/etc/keys/secret.key 2>/dev/null

Шифруем том, используя только что созданный ключик:

Cryptsetup luksFormat /dev/sdb1 /etc/keys/secret.key

Открываем шифрованное устройство и настраиваем маппинг в secretdata:

Cryptsetup luksOpen --key-file /etc/keys/secret.key \ /dev/sdb1 secretdata

Создаём на зашифрованном томе файловую систему (напр., btrfs):

Mkfs.btrfs -L SecretData /dev/mapper/secretdata

… и монтирум её:

Mount /dev/mapper/secretdata /var/secretdata/

Памятуя о 5-гиговом ограничении, устанавливае квоту для подтомов:

Btrfs quota enable /var/secretdata/

Поскольку квоты btrfs действуют только для подтомов, давайте создадим одну такую штуку:

Brfs subvolume create /var/secretdata/workingvolume

… и применим к нему указанную квоту (обратите внимание, что подтома btrfs могут быть смонтированы как обычные файловые системы, так что, возможно, впоследствии вам будет удобнеее монтировать именно этот подтом вместо всей фс):

Btrfs qgroup limit 5G /var/secretdata/workingvolume

Заполняем его какими-то данными:

Debootstrap --variant=buildd testing /var/secretdata/workingvolume

Ну и всё, теперь об этой части можно забыть:

Umount /var/secretdata cryptsetup luksClose secretdata

Сейчас создадим «рыбу» для заголовка и напихаем в неё случайного мусора:

Dd if=/dev/urandom of=/media/user/ExtUSBStick/hidden.head bs=4M count=1

А вот теперь наступает тот самый момент, когда начинается настоящая магия. (Что? Я сказал, что никакой магии нет? Значит я наврал.) Мы используем тот же самый секретный ключ, однако, не целиком, а только половину (со смещения в 32 байта). Тем не менее, оставшиеся 256 случайных бит вполне способны стать хорошим ключом. Затем мы отделим заголовок и положим его на флэшку. И наконец, мы скажем cryptsetup "у, что хотим сместить наш скрытый контейнер на 5ГБ (т.е. на 10485760 512-байтных блоков) относительно начала тома:

Cryptsetup --keyfile-offset 32 --header /media/user/ExtUSBStick/hidden.head \ --align-payload 10485760 luksFormat /dev/sdb1 /etc/keys/secret.key

Да-да, всё настолько просто. Теперь откроем новое зашифрованное устройство:

Cryptsetup luksOpen --key-file /etc/keys/secret.key --keyfile-offset 32 \ --header /media/user/ExtUSBStick/hidden.head /dev/sdb1 realsecretdata

Накатим любую фс, какую захотим:

Mkfs.btrfs /dev/mapper/realsecretdata

Полезные ссылки

Для тех, кто хочет знать несколько больше, вот некоторое количество дополнительных источников информации:

• Disk encryption , общая информация по шифрованию дисков: https://wiki.archlinux.org/index.php/Disk_encryption
• Отрицаемое шифрование , концепция несколько более узкая, нежели «правдоподобное отрицание», относящаяся только к области криптографии: https://ru.wikipedia.org/wiki/Отрицаемое_шифрование
• TrueCrypt

Введение

Хранение данных в зашифрованном виде - прекрасный способ защитить информацию, чтобы она не попала к злоумышленнику. Для охраны интеллектуальной собственности, производственных секретов или информации личного характера разрабатываются криптографические системы. Они могут быть выполнены в различных формах, предлагать разные уровни функциональности и содержать любое число опций, чтобы подходить под широкий диапазон операционных оболочек и сред. Сегодня количество современных криптографических методов, алгоритмов и решений гораздо больше, чем раньше. Да и качество разработки намного лучше. Более того, на рынке присутствует немало работоспособных решений на основе открытого кода, что позволяет достигать хорошего уровня защиты, не тратя большие суммы денег.

В декабре 2005 Понемонский институт провёл среди различных специалистов в сфере защиты информации опрос, касающийся шифрования и защиты данных. Среди 6298 опрошенных лишь 4 процента респондентов использовали шифрование в масштабах предприятия. Из этого же опроса выявились три главные причины стойкого противления официальным правилам шифрования:

• 69% опрошенных упоминали проблемы с производительностью;
• 44% опрошенных упоминали сложности с реализацией;
• 25% опрошенных говорили о высокой цене реализации криптографических алгоритмов.

Во многих странах организации подвержены воздействию множества рычагов давления для увеличения "прозрачности" их работы. Но, с другой же стороны, на них лежит установленная законом ответственность за необеспечение сохранности конфиденциальной информации. Так было, в частности, в случае с обувными магазинами корпорации DSW в США).

Федеральная торговая комиссия США выдвинула иск против DSW, в котором было заявлено о необеспечении должного уровня защиты информации и непринятии должных мер для построения адекватных систем ограничения доступа к этим данным, а также о неудовлетворительной защите сетевых соединений между магазинными и офисными компьютерами. В случае с компанией DSW примерно 1,4 миллиона кредитных карт и около 96 тысяч чековых счетов были потенциально доступны преступникам. И прежде чем соглашения между компанией и ФТК были достигнуты, этими счетами уже успели нелегально воспользоваться.

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

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

Потребители также начинают осознавать, что важно защищать личную информацию не только в Интернете, но и вне сети. В конце концов, нежелательный доступ к вашим данным не всегда происходит через сеть. Этот вопрос особенно актуален для тех, чьи незащищённые ноутбуки могут попасть либо в руки обслуживающего персонала для изменения конфигурации, либо в сервис на ремонт.

Технические вопросы шифрования

Функции шифрования необходимы всем современным многопользовательским компьютерным системам, где данные, процессы и информация пользователей логически разделяются. Чтобы установить подлинность пользователя в подобной системе, логины и пароли хэшируются и сравниваются с уже имеющимися в системе хэшами (либо хэш используется для расшифровки сеансового ключа, который потом проверяется на валидность). В целях предотвращения несанкционированного просмотра личной информации внутри зашифрованных контейнеров могут храниться отдельные файлы или целые разделы. А сетевые протоколы, например, SSL\TLS и IPSec, позволяют, если это необходимо, усилить криптографическую защиту различных устройств (/dev/random, /dev/urandom и т.д.) с помощью модульных алгоритмов, работающих с ядром операционной системы.

Задача любой технологии шифрования диска состоит в защите от нежелательного доступа к личной информации и в уменьшении урона от потерь интеллектуальной собственности в результате нелегального доступа или кражи физического устройства. Операционная система Linux с версией ядра 2.6.4 представила усовершенствованную криптографическую инфраструктуру, которая просто и надёжно защищает личные данные на многих уровнях программного обеспечения. Существуют как целые стандарты хранения данных в зашифрованном виде на низком уровне, подобно Linux Unified Key Setup (LUKS), так и реализации на пользовательском уровне, например, файловые системы EncFS и CryptoFS, которые, в свою очередь, основаны на Fast Userspace File System (FUSE) под Linux. Конечно же, любая криптографическая система устойчива к взлому настолько, насколько устойчивы её пароли и ключи доступа. Всего существует три основных уровня, на которых применяются технологии шифрования:

• уровень файлов и файловой системы (пофайловое шифрование, контейнер с файлами);
• низкий блочный уровень (контейнер с файловой системой);
• уровень "железа" (специализированные криптографические устройства).

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

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

Некоторые криптографические технологии бесплатны и включены во многие дистрибутивы. Кстати, последние версии Windows оснащаются специальной файловой системой с поддержкой шифрования Encrypted File System (EFS). Fedora поддерживает ряд опций шифрования, включая LUKS (можно включить поддержку LUKS и под Windows, если использовать файловые системы FAT или FAT32 и приложение FreeOTFE). А в дополнительных пакетах Extras доступны FUSE и EncFS. CryptoFS тоже можно установить, скачав с официального сайта. .

Инфраструктура FUSE состоит из загружаемого модуля ядра и userspace-библиотеки, которая служит основой как для файловой системы CryptoFS, так и для Encrypted file system (EncFS). По своей структуре FUSE не затрагивает исходный код ядра и при этом обеспечивает высокую гибкость для реализации многих интересных дополнений, например, файловой системы с удалённым монтированием Secure Shell file system (SSHFS).

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

Файловая система EncFS - тоже userspace-реализация на основе библиотека FUSE, обеспечивающая защиту от кражи информации и работающая по принципу пофайлового шифрования. Она унаследовала свою структуру от ранних версий, но с улучшениями как по форме, так и по функциям. Файловая система EncFS может быть динамически расширена, чтобы удовлетворить возрастающим требованиям пользователей. Файлы могут шифроваться по различным параметрам (например, при изменении содержания, по атрибутам и т.д.). По сути, нижележащим хранилищем для EncFS может быть что угодно: от ISO-образа до сетевого раздела или даже распределённой файловой системы.

Обе файловых системы работают по сквозному принципу, и их можно использовать поверх других файловых систем и логических абстракций, например, поверх журнальной или расширенной файловой системы, которая может быть распределена по нескольким физическим носителям посредством менеджера логических разделов (LVM). Следующая иллюстрация схематично показывает, как работает эта файловая система: в данной диаграмме видимая директория обозначена /mount (уровень незашифрованных данных EncFS).

Userspace-оверлей, показывающий взаимодействие FUSE и EncFS.

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

LUKS работает без точного знания формата файловой системы.

LUKS разработана в соответствии с Trusted Key Setup #1 (TKS1) и совместима с Windows, если использовать какой-либо общий формат файловой системы (FAT/FAT32). Система хорошо подходит для мобильных пользователей, поддерживает выпуск и отзыв ключей Gnu Privacy Guard (GPG) и абсолютно бесплатна. LUKS способна на гораздо большее, чем любая другая описанная в этой статье реализация. Более того, LUKS поддерживает большое число решений для создания и управления устройствами с шифрованием LUKS.

Файловая система CryptoFS принимает только пароль, в то время как носитель, зашифрованный с помощью LUKS, работает с любыми ключами PGP (Pretty Good Privacy) с любым количеством паролей. EncFS также использует пароль для защиты файлов, но он открывает ключ, хранящийся в соответствующем корневом каталоге.

Различия между реализациями на низком и userspace-уровнях лучше всего заметны на практических тестах. На низком уровне данные могут быть "прозрачно" переданы файловой системе, которая управляет операциями записи и чтения гораздо эффективнее.

Тестовая конфигурация

Нашей тестовой платформой стал ноутбук Dell Latitude C610, немного устаревший, но всё же достаточно шустрый представитель технологий образца 2002 года. При питании от аккумулятора C610 снижает частоту процессора до 733 МГц. Поэтому во время тестирования мы не отключали ноутбук от розетки. В следующей таблице приведена конфигурация ноутбука

Результаты тестирования были получены при использовании файловой системы EXT3 под Linux. Возможно, EXT3 в сравнении с другими журнальными файловыми системами не самая производительная. Но эксперименты с тонкой настройкой формата системы, размера блоков, параметров накопителей и т.д. не являются задачами нашего тестирования, поскольку не соответствуют критериями простой настройки и конфигурации. Напомним, что целью статьи было показать, как криптографические решения под Linux позволяют просто, эффективно и дёшево создавать защищённые хранилища данных.

Установка

LUKS, FUSE и EncFS доступны в дистрибутиве Fedora, так что дополнительных усилий прилагать не потребуется. А вот CryptoFS придется скачивать отдельно.

Компиляция CryptoFS из исходного кода достаточно проста. Распакуйте архив, выполните конфигурационный скрипт в конечной директории, затем запустите make, как показано на иллюстрации. Файл конфигурации содержит четыре параметра: код шифрования (encryption cipher), алгоритм профиля сообщения (message digest algorithm), размер блока (block size) и счётчик (encryption salt count).

Процесс установки CryptoFS прост.

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

Настройка CryptoFS.

Затем можно запускать команду mount, после чего можно будет видеть смонтированный раздел.

Сначала убедитесь в загрузке модуля ядра FUSE (modprobe fuse). EncFS упрощает процесс создания зашифрованного контейнера, как видно на следующей иллюстрации.

Если опустить процесс установки ключей (который специфичен для каждой ситуации), то LUKS можно легко настроить, как показано ниже.

Тесты и анализ производительности

Различия в производительности между "родной" установкой и установкой в среде, зашифрованной LUKS, достаточно незначительны. Особенно с учётом заметной разницы у userspace-решений. Для поочерёдной оценки производительности зашифрованных файловых систем мы использовали Iozone. Для тестов используются записи от 4 кбайт до 16 Мбайт, размер файла меняется от 64 кбайт до 512 Мбайт, а результат указан в кбайт/с.

Заключение

По крайней мере, там, где используется LUKS, о производительности можно не задумываться. Хотя, конечно, некоторая потеря производительности вызвана "прозрачным" шифрованием данных. Систему LUKS легко и просто установить, а использовать её можно как в Linux, так и под Windows.

Корпоративным пользователям наверняка придётся столкнуться с ограничениями, связанными с политикой компании. Часто они запрещают решения на основе открытого исходного кода или запрещают некоторые реализации. Кроме того, иногда приходится учитывать ограничения по импорту/экспорту технологий шифрования, касающиеся стойкости кода, или ИТ-департамент требует телефонной поддержки со стороны поставщика решения, что позволяет забыть о LUKS, EncFS и CryptoFS. В любом случае, LUKS - прекрасное решение, если подобные проблемы вас не беспокоят. Хороший вариант для малого бизнеса или для домашних пользователей.

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

Мнение редактора

CryptoFS и EncFS - userspace-реализации. Как мы объясняли ранее, они отличаются простотой дизайна и реализации, но за это приходится платить производительностью и возможностями. Особенно это очевидно при сравнении с LUKS. Она не только работает ощутимо быстрее, но также поддерживает один или несколько PGP-ключей и может использоваться на всём разделе.

Userspace-контейнеры важны, в первую очередь, для пользователей, которые желают защитить личную информацию в многопользовательском окружении. И кому нужно защитить свои данные так, чтобы даже администратор не смог получить доступ к аппаратным или программным ресурсам. Кроме преимуществ по производительности и межплатформенной поддержке, LUKS прекрасно интегрируется с GNOME и системами управления PGP-ключами. А лёгкость повседневного использования шифрованных LUKS разделов просто впечатляет. Кстати, EncFS поддерживает Pluggable Authentication Module (PAM) под Linux в соответствующих окружениях.

TrueCrypt больше не поддерживается, но dm-crypt и LUKS - отличный вариант с открытым исходным кодом, позволяющий шифровать и использовать шифрованные данные.

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

В мае этого года остановилась разработка приложения TrueCrypt, известного инструментального средства с открытым исходным кодом, предназначенного для шифрования дисков. Как многие из вас знают, это был один из весьма надежных инструментов, предназначенных для шифрования дисков. Прискорбно видеть исчезновение инструмента такого калибра, но величие мира с открытым исходным кодом таково, что есть несколько других инструментов с открытым исходным кодом, которые помогут вам достичь безопасности с помощью шифрования дисков, у которых, к тому же, есть много конфигурационных настроек. Мы рассмотрим два из них - dm-crypt и LUKS - в качестве альтернативы TrueCrypt для платформы Linux. Давайте начнем с краткого рассмотрения dm-crypt, а затем - LUKS.

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

Ресурсы

Шаг 01: Рассматриваем Dm-crypt

Название приложения dm-crypt является сокращением от device mapper- crypt (шифрование при отображении устройства). Как следует из названия, оно базируется на отображении устройств — фреймворке ядра Linux, предназначенном для отображения блочных устройств на виртуальные блочные устройства более высокого уровня. При отображении устройств можно пользоваться несколькими функциями ядра, такими как dm-cache (создает гибридные тома), dm-verity (предназначена для проверки целостности блоков, является частью Chrome OS) и также очень популярным Docker. Для криптографических целей в dm-crypt применяется фреймворк ядра Linux Crypto API.

Итак, если подвести итог, то приложение dm-crypt является подсистемой шифрования на уровне ядра, предлагающее прозрачное шифрование диска: это означает, что файлы доступными сразу после монтирования диска - для конечного пользователя нет видимой задержки. Чтобы шифровать с использованием dm-crypt вы можете просто указать один из симметричных шифров, режим шифрования, ключ (любого допустимого размера), режим генерации IV, а затем в /dev создать новое блочное устройство. Теперь при любой записи на это устройство будет происходить шифрование, а при чтении — расшифровка. Вы можете как и обычно смонтировать на этом устройстве файловую систему, либо можете использовать устройство dm-crypt для создания других конструкций, таких как RAID или том LVM. Таблица соответствия для dm-crypt задается следующим образом:

Здесь значение start-sector (начальный сектор), как правило, равно значению 0, значение size (размер) равно размеру устройства, указываемую в секторах, а target name является именем, которое вы хотите присвоить зашифрованному устройству. Таблица целевого отображения target-mapping table состоит из следующих разделов:

[<#opt_params> ]

Шаг 02: Рассматриваем LUKS

Как мы уже видели на предыдущем шаге, приложение dm-crypt может самостоятельно шифровать / расшифровывать данные. Но у него есть несколько недостатков - если приложением dm-crypt пользоваться непосредственно, то оно не будет создавать на диске метаданные, и это может стать серьезной проблемой в случае, если вы хотите обеспечить совместимость между различными дистрибутивами Linux. Кроме того, приложение dm-crypt не поддерживает использование несколько ключей, тогда как в реальных ситуация очень важно пользоваться несколькими ключами.

Именно по этим причинам на свет появилась методика LUKS (Linux Unified Key Setup — Унифицированная настройка ключей в Linux). LUKS является в Linux стандартом шифрования жестких дисков и стандартизация позволяет обеспечить совместимость различных дистрибутивов. Также поддерживается использование нескольких ключей и парольных фраз. В рамках такой стандартизации к зашифрованным данным добавляется заголовок LUKS и в этом заголовке присутствует вся информация, необходимая для настройки. Когда есть такой заголовок с данными, то пользователи могут легко перейти на любой другой дистрибутив. Сейчас в проекте dm-crypt рекомендуется использовать LUKS в качестве предпочтительного способа настройки шифрования диска. Давайте рассмотрим, как установить утилиту cryptsetup и как ее использовать для создания томов на основе LUKS.

Шаг 03: Установка

Функциональные возможности уровня ядра, которые применяются в dm-crypt, уже есть во всех дистрибутивах Linux; нам нужно к ним только интерфейс. Мы будем пользоваться утилитой cryptsetup, с помощью которой можно создавать тома с использованием dm-crypt, стандарта LUKS, а также старого и доброго приложения TrueCrypt. Для того, чтобы установить cryptsetup на дистрибутивах Debian / Ubuntu, вы можете воспользоваться следующими командами:

$ sudo apt-get update $ sudo apt-get install cryptsetup

Первая команда синхронизирует индексные файлы ракета с содержимым их репозиториев: она получает информацию о последних версиях всех доступных пакетов. Вторая команда загрузит и установит на ваш компьютер пакет cryptsetup. Если вы используете дистрибутив RHEL/Fedora/CentOS, то для установки утилиты cryptsetup вы можете воспользоваться командой yum.

$ yum install cryptsetup-luks

Шаг 04: Создание целевого файла

Теперь, когда утилита cryptsetup успешно установлена, мы должны создать целевой файл, в котором будет храниться контейнер LUKS. Хотя есть много способов создания такого файла, при его создании необходимо выполнить ряд условий:

• Файл не должен состоять из нескольких частей, расположенных в различных местах диска, т. е. для него при создании следует сразу выделить достаточное количество памяти.
• Весь файл нужно заполнить случайными данными с тем, чтобы никто не мог сказать, где будут расположены данные, применяемые при шифровании.

В создании файла, который будет удовлетворять вышеуказанным условиям, нам может помочь команда dd, хотя она и будет работать сравнительно медленно. Просто используйте ее вместе с файлом специального устройства /dev/random, указанным в качестве входных данных, и целевого файла, который должен быть указан в качестве выходных данных. Пример команды выглядит следующим образом:

$ dd if=/dev/random of=/home/nitish/basefile bs=1M count=128

В результате в каталоге /home/nitish будет создан файл с именем basefile, имеющий размер в 128 МБ. Однако, учтите, что на выполнение этой команды может потребоваться достаточно большое время; в системе, которой пользовался наш эксперт, на это потребовался час времени.

Шаг 05: Создаем dm-crypt LUKS

После того, как вы создали целевой файл, в этом файле необходимо создать раздел LUKS. Этот раздел служит в качестве основного слоя, на базе которого строится все шифрование данных. Кроме этого, в заголовке этого раздела (LUKS header) содержится вся информация, требуемая для совместимости с другими устройствами. Чтобы создать раздел LUKS применяется команда cryptsetup:

$ cryptsetup -y luksFormat /home/nitish/basefile

После того, как вы согласитесь с тем, что данные, находящиеся внутри файла basefile, будут безвозвратно удалены, введете парольную фразу, а затем — ее подтверждение, будет создан раздел LUKS. Вы можете проверить это с помощью следующей команды file:

$ file basefile

Обратите внимание, что фраза, которую вы здесь вводите, будет использоваться для расшифровки данных. Очень важно ее запомнить и хранить ее в безопасном месте, поскольку если вы ее забудете, то почти наверняка потеряете все данные, имеющиеся в зашифрованном разделе.

Шаг 06: Создаем и монтируем файловую систему

Контейнер LUKS, который мы создали на предыдущем шаге, теперь доступен в виде файла. В нашем примере, это /home/nitish/basefile. Утилита cryptsetup позволяет открывать контейнер LUKS как независимое устройство. Чтобы сделать это, сначала отобразите файл контейнера на имя устройства, а затем смонтируйте устройство. Команда, осуществляющая отображение, выглядит следующим образом:

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

Шаг 07: Файловая система - продолжение

Файл контейнера LUKS теперь доступен в системе в виде обычного устройства. Прежде, чем мы сможем использовать его для обычных операций, мы должны его отформатировать и создать на нем файловую систему. Вы можете пользоваться любой файловой системой, которая поддерживается в вашей системе. В моем примере, мы использовали ext4, поскольку это самая новая файловая система для систем Linux.

$ mkfs.ext4 -j /dev/mapper/volume1

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

$ mkdir /mnt/files

Теперь выполняем монтирование:

Для перекрестной проверки воспользуйтесь командой df –h - вы в конце списка смонтированные устройств увидите устройство "/dev/mapper/volume1". Видно, что заголовок LUKS уже занимает в устройстве уже некоторое место.

Благодаря этому шагу, вы теперь можете использовать устройство LUKS с файловой системой ext4. Просто используйте это устройство для хранения файлов - все, что вы будет записывать на это устройство, будет шифроваться, а все, что вы будете читать с него, будет расшифровано и показано вам.

Шаг 08: Использование шифруемого диска

Мы выполнили несколько шагов для того, чтобы достичь этого результата, и если вам не очень понятно, как все это работает, вы, скорее всего, запутаетесь в том, что нужно сделать только один раз (требуется для установки), и в том, что нужно делать регулярно при использовании шифрования. Давайте рассмотрим следующий сценарий: вы успешно выполнили все описанные выше шаги, а затем выключили компьютер. На следующий день, когда вы запускаете ваш компьютер, вы не в состоянии найти смонтированное устройство - куда оно делось? Чтобы со всем этим разобраться, нужно иметь в виду, что после запуска системы нужно смонтировать контейнер LUKS, а перед остановкой компьютера - размонтировать.

Для того, чтобы получить доступ к файлу LUKS, каждый раз, когда вы включаете компьютер, выполняйте следующие действия, а затем прежде, чем выключить компьютер, безопасно закрывайте файл:

Откройте файл LUKS (т.е. /home/nitish/basefile) и введите пароль. Команда выглядит следующим образом:

$ cryptsetup luksOpen /home/nitish/basefile volume1

После того, как файл будет открыт, смонтируйте его (если он не монтируется автоматически):

$ mount /dev/mapper/volume1 /mnt/files

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

После того, как все сделаете, размонтируйте устройство следующим образом:

$ umount /mnt/files

После успешного размонтирования, закройте файл LUKS:

$ cryptsetup luksClose volume1

Шаг 09: Резервное копирование

Большинство потерь данных, хранящихся в контейнере LUKS, связаны с повреждением заголовка LUKS или слотов с ключами. Кроме того, что даже из-за случайной перезаписи в память заголовка могут быть повреждены заголовки LUKS, в реальных условиях также возможен полный выход жесткого диска из строя. Лучший способ защититься от таких проблем — это резервное копирование. Давайте посмотрим, какие доступны варианты резервного копирования.

Чтобы создать резервную копию файла заголовка LUKS, укажите в команде параметр luksHeaderBackup:

$ sudo cryptsetup luksHeaderBackup /home/nitish/basefile --header-backup-file /home/nitish/backupfile

Или, если вы хотите восстановить файл из резервной копии, то укажите в команде параметр luksHeaderRestore:

$ sudo cryptsetup luksHeaderRestore /home/ nitish/basefile --header-backup-file /home/nitish/backupfile

Для проверки файла заголовка LUKS и проверки того, что файл, с которым вы имеете дело, соответствует действительно существующему устройству LUKS, вы можете воспользоваться параметром isLuks.

$ sudo cryptsetup -v isLuks /home/nitish/basefile

Мы уже видели, как делать резервную копию файлов заголовков LUKS, но резервная копия заголовка LUKS на самом деле не защитит от полного отказа диска, так что вам с помощью следующей команды cat необходимо сделать резервную копию всего раздела:

$ cat /home/nitish/basefile > basefile.img

Шаг 10: Различные настройки

Есть несколько других настроек, которые при использовании шифрования dm-crypt LUKS могут оказаться полезными. Давайте их рассмотрим.

Чтобы сделать дамп заголовка LUKS, в команде cryptsetup есть параметр luksDump. Он позволит вам сделать снимок файла заголовка LUKS того устройства, которое вы используете. Пример команды выглядит следующим образом:

$ cryptsetup luksDump /home/nitish/basefile

В начале данной статьи мы упоминали о том, что LUKS поддерживает работу с несколькими ключами. Давайте сейчас это увидим в действии, добавив новый слот ключа (прим.пер.: слот ключа — место под ключ ):

$ cryptsetup luksAddKey --Key-slot 1 /home/nitish/basefile

Эта команда добавляет ключ к слоту ключа с номером 1, но только после того, как вы введете текущий пароль (ключ, присутствующий в слоте ключа 0). Всего есть восемь слотов ключей, и вы можете расшифровывать данные с использованием любого ключа. Если вы после того, как добавили второй ключ, сделаете дамп заголовка, вы увидите, что второй слот ключа занят.

Вы можете удалить слоты с ключами следующим образом:

$ cryptsetup luksRemoveKey /home/nitish/basefile

В результате будет удален слот с ключом с самым большим номером слота. Будьте аккуратны и не удаляйте все слоты, иначе ваши данные будут навсегда потеряны.

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

В отличие от некоторых других операционных систем, в Linux имеется множество средств для криптографической защиты информации - от шифрования почтовых переписок до шифрования файлов и блочных устройств. Нас интересует именно шифрование на уровне файловых систем, файлов и блочных устройств. Для начала стоит разобраться, в чем разница. Шифрование на уровне файловых систем предполагает наличие прослойки между основной файловой системой (если, конечно, файловая система сама по себе не поддерживает шифрование) и пользователем.

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

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

В статье будет описана настройка следующих методов криптозащиты:
dm-crypt/LUKS - создание криптоконтейнера с помощью device-mapper и CryptoAPI ядра;
eCryptfs - шифрование на уровне файловых систем;
EncFS - аналогично описанному выше, но не требует загрузки модулей ядра.

DM-CRYPT/LUKS
Существует два вида настройки dm-crypt - plain и LUKS. Отличие в том, что в случае использования LUKS в начале криптотома присутствуют метаданные, позволяющие использовать несколько ключей и изменять их. В то же время наличие подобного заголовка в некоторых случаях само по себе компрометирующе - впрочем, в большинстве подобных случаев будет компрометирующей и область с высокой степенью энтропии. Настройка plain dm-crypt с файлом ключа и парольной фразой Посмотрим, как настроить комбинацию из тома plain dm-crypt, зашифрованного с помощью ключевого файла, в свою очередь содержащегося в LUKS-контейнере. Для начала стоит определиться, как именно будут размещаться разделы. Существует три основных варианта:
просто крипто-том;
сперва крипто-том, затем поверх него LVM;
сперва крипто-том, затем RAID, затем LVM.

И всяческие комбинации. Давай попробуем второй вариант. Первым делом создадим контейнер LUKS для хранения ключевого файла, чтобы использовать этот файл вместе с ключевой фразой. В этом случае вероятность криптоанализа тома, зашифрованного с помощью plain dm-crypt, снижается:

Первая команда подготавливает файл контейнера, вторая этот контейнер создает, третья подключает, четвертая генерирует ключевую информацию. Стоит заметить, что опция –align-payload=1 нужна для того, чтобы размер метаданных LUKS составлял не 4096 512-байтовых блоков, а всего лишь 2056. Таким образом, на собственно ключевую информацию остается 512 байт.
Затем переходим к созданию криптотома. На этом этапе по желанию можно также заполнить диск псевдослучайными данными, чтобы затруднить криптоанализ, если он будет. Затем уже можно создавать криптотом. Команда для этого выглядит следующим образом (естественно, в иных случаях идентификаторы могут отличаться, так что нужно быть внимательным):

При необходимости надо повторить аналогичную команду и на других устройствах, для которых требуется шифрование. Затем создадим на криптотомах LVM и ФС на нем:

Создадим файл /etc/initramfs-tools/hooks/cryptokeys примерно следующего содержания (служебная часть скрипта опущена):

И файл /etc/initramfs-tools/scripts/local-top/cryptokeys (служебная часть опять
же опущена):

Эти два файла должны быть исполняемыми. Затем создаем initrd:

При следующей перезагрузке будет запрошен пароль для LUKS-контейнера. В случае использования plain dm-crypt есть еще одна возможность - общий нижний слой, что позволяет сделать нечто наподобие скрытых томов TrueCrypt. Проще привести пример:

Размер и смещение указываются в 512-байтовых блоках.

Расширенные возможности LUKS
Давай посмотрим также и на расширенные возможности использования LUKS-контейнеров. К ним можно отнести смену ключей. Это необходимо при компрометации или создании политики смены ключей. Первым шагом для этого будет создание резервной копии заголовка контейнера. Если все
нормально, после смены ключа ее можно уничтожить. Делаем мы ее, понятно, на нешифрованный раздел:

Наконец, добавляем новый ключ в систему:

Рассмотрим и процедуру восстановления томов LUKS. Самый простой вариант, разумеется, когда есть копия заголовка. В этом случае для восстановления требуется всего одна команда:

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

ENCFS
Посмотрим, как настроить EncFS для автоматического монтирования при входе в систему. Для начала поставим нужные пакеты:

При настройке в режиме эксперта будет задан ряд вопросов: тип шифра (доступны только AES и Blowfish), размер ключа, размер блока, как шифровать имена файлов - блочное шифрование (которое полностью скрывает имя файла, в том числе длину), потоковое (которое шифрует с максимально близкой длиной, что иногда удобно, если имена чересчур длинные и при использовании блочного шифра есть достаточно большая вероятность превысить максимально допустимую длину) или вовсе будет отсутствовать… В конце будет запрошен пароль, он должен совпадать с используемым для входа, в противном случае автомонтирование работать не будет.

Следом нужно отредактировать файл /etc/security/pam_encfs.conf:

И файл /etc/fuse.conf:

И добавим пользователя в группу fuse:

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

ECRYPTFS
Известно, что eCryptFS применяется в Ubuntu как средство по умолчанию для защиты домашних каталогов. Посмотрим, как оно работает, - создадим шифрованный каталог вручную. Установим пакеты:

СозданиеeCryptFS

И смонтируем ФС (при первом монтировании создаются все необходимые метаданные):

Будет запрошена парольная фраза (всего один раз, повторный ввод не реализован, что выглядит не очень хорошим решением, учитывая, что она должна быть длинной), затем будет запрошен тип шифра (AES, Blowfish, 3DES, Twofish, CAST6 и CAST5), размер ключа, задан вопрос, разрешить или запретить нешифрованные файлы в каталоге с зашифрованными, шифровать ли имена файлов… и в финале спросит, действительно ли желаем подмонтировать и сохранить ли сигнатуру в определенный файл. Вопрос не настолько глупый, как может показаться сначала: в данном ПО при отсутствии сигнатуры не существует возможности отличить правильный пароль от неправильного.

Шифрование домашнего каталога пользователя

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

Посмотрим, как его восстанавливать. Предположим, что парольная фраза не записана и восстановление идет с Live CD. Подразумевается, что ФС подмонтирована. Переходим в каталог home/.ecryptfs/rom/.ecryptfs и набираем команду:

dm-verify
Модуль dm-verify предназначен для проверки целостности блочных устройств. Верификация ведется с помощью hash tree, где «листья» - хеш-суммы блоков, а «ветви» - хеш-суммы наборов «листьев». Таким образом, для верификации блочного устройства (будь то раздел или диск) достаточно проверить всего одну контрольную сумму.
Этот механизм (вкупе с цифровой подписью) применяется в некоторых Android-устройствах для защиты от модификации системных разделов, а также в Google Chromium OS.

ЗАКЛЮЧЕНИЕ
Linux содержит действительно немало средств для криптографической защиты информации. Из трех описанных средств как минимум одно присутствует во всех современных дистрибутивах Linux. Но что же выбрать?
dm-crypt/LUKS стоит применять в тех случаях, когда есть возможность быстро отключить зашифрованный том и когда резервные копии либо не нужны, либо засекречиваются иным путем. В этом случае данное решение более чем эффективно, особенно с учетом того, что шифровать можно каскадом произвольной вложенности и типа (например, AES-Twofish-AES), - настоящий рай
для параноиков.
eCryptFS подходит в тех случаях, когда нужно шифрованные данные куда-то сохранять - к примеру, в облако. Она обеспечивает довольно надежноешифрование (хотя в 128-битном варианте, используемом по умолчанию, есть возможность снижения криптостойкости на два бита) и для конечного пользователя прозрачна.
EncFS же - старичок примерно десятилетней давности, базирующийся на еще более древних работах. К настоящему времени не рекомендован к использованию из-за потенциальных дыр в безопасности, но может применяться в качестве кросс-платформенного средства для защиты несенситивных данных в облаках.

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