Full Disk Encryption (FDE)

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

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

Что будем использовать


Дистрибутив: Slackware Linux 14.2 (но думаю, всё легко адаптировать под любой дистрибутив Linux)
Шифрование: Luks
Разметка: LVM
Загрузчик: Grub2

Разметка и шифрование диска


Начинаем с разметки диска. Так, как мы планируем шифровать весь диск, нам необходимо создать только один раздел (я не использую UEFI).

parted /dev/sda mklabel msdos
parted -a optimal /dev/sda mkpart primary 0% 100%

Теперь форматируем данный раздел под Luks и подключаем его.

cryptsetup luksFormat /dev/sda1
cryptsetup luksOpen /dev/sda1 lda


После выполнения luksOpen у нас появилось блочное устройство lda, которое мы уже можем разметить с использованием LVM.

pvcreate /dev/mapper/lda
vgcreate vga /dev/mapper/lda
lvcreate -L4G -n swap vga
lvcreate -L32G -n root vga
lvcreate -l100%FREE -n home vga

Создаём swap-раздел.

mkswap /dev/vga/swap

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

Загрузка


Первым делом, нам необходимо создать initrd/initramfs так, как ядро не в состоянии самостоятельно получить доступ к шифрованному диску. Тут следует отметить, что большинство коробочных дистрибутивов рассчитаны на загрузку с раздела /boot без шифрования и на то, что пароль для доступа к шифрованному диску надо будет вводить во время загрузки (инициализации системы). Для нас это означает то, что мы должны будем вводить пароль дважды, что не слишком удобно. Решить эту проблему можно создав luks-ключ и разместив его в initrd.

dd bs=512 count=4 if=/dev/urandom of=/root/boot.key
cryptsetup luksAddKey /dev/sda1 /root/boot.key

Настоятельно рекомендую обратиться к документации на утилиту для создания initrd/initramfs вашего дистрибутива. Она может поддерживать добавление luks-ключей. В Slackware я столкнулся с тем, что работа с такими ключами поддерживается, но ключ должен быть размещён на незашифрованном носителе (к примеру, на флешке). Пришлось схитрить следующим образом:

# создаём initrd
mkinitrd -c -k 4.4.14 -m ext4 -f ext4 -r /dev/vga/root -C /dev/sda1 -L

# копируем ключ
install -D -m 0600 /root/boot.key /boot/initrd-tree/mountkey/boot.key

# пересоздаём initrd
mkinitrd -c -k 4.4.14 -m ext4 -f ext4 -r /dev/vga/root -C /dev/sda1 -L -K :/boot.key

Grub


Я не особо долго искал, но из того, что попалось под руку, загрузку с шифрованного диска поддерживает только Grub2.
Для того, чтобы загрузчик смог получить доступ к файлам на диске, нам необходимо в /etc/default/grub добавить соответствующий ключ:

GRUB_ENABLE_CRYPTODISK=y
GRUB_CRYPTODISK_ENABLE=y

Как можно видеть, я указал и GRUB_ENABLE_CRYPTODISK и GRUB_CRYPTODISK_ENABLE. Это первый подводный камень, на который я наткнулся. В природу этого явления я не вникал, но по документации надо использовать первый, а grub-mkconfig проверяет на «y» именно второй.

Устанавливаем загрузчик.
grub-mkconfig -o /boot/grub/grub.cfg
grub-install /dev/sda

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

Материалы по теме и источники


Full disk encryption with LUKS (including /boot) — Pavel Kogan
Installing Slackware on encrypted volumes — Eric Hameleers
Ads
AdBlock has stolen the banner, but banners are not teeth — they will be back

More

