Должен ли я использовать LUKS1 или LUKS2 для шифрования разделов?

В процессе настройки шифрования LUKS на моем разделе Ubuntu я наткнулся на параметр --type luks2 на страницах справочника по cryptsetup. Из того, что я прочитал, нет никаких причин не использовать LUKS2, но cryptsetup по-прежнему использует LUKS1 по умолчанию.

По какой причине я не должен использовать LUKS2?

Спасибо.

5
задан 6 May 2018 в 00:32

4 ответа

Согласно официальному проекту для документации:

LUKS2 является второй версией Linux Объединенная Ключевая Установка для диска encryp-tion управление. Это - продолжение LUKS1 [1, 2] формат, который расширяет возможности дискового формата и удаляет некоторые известные проблемы и lim - itations. Большинство фундаментальных понятий LUKS1 остается на месте, как разработано в Новых Методах в Шифровании Жесткого диска 2 Clemens Fruhwirth. LUKS предоставляет универсальную базу ключей на специализированной области на диске со способностью использовать несколько паролей 1 для разблокирования сохраненного ключа. LUKS2 расширяет это понятие для более гибких способов сохранить метаданные, избыточная информация для обеспечения восстановления в случае повреждения в области метаданных и интерфейса для хранения внешне управляемых метаданных для интеграции с другими инструментами. В то время как реализация LUKS2 предназначается, чтобы использоваться с основанным на Linux dm-склепом 3 шифрования диска, это - универсальный формат

В основном, хотя это уже доступно, это - вполне происходящий работой формат по стандартам пользователя/определения. Далее цитируя cryptsetup официальную информацию о версии для 2.0.0 версий, едва 6 месяцев назад (шахта акцента):

Cryptsetup 2.0.0 информации о версии

Стабильная версия с экспериментальными функциями.

Эта версия представляет новый дисковый формат LUKS2.

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

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

Обратите внимание на то, что аутентифицируемое шифрование диска, некриптографическая защита целостности данных (dm-целостность), использование Основанной на пароле Ключевой Функции Деривации Argon2 и самого дискового формата LUKS2 являются новыми возможностями и могут содержать некоторые ошибки.

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

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

Так, если Вам не нужна одна из новых возможностей, Ваша лучшая и самая безопасная опция шла бы с LUKS1 по умолчанию/стабильным. С другой стороны, если Вы не возражаете против небольшого количества тестирования или проблем с установкой, можно пойти с опцией LUKS2 и сообщить о любых проблемах, которые Вы находите к cryptsetup системе отслеживания ошибок.

4
ответ дан 23 November 2019 в 09:20
  1. GRUB еще не поддерживает LUKS2. Если Ваш каталог начальной загрузки / будет на LUKS-шифруемом-устройстве, и Вы используете GRUB в качестве своего загрузчика, то это не будет работать.
  2. [деталь] Более старый cryptsetup (1.x.y) не может обработать LUKS2, так Живой CD/USBs с версией cryptsetup прежде 2, не может использоваться для дешифрования разделов LUKS2.
1
ответ дан 23 November 2019 в 09:20

По состоянию на 10 января 2020 года GRUB поддерживает LUKS2 , поэтому, если вы используете GRUB для разблокировки раздела / boot или зашифрованного диска, GRUB поможет вам. Что касается функций, см. ответ Льва

4
ответ дан 22 January 2020 в 16:08

По возможности обязательно используйте LUKS2. Это более новый формат заголовка, который преодолевает ограничения (устаревшего) заголовка LUKS1. Это значение по умолчанию, начиная с cryptsetup версии 2.1, но само по себе это мало что говорит. Функция получения ключа на основе пароля (PBKDF) — это большое изменение.

Если вы используете алгоритм PBKDF2, не имеет большого значения, какой у вас заголовок: LUKS1 или LUKS2 (даже несмотря на то, что LUKS2 более устойчив, так как имеет резервную копию важных данных). Более новые алгоритмы Argon2i или Argon2id, представленные в cryptsetup версии 2.0, занимают больше места, поэтому Argon2 не помещается в меньший заголовок LUKS1.

Кроме того, Argon2, поскольку это более новый алгоритм, вероятно, даже безопаснее, чем PBKDF2, но это происходит за счет большего потребления памяти (ОЗУ), а также требует наличия заголовка LUKS2.

Из справочной страницы cryptsetup.8:

Для PBKDF2 применяется только стоимость времени (количество итераций). Для Argon2i/id есть также стоимость памяти (память, необходимая в процессе создания ключа) и параллельная стоимость (количество потоков, которые выполняются параллельно во время создания ключа).

Поскольку cryptsetup 2.1 по умолчанию использует более крупный заголовок LUKS2, по умолчанию также используется Argon2i вместо PBKDF2.Недавно я вручную создал раздел LUKS в своем Debian Linux, текущая стабильная версия 10.4 (на момент написания этой статьи; возможно, это было 10.2 или 10.3, когда я создавал раздел LUKS), и для него был установлен LUKS2 с Argon2i.

Проблема в том, что GRUB2 не поддерживает LUKS2 в большинстве дистрибутивов (на момент написания этой статьи), поэтому установка по умолчанию все равно будет (должна) использовать LUKS1 по умолчанию, по крайней мере, если затрагивается /boot, иначе он не сможет загрузиться. Существует это руководство о том, как правильно это сделать в Debian 10 "Buster". Ubuntu изначально основан на Debian, поэтому он может быть похожим. Хитрость заключается в том, чтобы иметь отдельный раздел LUKS с отдельным разделом /boot и преобразовать этот раздел обратно в LUKS1, чтобы GRUB2 мог найти ядро ​​Linux и initramfs. В качестве альтернативы корневой раздел, если он содержит /boot и является LUKS2, может быть полностью преобразован обратно в LUKS1. В обоих случаях рекомендуется добавить ключевой файл для одного дополнительного слота ключей LUKS и скопировать этот ключевой файл в initramfs (или настроить initramfs для поиска ключевого файла). GRUB2 запросит пароль для /boot, но при загрузке ядра и initramfs пароль нужно будет вводить снова — это тот же пароль для того же раздела, если /boot находится в корневом разделе (или другой пароль). для /, если он отличается от раздела /boot). Этого можно избежать, если initramfs использует ключевой файл, который в любом случае безопасно хранится в зашифрованном каталоге /boot.

Также следует отметить: в январе 2020 года GRUB2 получил патч и теперь может обрабатывать заголовки LUKS2, но только с устаревшим алгоритмом PBKDF2.Здесь есть две проблемы. Во-первых, требуется время, пока такой патч выйдет в релизную версию, и еще больше времени, пока он будет распространен. Debian 10.4 (стабильная ветвь), например, имеет более старую версию GRUB2, которая не может обрабатывать LUKS2. А во-вторых, Argon2 не поддерживается GRUB2 даже с упомянутым исходным LUKS2-патчем.

Если вы создадите раздел LUKS2 /boot, велика вероятность, что по умолчанию он будет Argon2i. Для /boot вам нужно будет указать --pbkdf pbkdf2 при создании нового слота ключей для GRUB2 (с патчем LUKS2), чтобы это работало.

cryptsetup luksAddKey --pbkdf pbkdf2 /dev/

Я настоятельно рекомендую прочитать страницы Arch Wiki для получения дополнительной информации о том, как работать с томами cryptsetup и LUKS.

7
ответ дан 15 July 2020 в 21:08

Другие вопросы по тегам:

Похожие вопросы: