Сравнение производительности различных систем шифрования под linux. Шифрование жесткого диска в Linux Проверить файловую систему luks

Хотите спрятать свои данные от посторонних глаз? Мы научим вас приемам шифрования жёсткого диска.

За последний год тема безопасности интернет-данных всплывала часто: сначала в связи с откровениями Сноудена, потом - с уязвимостью в OpenSSL (Heartbleed bug). Незадолго до последней была обнаружена и менее заметная ошибка в GnuTLS. В результате мы стали уделять больше внимания безопасности удалённых данных; но как насчёт тех, что хранятся у нас на диске?

Стек блочных устройств

Прежде чем рассматривать шифрование, важно осознать, как работают блочные устройства. Они являются системными интерфейсами для устройств хранения данных, например, /dev/sda! Внутри блочного устройства находится аппаратный драйвер, например, SATA, и собственно оборудование. Затем операционная система взаимодействует с блочным устройством для создания на нем файловой системы.

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

Такие технологии, как RAID и LVM (Logical Volume Management), также представляют собой стеки блочных устройств. У вас может быть LVM поверх массива RAID, который, в свою очередь, также расположен на блочных устройствах отдельных дисков или их разделов.

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

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

Всё делается за счёт ядра, но на уровне пользователя нам необходимо программное обеспечение для создания устройств dm-crypt и управления ими; таким стандартным инструментом выступает cryptsetup. Вероятно, он уже установлен в вашем дистрибутиве; а если нет, то уж точно будет в основных репозиториях.

Шифрование

Значений по умолчанию, как правило, более чем достаточно, а все доступные опции можно просмотреть с помощью cryptsetup -help Эти параметры необходимы только с LuksFormat. При создании защищенного устройства cryptsetup автоматически использует правильные настройки для его открытия.

Лучше всего придерживаться популярных шифров и хэшей, если только у вас нет более веской причины выбрать что-то другое. У методов, используемых реже, могут быть скрытые недостатки, просто потому, что они менее протестированы, что и произошло недавно с реализацией хэша Whirlpool в библиотеке libcgrypt, используемой cryptsetup. При внесении исправлений пострадали те системы, где уже использовались дефектные хэши.

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

LUKS

LUKS — Linux Unified Key Setup был создан ради предоставления стандартного, кросс-платформенного (несмотря на название) формата хранения шифрованных данных на дисках. Он касается не методов шифрования, а способа хранения информации о них.

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

Имейте в виду, автор данного труда рассказывает о методах шифрования разделов диска, которые использует сам, при .

Linux

В данном руководстве используется Linux dm-crypt (device-mapper ) на ядре 2.6 . Шифровать будем раздел /dev/sdc1 , это может быть любой раздел, диск, USB или файл, созданный losetup . Здесь мы будем использовать /dev/loop0 , смотрите . Device mapper использует метку для идентификации раздела, в данном примере sdc1 , но это может быть любая другая строка.

Шифрование разделов диска с помощью LUKS

LUKS с dm-crypt очень удобен для шифрования разделов диска, он позволяет иметь несколько паролей для одного раздела а так-же с легкостью менять их. Что-бы проверить доступно-ли у вас использование LUKS , наберите: cryptsetup --help , если насчет LUKS ничего не появилось, читайте ниже "dm-crypt без LUKS ". Для начала создайте раздел, если необходимо fdisk /dev/sdc .

Как создать зашифрованный раздел

# dd if=/dev/urandom of=/dev/sdc1 # Опционально. Только для параноиков # cryptsetup -y luksFormat /dev/sdc1 # Это уничтожит все данные на sdc1 # cryptsetup luksOpen /dev/sdc1 sdc1 # mkfs.ext3 /dev/mapper/sdc1 # Будет создана файловая система ext3 # mount -t ext3 /dev/mapper/sdc1 /mnt # umount /mnt # cryptsetup luksClose sdc1
Монтировать
# cryptsetup luksOpen /dev/sdc1 sdc1 # mount -t ext3 /dev/mapper/sdc1 /mnt
Размонтировать
# umount /mnt # cryptsetup luksClose sdc1

dm-crypt без LUKS

# cryptsetup -y create sdc1 /dev/sdc1 # Или любой другой раздел, типа /dev/loop0 # dmsetup ls # Проверить, покажет: sdc1 (254, 0) # mkfs.ext3 /dev/mapper/sdc1 # Только если делается впервые! # mount -t ext3 /dev/mapper/sdc1 /mnt # umount /mnt/ # cryptsetup remove sdc1 # Отсоединить зашифрованный раздел Делайте тоже самое, (без создания fs), что-бы переподключить раздел. При вводе некорректного пароля команда mount не будет выполнена. В таком случае просто удалите отображение sdc1 (cryptsetup remove sdc1 ) и создайте по новой.

FreeBSD