Comments 53

    0
    Вот бы кто ещё придумал как сделать туда внутрь раздел с загружаемой виндой
      0
      qemu/kvm? В принципе, можно заморочиться и сделать pci-passthrough видеокарты. А блочное и сетевое IO — через хост-систему. Общаться с ней можно будет либо по сети (с другой машины), либо через последовательный порт.
        0
        Ды что то сложно. Речь про вторую ос для поиграть, в основном. Это к тому что ей бы полноценно загружаться, а не внутри виртуальной машины.

        Причём, принципиально проблем нет, я так понял — был же fde в том же truecrypt.

        Просто нет кроссплатформенного решения почему то
          0
          Я с трудом себе представляю такую схему. Особенно в контексте винды, у которой свой загрузчик.
            0
            Схема то как раз представима.

            — Windows может быть зашифрована до уровня «запрос пароля на уровне загрузчика» при помощи truecrypt
            — Linux может быть зашифрован до уровня «запрос пароля на уровне загрузчика» десятком (наверное) способов

            Если я правильно помню про truecrypt, оно там чуть ли не в роли прослойки между ос и оборудованием должно было выступать.

            Просто реально неудобно что с какой то одной ос ты себе можешь fde организовать, а на две — неа
      +1
      Весь диск шифровать LUKS — это оверкилл…
      Как правило, /home выносят на отдельный раздел и шифруют только его, тк всё остальное обычно не представляет особого интереса с точки зрения утечки данных.
        0
        Всё-таки, обычно, если учесть массовость использования коробочных решений, шифруют весь диск кроме /boot.

        Что же касается излишества — зависит от того, что и где вы храните и как сильно у вас развита паранойя. Я вот даже /etc/wpa_supplicant.conf отдавать никому не хочу.

        Кроме того, подобный подход позволяет вводить пароль только один раз, без ущерба для безопасности (конечно, если с данным ноутом работает только один человек) так, как если кто-то сможет обойти luks, остальные пароли его даже не затормозят.
          0
          > Я вот даже /etc/wpa_supplicant.conf отдавать никому не хочу.
          Если у вас паранойя, это еще не значит, что за вами никто не следит)))
            +1
            Если у вас развита паранойя, то вы должны понимать, что нет разницы между «нешифрованным /usr» и «нешифрованным /boot».

            Алсо, отдельные пароли на ssh и gpg-ключи и менеджер паролей — must have.
            0
            Вы совершенно не правы. Если вы опасаетесь не только случайного разглашения данных, но и [зло-]умышленного, то вам следует защитить не только домашнюю директорию, но и всю систему, в которую злоумышленник может попытаться установить считыватель клавиатурных нажатий или ещё какой-нибудь зловред.

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

              Мы тут говорим про установку кейлоггера при физическом доступе к устройству, так?
              От удаленной установки через уязвимость описанное в статье шифрование не спасёт.
              А при физическом доступе они поставят физический кейлоггер.
                0
                Бла-бла-бла, сколько раз уже обсуждалось, что все эти пароли на разделы, на вход просто сходят на нет, когда достают паяльник…
                Если действительно возможна ситуация, что к тебе придут и будут тебя трясти, то тебя расколют (если ты конечно не крепкий орех). А если такая ситуация не возможна, то зачем напрягаться к таким сложностям?
              0
              /var/www тоже не хотелось бы потерять) да и бдшки) или у вас всё в /home?)
              • UFO just landed and posted this here
                  0
                  На незашифрованный бук могут еще и подкинуть веществ, ой, я хотел сказать анимэ или порнографии в школьной униформе. Или по мелочи напакостят — пару фоток с «фошыстами» загрузят — так, на административку. Причем их даже распространять не надо, достаточно во время обыска (по любой другой причине) найти их на харде.
                  0
                  > я не использую UEFI
                  Имелось в виду GPT?
                    0
                    Имелось в виду UEFI. Для загрузки с использованием UEFI создаётся отдельный небольшой раздел.
                      0
                      Этот раздел необходим исключительно для GPT разметки. И я бы не рекомендовал его удалять. В сети ходят слухи (сам лично не проверял), что после удаления EFI раздела невозможно зайти в настройки BIOS/UEFI.
                        +1
                        Этот раздел не имеет ничего общего с GPT. Монтируется он в /boot/efi.
                        Что касается слухов — это только слухи. Я уже проверил на своём ноуте.
                          0
                          Я тоже так один раз «проверил» :) Винт вообще пропадает как вариант загрузки из биоса) Клёво было ещё то что на моём N56VZ вообще убрали отключение UEFI, т.е. в принципе ноут превращался в кирпич до перенакатывания oem recovery с DVD носителей.
                            +1
                            Если нет возможности отключить UEFI, грузимся с другого носителя (флешка или cdrom) и возвращаем (создаём заново) раздел и пишем загрузчик. Никаких проблем с этим не вижу. Стандартный установочный образ Slackware вполне UEFI-бутабелен.
                    0
                    Вроде и статью прочитал, но не могу понять, как это работает.
                    Сначала grub загружается из mbr, это ок.
                    Но дальше для расшифровки раздела ему нужно получить initrd, который лежит на этом же зашифрованном разделе.
                    Подскажите, пожалуйста, что я пропустил?
                      +1
                      > Я не особо долго искал, но из того, что попалось под руку, загрузку с шифрованного диска поддерживает только Grub2.

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

                      Далее, Grub загружает ядро и передаёт ему управление. После этого, система так же должна подключить необходимые разделы. В штатном режиме, она так же попросит пароль. Для того, чтобы она не просила пароль, используется luks-ключ, который хранится в initrd.
                      0
                      GRUB_ENABLE_CRYPTODISK=y — правильный вариант.
                        0
                        Правильный, но не всегда работающий.

                        [user@HOST /tmp/grub-2.00] grep -rE '(GRUB_ENABLE_CRYPTODISK|GRUB_CRYPTODISK_ENABLE)' .
                        ./util/grub-install.in:    if [ x$GRUB_CRYPTODISK_ENABLE = xy ]; then
                        ./util/grub-mkconfig.in:  GRUB_ENABLE_CRYPTODISK \
                        ./util/grub-mkconfig_lib.in:  if [ x$GRUB_CRYPTODISK_ENABLE = xy ]; then
                        ./util/grub-mkconfig_lib.in:  if [ x$GRUB_CRYPTODISK_ENABLE = xy ]; then
                        ./ChangeLog:    * util/grub-mkconfig.in: Export GRUB_ENABLE_CRYPTODISK.
                        
                          0
                          Похоже, что GRUB_CRYPTODISK_ENABLE — это внутренняя переменная, используемая для генерации конфигов компиляции.

                          По крайней мере, в грабе Арча GRUB_ENABLE_CRYPTODISK=y.

                          И вот ещё ссылка на всякий случай, тоже полезная:

                          http://www.pavelkogan.com/2014/05/23/luks-full-disk-encryption/
                            0
                            В Slackware, по крайней мере, в моём конкретном случае, ожидаемый результат дало только добавление GRUB_CRYPTODISK_ENABLE

                            > И вот ещё ссылка на всякий случай, тоже полезная:

                            Эта ссылка приведена у меня в источниках:
                            > Full disk encryption with LUKS (including /boot) — Pavel Kogan
                              0
                              Упс, а ссылку проморгал.

                              ОК, добавлю тогда, что для себя именно по ней я всё и настраивал.
                        0
                        фигня всё это и игрушки. лучше бы ктонить рассказал о готовой схеме, чтото типа — гдето в сети лежит зашифрованный файл, который монтируется на моём компе и я работаю с ним как с диском. скорость работы… срать! главное, чтоб оно записывало/читало _В РЕАЛЬНОМ_ времени, а не как яндексдиск — создал мне папку и синхронизирует её с облаком. нахера оно такое нада??? почему сразу не монтировать облако в папку????
                          0
                          NBD (Network Block Device) + LUKS вполне решают эту задачу.
                            0
                            https://github.com/yoe/nbd оно? если да, то опять фигня )) или предлагаете микрософт попросить чтоб на вандрайв сервере нбд запустили? ;) webdav вроде и оно, но нет шифрования нифига (
                              0
                              С webdav можно использовать шифрование на уровне файлов типа encFS.
                            0
                            iSCSI
                              0
                              Блочное устройство — пожалуйста, буквально три строчки. Можно ceph, можно iscsi/nbd для чего попало.

                              С файловой системой сложнее — адекватно-шаренных multitenant FS не существует до сих пор, слишком сложно.
                                0
                                Можно попробовать EncFS. А каталог с зашифрованными файлами монтировать каким-нибудь стандартным способом.
                                  0
                                  TrueCrypt
                                  0
                                  Немалая часть дистрибутивов спрашивает «а не зашифровать ли вам диск?» сразу при установке.

                                    0
                                    И я даже говорил про это:

                                    > На данный момент во многих дистрибутивах уже из коробки предоставляется возможность создавать шифрованные разделы. Однако, все те варианты, что мне попадались, предусматривают не шифрованный /boot.
                                    +1
                                    Я просто оставлю это здесь: https://github.com/hummelchen/notes/blob/master/full_disk_encryption.md
                                      +1
                                      Если этот вопрос стоит остро, почему бы не вынести все нужное для загрузки на флешку? Ведь могут подменить код, который запрашивает пароль, пока вы не рядом с ноутбуком.
                                        0
                                        Флешку могут забрать (не всегда спрашивая согласия), её можно потерять, она может сломаться… а если вопрос стоит на столько остро, чтобы привлечь спецалистов, которые за короткий промежуток времени внедрят в код загрузчика кейлогер, чтобы узнать пароль от люкса то… терморектальный криптоанализ (паяльник, утюг и т.д.) позволяет обойти любые пароли куда дешевле и быстрее.

                                        Единственный способ защитить информацию — сделать затраты на её получение несоразмерными с получаемой выгодой.
                                        0
                                        нужно мнение знающих людей: что скажете о программе DiskCryptor, как способе зашифровать винт с виндовсом на борту? (хорошо/плохо/альтернативы)

                                        Спасибо
                                          0
                                          Diskcryptor умеет грузиться с флешки, храня там же ключ (удобно — загрузил машину с флешки, унёс до ребута, никаких паролей). Может грузить левую ОС (пароль под принуждением).

                                          По теме топика —
                                          Вообще, сейчас многие, скажем, SSD (Intel/Samsung) имеют AES шифрование на уровне диска. Что мешает воспользоваться им?
                                            0
                                            видимо то, что о таком не слышал. Для этого какая то софтина фирменная нужна будет?
                                              0
                                              Включается установкой пароля в CMOS Setup для защиты диска. Не путаем с паролем на вход в сам CMOS setup («BIOS»).
                                              0
                                              Обоснованные сомнения в отсутствии вполне легального «чёрного хода» для «людей в чёрном»? Тоже «на уровне диска».
                                                0
                                                Поэтому изначально и спрашиваю за софтину, которая вроде как свободная и с открытым исходным кодом)
                                                  0
                                                  Я бы посоветовал VeraCrypt.

                                                  DiskCryptor (как и TrueCrypt) не зашифруют вам системный раздел с операционной системой на диске с GPT-разметкой (только с MBR). А вот следующая версия VeraCrypt — сможет (сейчас эта функция обкатывается в тестовых выпусках).
                                                    0
                                                    Надо будет потестить. Спасибо! :)
                                            +1

                                            Если ли возможность задать т. н. «пароль под принуждением», с загрузкой совершенно другой системы? Если нет, то и смысла возиться нет — вежливо попросят, сами пароль введете.

                                              0
                                              Возможность есть, но имеются ньюансы. Обсуждения на тему plausible deniability в LUKS можно почитать например здесь.
                                                0
                                                Самая, на мой взгляд, большая трудность с «загрузкой совершенно другой системы» заключается в том, что вам придётся этой «подложной» системой регулярно пользоваться, чтобы создать впечатление, что это и есть основная система. Иначе, у товарища майора к вам возникнет совершенно закономерный вопрос, отчего она у вас последний раз запускалась месяц или неделю назад, когда есть свидетельства того, что вы активно пользуетесь ПК.

                                                То есть, придётся каждый день её запускать, сёрфить из неё и так далее.
                                                  0
                                                  Кажется, это уже совершенно иная тема. Я описал вариант защиты данных на переносной системе, которую можно «потерять» и при этом, желательно не допустить возможности того, что кто-то воспользуется этими данными.

                                                  Вопросы сокрытия хостовой или основной системы — тема абсолютно другая и подобные задачи решаются абсолютно иными средствами. Для решения подобных задач, правда, с серьёзной потерей производительности, как мне кажется, могла бы подойти VMware ESX(i?)… особенно, если её удастся скрестить с тем же LUKS-ом. Но данной темой я не занимался и потому, не могу сказать чего-либо конкретного.

                                              Only users with full accounts can post comments. Log in, please.