☰

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

tag-icon • tag-icon security encryption dm-crypt ecryptfs
Как получить пригодное для использования полное шифрование диска с разными шифрованиями для разных пользователей

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

  • весь жесткий диск зашифрован
  • когда пользователь 1 вошел в систему, а пользователь 2 нет, данные пользователя 2 шифруются для пользователя 1 и наоборот
  • Мне нужно ввести один пароль при загрузке, который расшифрует систему (как в обычной настройке LVM/dm-crypt), и только второй, который войдет в систему пользователя x и расшифрует его раздел.
  • производительность аналогична простому полному шифрованию диска
  • решение должно работать вместе с SSD, т.е. оно должно поддерживать TRIM

Я хочу использовать Ubuntu в качестве дистрибутива, если это имеет значение.

решение1

  1. Не шифруйте весь жесткий диск (например /dev/sda, делайте это для каждого раздела (или, точнее, для каждой файловой системы — см. ниже).

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

  3. Автоматическое монтирование при входе в систему возможно через PAM. Обратите внимание, что вы не хотите использовать один и тот же пароль для входа в систему и для фактическогошифрование данных. Вместо этого вы либо используете LUKS, либо имитируете его, сохраняя ключ шифрования в файле, который сам зашифрован паролем входа. Это гарантирует, что изменение пароля входа не повлияет на зашифрованные данные, а только на зашифрованный ключ, и, таким образом, вам не придется заботиться о повторном шифровании всего пользователя (home).

Основные инструкции:

  • использование разбиения на разделы gdisk(также известное как gptfdisksometimes) partedили любой другой подходящей программы, подробности читайте на страницах руководства (разбиение на разделы немного выходит за рамки этого QA)

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

    1. подготовьте ключ шифрования и пароль. Это интересная часть — для шифрования данных вам нужно что-то с достаточной случайностью (пароль из 8 букв на самом деле недостаточно), а для пароля — что-то, что вы можете легко изменить (без необходимости перешифровывать всю файловую систему) и что достаточно легко запомнить и ввести. Эти требования довольно противоречивы. Поэтому мы воспользуемся тем же трюком, что и LUKS (и который на самом деле можно считать вариациейгибридная криптосистемав каком-то смысле)).ключ шифрованияможет быть более или менее случайным — либо используйте действительно случайные данные (например, из /dev/random), либо достаточно длинный хеш, такой как SHA-2 или SHA-3 (первый был разработан АНБ, если вы сомневаетесь, использовать его или нет в свете последних событий) достаточно длинной парольной фразы.

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

      # set up the encrypted encryption key
printf "Reasonably long and complicated passphrase" \
    | openssl dgst -sha512 -binary \
    | openssl enc -bf > /path/to/key.enc

      openssl dgst -sha512 -binaryсоздает двоичную форму хеша SHA-512 из стандартного ввода, openssl enc -bfшифрует его с помощьюРыба-иглу- можете свободно выбирать хэш и шифр по своему вкусу (Twofish или Rijndael оба достаточно хорошо зарекомендовали себя, но другие шифры, доступные в ядре, тоже должны подойти).

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

      С другой стороны, с отдельным файлом вы вольны выбрать любой способ хранения ключа. Вы даже можете поместить его на съемный носитель, вставить его перед входом в систему и удалить его после монтирования файловой системы (вероятно, вы даже можете привязать автоматический вход к событию присоединения носителя к компьютеру). Конечно, все это должно быть хорошо продумано, поскольку максима безопасности«Не изобретайте свою собственную криптовалюту»применяется (см. напримерэтот пост на Security SE) - что на самом деле может быть аргументом в пользу использования LUKS. Резервное копирование ключа, очевидно, легко.

    2. создайте пустой файл, который будет содержать файловую систему

      dd if=/dev/zero of=/path/to/backing_file.enc bs=1M count=X

    3. создать зашифрованное устройство

      openssl enc -bf -d -in /path/to/key.enc 2>/dev/null \
    | cryptsetup create \
            -c twofish-cbc-essiv:sha256 \
            -s 256 \
            -h plain \
            encryptedfs /path/to/backing_file.enc

      openssl enc -bf -dзапрашивает пароль на stdin и пытается расшифровать ключ шифрования. cryptsetup create ... encryptedfs /path/to/backing_file.encсоздано зашифрованное устройство DM, вызываемое encryptedfsс поддержкой ранее созданного файла. Важная опция, -cкоторая выбирает шифр шифрованияиего режим работы

    4. заполнить устройство нулями — это фактически помещает «случайный мусор» в резервный файл и делает менее очевидным, каким может быть содержимое файла (в противном случае вы могли бы определить, куда что было записано, просканировав блоки, которые не были обнулены на шаге 2).

      dd if=/dev/zero of=/dev/mapper/encryptedfs bs=1M

    5. Создать файловую систему

      mkfs.[favourite_filesystem] [tuning options] /dev/mapper/encryptedfs

    6. Введите соответствующую строку в , /etc/fstabесли вы хотите сделать все самостоятельно, или в/etc/crypttabесли вам нужна какая-то интеграция с системными инструментами.

  • для автоматического (де)монтирования при входе/выходе из системы я отсылаю вас кдокументация pam_mount.

решение2

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

  • отдельный домашний раздел:создать отдельный раздел, который монтируется в /home. Затем каждый пользователь шифрует свой дом через encfs.
  • отдельный домашний раздел для каждого пользователя:Каждый пользователь получает отдельный раздел для своего дома, который сам по себе зашифрован с помощью dm-crypt. Этот раздел затем монтируется, /home/userкогда он входит в систему.

Конечно, плюс шифрование /;-)

В обоих случаях дома могут быть автоматически смонтированы во время процесса входа в систему, если вы используете один и тот же пароль для входа в систему и шифрования. (можно настроить, например /etc/security/pam_mount.conf.xml, есть много инструкций) В то время как первый метод не шифрует имена папок ваших пользователей, при использовании второго метода действительно шифруется все. Поэтому я бы предпочел (и фактически использую) метод два ;-)

Связанный контент