Пара популярных модулей для шифрования дисков в , это gbde и geli . Geli более быстрый т.к использует аппаратное ускорение. Смотрите FreeBSD handbook Chapter 18.6 для более подробного описания. Для работы, geli должен быть загружен как модуль ядра, или встроен в него на стадии компиляции. options GEOM_ELI device crypto # Или загрузить в качестве модуля ядра: # echo "geom_eli_load="YES"" >> /boot/loader.conf # Или kldload geom_eli

Использование пароля и ключа

Автор пользуется данными настройками для типичного шифрования разделов, он использует пароль и ключ для шифрования "Master key - основного ключа". Что-бы смонтировать зашифрованный раздел, понадобится и пароль и ключ /root/ad1.key . "Master key " хранится вутри раздела и невидим. Следующий пример типичен для USB или файлового образа.

Создаем шифрованный раздел

# dd if=/dev/random of=/root/ad1.key bs=64 count=1 # Этот ключ шифрует Master key # geli init -s 4096 -K /root/ad1.key /dev/ad1 # -s 8192 и OK для дисков # geli attach -k /root/ad1.key /dev/ad1 # DO создает резервную копию /root/ad1.key # dd if=/dev/random of=/dev/ad1.eli bs=1m # Опционально и занимает много времени # newfs /dev/ad1.eli # Создать файловую систему # mount /dev/ad1.eli /mnt # Монтирование шифрованного раздела
Attach
# geli attach -k /root/ad1.key /dev/ad1 # fsck -ny -t ffs /dev/ad1.eli # Если есть сомнения, проверьте файловую систему # mount /dev/ad1.eli /mnt
Detach
Процедура размонтирования производится автоматически при выключении. # umount /mnt # geli detach /dev/ad1.eli
/etc/fstab
Монтирование шифрованного раздела можно сконфигурировать через /etc/fstab . Пароль будет запрошен при загрузке. # grep geli /etc/rc.conf geli_devices="ad1" geli_ad1_flags="-k /root/ad1.key" # grep geli /etc/fstab /dev/ad1.eli /home/private ufs rw 0 0

Только по паролю

Это более подходящий способ для шифрования флэшки или образа на основе файла, запрашивается только пароль. В данном случае не нужно волноваться о файлах ключей. Процедура напоминает вышеописанную, за исключением создания файлов ключей. Зашифруем образ размером 1 Гб, созданный из файла /cryptedfile . # dd if=/dev/zero of=/cryptedfile bs=1M count=1000 # Создаем 1Гб файл # mdconfig -at vnode -f /cryptedfile # geli init /dev/md0 # Зашифровать только по паролю # geli attach /dev/md0 # newfs -U -m 0 /dev/md0.eli # mount /dev/md0.eli /mnt # umount /dev/md0.eli # geli detach md0.eli Теперь этот образ можно примонтировать на другую машину, просто введя пароль. # mdconfig -at vnode -f /cryptedfile # geli attach /dev/md0 # mount /dev/md0.eli /mnt

Диска (a la TrueCrypt). Я знаю, что была работа по добавлению поддержки шифрования в GRUB2, но пока это пока не готово. Любые другие варианты?

(Обратите внимание, что я действительно имею в виду полное шифрование диска здесь, в том числе /boot)

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

Не вдаваясь в дискуссию о том, почему мне действительно нужно / boot быть зашифрованным, вот статья, которая точно описывает, что мне нужно, на основе модифицированной версии GRUB2:

  • http://xercestech.com/full-system-encryption-for-linux.geek

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

8 Solutions collect form web for “Linux-загрузчики, поддерживающие полное шифрование диска?”

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

Обновление (2015) : последняя версия GRUB2 (2.00) уже содержит код для доступа к зашифрованным разделам LUKS и GELI. (Ссылка xercestch.com, которую предоставили OP, упоминает первые исправления для этого, но теперь они включены в последнюю версию).

Однако, если вы пытаетесь зашифровать весь диск по соображениям безопасности, обратите внимание, что незашифрованный загрузчик (например, TrueCrypt, BitLocker или модифицированный GRUB) не обеспечивает больше защиты, чем незашифрованный /boot раздел (как указано СП в комментарии выше). Любой, у кого есть физический доступ к компьютеру, может так же легко заменить его на пользовательскую версию. Это даже упоминается в статье на xercestech.com, которую вы связали:

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

Обратите внимание, что все программные продукты для полного шифрования диска имеют эту слабость, независимо от того, используют ли они незашифрованный загрузчик или незашифрованный раздел boot / preboot. Даже продукты с поддержкой чипов TPM (Trusted Platform Module), таких как BitLocker, могут быть внедрены без изменения оборудования.

Лучшим подходом было бы:

  1. расшифровывать на уровне BIOS (в материнской плате или на адаптере диска или на внешнем оборудовании [смарт-карта], с чипом TPM или без него), или
  2. нести код авторизации PBA (preboot authorization) (раздел /boot в этом случае) на съемном устройстве (например, смарт-карте или USB-накопителе).

