Шифрование жесткого диска в Linux. Использование шифрованной файловой системы по стандартам LUKS Шифрование файловой системы linux
Шифрование домашнего каталога обеспечивает надежную защиту данных, хранящихся на жёстком диске или ином носителе. Шифрование особенно актуально на переносных ПК, на компьютерах с множественным доступом, а также в любых других условиях. Шифрование домашнего каталога предлагается при установке Linux Mint.
Основная загвоздка при полном шифровании домашнего каталога состоит в том, что необходимо «вынести» каталог с зашифрованными данными за пределы точки монтирования.
Производительность снижается незначительно, по крайней мере пока не пользуется SWAP. SWAP – это специальный раздел на диске или файл в который операционная система перемещает отдельные блоки оперативной памяти в случае когда оперативной памяти не хватает для работы приложений. SWAP тоже шифруется, если в инсталляторе выбрать шифрование домашнего каталога, и при этом перестает работать спящий режим.
Не шифровать SWAP при шифрованном домашнем каталоге – потенциально опасно, так как там могут оказаться данные из шифрованных файлов в открытом виде – весь смысл шифрования теряется. Начиная с 14-ой версти Linux Mint, при установке есть возможность выбрать вариант шифрования всего диска. Этот вариант наиболее подходит для сохранения персональных данных на переносных устройствах (у которых, как правило, только один пользователь).
1.3 Шифрование в gnome – Seahorse
В Linux Mint есть встроенная утилита «Пароли и ключи» или же Seahorse. Используя её возможности пользователь может оперировать всеми ключами, паролями, а также сертификатами которые имеются в данной ОС.
По сути Seahorse – это приложение для GNOME (GNOME – свободная среда рабочего стола для Unix-подобных операционных систем), являющееся фронтэндом к GnuPG (свободная программа для шифрования информации и создания электронных цифровых подписей) и предназначенное для управления ключами шифрования и паролями. Пришел на замену GNOME Keyring, которого полностью заменил в GNOME 2.22, хотя был анонсирован еще в GNOME 2.18. Позволяет производить все операции которые ранее необходимо делать в командной строке и объединяя их под едиными интерфесом:
управлять безопасностью своей рабочей среды и ключами OpenPGP и SSH;
шифровать, расшировывать и проверять файлы и текст;
добавлять и проверять цифровые подписи к документам;
синхронизировать ключи с ключевыми серверами;
создавать и публиковать ключи;
резервировать ключевую информацию;
добавлять к изображениями в любом поддерживаемом GDK как OpenGPG photo ID;
1.4 TrueCrypt
TrueCrypt обладает достаточно удобным графическим интерфейсом, но, к сожалению, разработчики жестко зашили в код интеграцию с файловым менеджером Nautilus.
Для шифрования данных можно использовать разные методы.
Для начала нужно создать так называемый контейнер, в котором будут содержаться файлопапки, предназначенные для шифрования. Контейнером может служить файл с произвольным названием или даже целый раздел диска. Для доступа к контейнеру необходимо указать пароль, а также можно сделать файл ключа (необязательная опция), с помощью которого будет шифроваться информация. Размер контейнера ограниченный.
Создание зашифрованных разделов/файлов
Создание файл ключа:
truecrypt -create-keyfile /home/user/test/file , где file – название файла-ключа.
Создание контейнера, в данном случае раздела:
sudo truecrypt -k /home/user/test/file -c /dev/sda9
Вместо раздела /dev/sda9 вполне можно указать и файл, например /home/user/test/cryptofile, но в этом случае необходимо будет указать его размер, это делается параметром -size=5G до параметра -c. В указанном примере создастся файл cryptofile размером 5 Гбайт. Иногда TrueCrypt принимает размер только в байтах, для 5 Гбайт можно или высчитать значение заранее и указать -size=5368709120, или же записать следующим образом: -size=`echo 1024^3*5 | bc`.
Для шифрования будет использоваться сделанный уже файл-ключ.
При создании будет предложен выбор типа контейнера (нормальный / скрытый), файловой системы (FAT, ext2/3/4 или без ФС), в данном примере был выбран режим без использования ФС. Также будет предложен выбор алгоритма шифрования (например, AES), а так же hash-алгоритм (например, SHA-1) для шифрования потоков данных.
TrueCrypt используется для шифрования данных налету, то есть можно, подмонтировав контейнер, работать с находящимися в нём файлами как обычно (открывать/редактировать/закрывать/создавать/удалять), что очень удобно.
Шифрованный раздел/файл был создан. Теперь, если необходимо его внутреннюю файловую систему (далее ФС) отформатировать под нужную, следует сделать следующее.
Выбрать необходимый раздел используя Truecrypt:
truecrypt -k /home/user/test/file /dev/sda9
По умолчанию будет задействован созданный Truecrypt девайс /dev/mapper/truecrypt0. По обращению к этому девайсу, можно менять, например ФС в шифрованном контейнере. В данном случае это нужно сделать.
sudo mkfs.ext4 -v /dev/mapper/truecrypt0
Этим самым была сделана ФС ext4 внутри данного шифрованного контейнера.
Далее, так как данный контейнер уже «прикреплён» к девайсу /dev/mapper/truecrypt0, то осталось его просто примонтировать к какой-нибудь директории. Эта директория для монтирования должна уже существовать в системе.
sudo mount /dev/mapper/truecrypt0 /mnt/crypto , где /mnt/crypto – директория, к которой примонтирован шифрованный контейнер.
truecrypt -d
Теперь без знания файла-ключа и пароля никто не сможет прочесть спрятанную информацию.
Хотите спрятать свои данные от посторонних глаз? Мы научим вас приемам шифрования жёсткого диска.
За последний год тема безопасности интернет-данных всплывала часто: сначала в связи с откровениями Сноудена, потом - с уязвимостью в 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 (LUKS и cryptsetup). Встроенные фишки LUKS"а (такие, как использование внешних заголовков и размещение реальных данных по заданному смещению) позволяют пользователю получить доступ к данным, скрытым внутри существующего контейнера, а также отрицать существование подобных данных.
UPD: Поскольку этот пост был готов ещё месяц назад, тогда я даже не мог представить настолько странную и неожиданную смерть проекта . Ну да, возможно, он ещё не совсем помер , посмотрим… Тем не менее, в этом тексте я решил оставить все ссылки на TrueCrypt как есть.
Что такое «правдоподобное отрицание»?
Вы можете найти весьма длинное и подробное описание этого понятия в Википедии: http://en.wikipedia.org/wiki/Plausible_deniability . Если коротко, это значит, что вы можете обладать чем-то (или могли сделать что-то), наличие чего не может быть никем заподозрено или доказано (если в этом не признаться самостоятельно, конечно). И впоследствии вы можете отрицать наличие (или факт совершения) этого чего-то, если кто-то захочет вас обвинить, поскольку (повторюсь) этот факт недоказуем. Ну например, если ребёнок пнул под зад своего маленького брата, и брат пошёл искать справедливости у родителей, что в этом случае произойдёт?
Ну… Как бы ничего не произойдёт. Потому что этот чувак будет отнекиваться, а родители, формально говоря, не смогут его поймать за руку (поскольку, во-первых, тупо нет свидетелей, а во-вторых, младший братец может вести свою грязную игру). Таким образом, никого не накажут. Ну или накажут обоих на всякий пожарный. Это как раз был пример использования возможности правдоподобного отрицания ребёнком, склонным к агрессии. Но мы-то с вами, безусловно, белые и пушистые, и будем использовать скрытые контейнеры исключительно в целях защиты своих персональных данных от плохих парней. Так ведь? Безусловно, «что такое „хорошо”, и что такое „плохо”» - это отдельный вопрос… Однако, ближе к делу.
Общая идея реализации
Предположим, мы хотим сохранить некие важные данные внутри зашифрованного файла. В общем случае мы будем использовать какую-то программу криптозащиты, которая будет делать за нас всю грязную работу. Возможно, мы захотим работать с зашифрованным файлом как с виртуальным диском, и это значительно сужает число потенциальных кандидатов. Однако, есть одно «но». Практически все подобные программы работают с файлом как с одним куском зашифрованных данных. Поясню: у пользователя обычно есть один пароль (и, быть может, несколько «запасных») для всех данных внутри контейнера. Это означает наличие как минимум одного слабого звена: пароля на контейнер. Я не хочу упоминать о том, что пароль должен быть криптографически надёжным, поскольку это прописная истина. Я имею в виду, что если пользователь по какой-то причине сдаст этот пароль (например, под давлением), все данные будут прочитаны. И этот факт мне кажется печальным и совершенно неправильным…
Хотя вообще-то надежда есть. :) Например, существует такая программа, как , которая является достаточно умной. Пользователь может создать в одном файле два контейнера: один «подставной» с некоторым количеством «запрещённых», но относительно безопасных файлов, а другой - настоящий, с данными, которые не должны засветиться ни в коем случае. Таким образом, TrueCrypt запрашивает два разных пароля, когда пользователь хочет создать подобный «двойной» контейнер. При работе пользователь вводит только один пароль для «настоящей» части и работает с ней. В том случае, если под давлением внешних обстоятельств пользователь вынужден раскрыть содержимое контейнера третьим лицам, он просто вводит другой пароль, и TrueCrypt открывает «фальшивку». Я подчёркиваю (и это действительно важно), что не существует возможности доказать наличие скрытой части, если исследователь не знает соответствующего пароля.
А теперь давайте быстренько разберёмся, как работает это барахло… На самом деле всё очень просто. Софт делит файл-контейнер на две (вообще говоря, неравные) части. Первая часть, которая может быть относительно небольшой, содержит специально подготовленные данные; вторая - настоящие. Соответственно, программа должна уметь работать с двумя различными заголовками (конфигурациями) для двух разных частей, а также уметь выбирать, какую часть расшифровывать в зависимости от введённого пользователем пароля. А это, надо сказать, не самая тривиальная часть работы. Ну просто потому, что «официально» должна быть видна только одна, «фальшивая», конфигурация: если у контейнера есть стандартный заголовок, это должен быть только «фальшивый» заголовок; если параметры контейнера хранятся в отдельном конфиге, этот конфиг должен позволять расшифровать только «фальшивую» часть. И после расшифровки «фальшивой» части не должно появиться ни одного намёка на наличие реальной. Они должны быть абсолютно независимыми. Более того, когда открыта «фальшивая» часть, софт должен показывать полную ёмкость крипто-контейнера, даже в том случае, когда объём этой части намного меньше.
Так что там про LUKS-то?
Ну тут у нас есть хорошие новости и… эм… ещё боле хорошие новости.
Хорошие новости заключаются в том, что cryptsetup умеет расшифровывать и монтировать тома, созданные TrueCrypt"ом. Только для чтения, впрочем, но это ерунда. Поскольку есть новости и получше. А именно, мы можем создавать «скрытые» контейнеры исключительно средствами cryptsetup "а. Более того, эта утилита позволяет создать любое количество «скрытых» частей. Естественно, в разумных пределах. И вот каким образом это можно сделать.
Но перед тем, как продолжить,
ОГРОМНОЕ ЖИРНОЕ СТРАШНОЕ ПРЕДУПРЕЖДЕНИЕ!!!
- Всё, что описано ниже, может стать причиной необратимой потери данных.
- В вашей стране может быть запрещено использование сильной криптографии, так что вас могут посадить не за реальную информацию, а просто за наличие крипто-контейнера, который найдут на вашем винте.
- Криптография может защитить ваши данные, однако она не защитит вас от пыток. Скрытый контейнер может помочь сохранить ценную информацию, но вы не сможете отрицать его наличие в случае предательства или доноса.
- Ребята, которых заинтересовали ваши зашифрованные данные, могут оказаться не настолько тупыми, как вы ожидали. Даже если они не смогут доказать наличие скрытой части контейнера, они вполне могут запереть вас в одной камере с матёрыми уголовниками, и через пару суток вы вспомните все пароли ко всем скрытым данным.
- Если у вас есть близкие люди (девушка/парень, родственники, друзья), они точно так же могут стать мишенью для жёсткого прессинга. И это наверняка поможет значительно быстрее вспомнить вообще всё, включая то, чего вы даже и не знали.
Так что лучше дважды подумайте, насколько информация ценнее вашей жизни и жизни ваших близких. И сделайте бэкап. Просто на всякий случай.
Так вот, man cryptsetup способен рассказать нам множество интересных подробностей о параметрах командной строки этой утилиты. Ну например, давайте глянем на опцию --header :
Ну и ладненько. Это значит, что теперь у нас может иметься в наличии том данных, забитый случайным мусором, причём совершенно без всяких осмысленных сигнатур. Описание этой опции содержит несколько больше информации, предостережений и предупреждений, однако в сухом остатке это всё, что требуется. И тем не менее, я настоятельно рекомендую прочитать это отличное руководство.
Ещё одна весьма полезная опция - это --align-payload , которая позволяет расположить настоящие данные по определённому смещению относительно начала тома:
И это тоже классно, потому что теперь мы свободно можем сдвигать наши данные в любую часть тома. Идею улавливаете, да?
- Инициализируем том для шифрования: полностью перезаписываем его случайными данными.
- Делаем «официальный» зашифрованный том и скидываем на него немножко заражённого вареза, спираченного музла, прона полезных свободных программ, записей вашей любительской рок-группы, фильмов про любовь и т.п., в общем, того, за что вам дадут не больше двух лет условно.
- Используя указанные выше эзотерические опции 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
Имейте в виду, автор данного труда рассказывает о методах шифрования разделов диска, которые использует сам, при .
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 sdc1dm-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 /mntDetach
Процедура размонтирования производится автоматически при выключении. # 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Введение
Хранение данных в зашифрованном виде - прекрасный способ защитить информацию, чтобы она не попала к злоумышленнику. Для охраны интеллектуальной собственности, производственных секретов или информации личного характера разрабатываются криптографические системы. Они могут быть выполнены в различных формах, предлагать разные уровни функциональности и содержать любое число опций, чтобы подходить под широкий диапазон операционных оболочек и сред. Сегодня количество современных криптографических методов, алгоритмов и решений гораздо больше, чем раньше. Да и качество разработки намного лучше. Более того, на рынке присутствует немало работоспособных решений на основе открытого кода, что позволяет достигать хорошего уровня защиты, не тратя большие суммы денег.
В декабре 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 в соответствующих окружениях.