Чтобы сделать это вторым способом, вы можете проверить проект Linux Full Disk Encryption (LFDE) по адресу: http://lfde.org/ , который предоставляет сценарий после установки, чтобы переместить раздел /boot на внешний USB-накопитель, зашифровав ключ с GPG и хранение его на USB тоже. Таким образом, слабая часть загрузочного пути (незашифрованный /boot раздел) всегда с вами (вы будете единственным с физическим доступом к расшифровке кода и ключу). (Примечание : этот сайт был потерян, и блог автора также исчез, однако вы можете найти старые файлы на https://github.com/mv-code/lfde , просто отметив, что последняя разработка была выполнена 6 лет назад). В качестве более легкой альтернативы вы можете установить незашифрованный загрузочный раздел на USB-накопителе при установке ОС.

С уважением, М.В.

Сделайте свой первый RAMdisk и / boot папку не использующим шифрование.

Это вызовет «минимальное» ядро ​​с драйверами и поддержкой для переключения на «настоящую» корневую файловую систему, которая зашифрована.

Прежде чем вы заявите «это взломать», помните – большинство (если не все) дистрибутивов Linux загружаются по умолчанию сегодня. Это явно позволяет вашей системе загружать и загружать корневую FS, используя модули, которые необходимо загрузить из файловой системы. (Вид проблемы с курицей и яйцом). Например, если ваша корневая файловая система была на томе аппаратного RAID-массива, и вам нужно было загрузить его драйвер, прежде чем вы сможете смонтировать корневой FS.

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

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

У Ubuntu есть хорошая страница с инструкциями по созданию зашифрованных разделов, LMVP, папок и т. Д., Просто ваша версия вашего дистрибутива …

Нет, я думаю, что нет.

Вам действительно нужно шифровать / загружать? Я подозреваю, что нет. Остальная часть файловой системы может быть зашифрована обычным программным обеспечением Linux, которое находится в initramfs in / boot и запрашивает пользователя соответственно.

Кажется, вы просите что-то, что невозможно сделать, и сравнивая его с решением Windows, которое скрывает реализацию от вас, но на самом деле делает то же самое, что делает Linux.

Самое близкое решение, о котором я могу думать, – использовать жесткий диск, который реализует пароль безопасности и шифрование. Некоторые ноутбуки Thinkpad используют эти аппаратные решения.

Ответ намечен статьей. «Теперь это возможно с расширениями к загрузочному загрузчику следующего поколения GRUB2, который был исправлен, чтобы поддерживать не только« и «мы хотим установить новое изображение с поддержкой luks grub2 позже», и «Теперь мы скомпилируем источник GRUB2 с поддержкой LUKS. " Кажется, есть исправление или расширение, которое вам нужно получить и включить с GRUB2 или разветвленным источником GRUB2.

Grub2 версии 2.02 ~ beta3 может многое сделать, что Grub2 версии 2.02 ~ beta2 не может сделать, проверено мной:

  1. Загрузка с использованием диска Super Grub 2
  2. Введите «c», чтобы перейти в командную строку
  3. Введите команды для монтирования зашифрованного раздела, который я хочу
    • insmod luks
    • cryptomount (hd0, #) // где # представляет зашифрованный раздел
  4. Введите ключевую фразу и введите несколько команд
    • multiboot (crypto0) /grub/i386-pc/core.img
    • ботинок

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

Предупреждение: Grub2 версии 2.02 ~ beta2 не может сделать то же самое, поскольку имеет некоторые ошибки (которые, по-видимому, исправлены на Grub2 версии 2.02 ~ beta3), связанные с командой cryptomount …

beta2 ошибки, о которых я говорю, являются:

  1. На самом деле он не монтирует зашифрованный раздел, поэтому он не позволяет вам получить доступ (crypto0) / *
  2. Если существует более одного зашифрованного раздела, использование cryptomount -a требует только одной кодовой фразы
  3. После запуска cryptomount один раз он запускается снова, ничего не делает

на бета-версии 3:

  1. Он действительно монтирует зашифрованный раздел и позволяет вам получать доступ к файлам через (crypto0) / * или (crypto1) / * и т. Д., Если более одного установленного одновременно
  2. Он запрашивает каждую кодовую фразу (по одному за зашифрованный раздел)
  3. Это позволяет вам запускать его столько раз, сколько вам нужно, вы можете установить один, затем другой и т. Д.

Боковое примечание: я не понял, как их размонтировать, кроме перезагрузки или загрузки другого или одного загрузочного загрузчика grub2 / other и т. Д.

Надеюсь, это поможет прояснить ситуацию, и надеюсь, что версия Grub2 2.02 ~ beta3 будет интегрирована в LiveCD, поэтому мы можем установить ее без необходимости компилировать ее сами.

PD: С диском Super Grub 2 я не вижу способа установить Grub2 версии 2.02 ~ beta3 на раздел MBR / boot и т. Д.

В этой статье я расскажу вам, как создать скрытый криптоконтейнер стандартными средствами ОС 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

Автор: Nitish Tiwari
Дата публикации: 04 febriary 2015
Перевод: Н.Ромоданов
Дата перевода: март 2015 г.

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

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