The OpenNET Project / Index page

[ новости /+++ | форум | wiki | теги | ]



"Раздел полезных советов: Перевод шифрованного раздела на LUKS2 и более надёжную функцию формирования ключа"
Вариант для распечатки  
Пред. тема | След. тема 
Форум Разговоры, обсуждение новостей
Изначальное сообщение [ Отслеживать ]

"Раздел полезных советов: Перевод шифрованного раздела на LUKS2 и более надёжную функцию формирования ключа"  +/
Сообщение от auto_tips (??), 19-Апр-23, 06:23 
В шифрованных разделах LUKS1 в качестве функции формирования ключа (KDF, Key Derivation Function) на основе заданного пользователем пароля применяется функция PBKDF2, не обеспечивающая должную стойкость от подбора с использованием GPU. В LUKS2 в качестве KDF появилась возможность использования гибридной хэш-функции [[https://en.wikipedia.org/wiki/Argon2 argon2id]], которая помимо потребления вычислительных ресурсов, затрудняет распараллеливание и требует значительного объёма памяти.

Например, подбор KDF-функции PBKDF2, рассчитанной на потребление CPU,  может эффективно распараллеливаться на GPU Geforce 4090 c 16384 вычислительными блоками, но в случае применения argon2id подбор упирается в размер видеопамяти (при потреблении 1 ГБ на каждую операцию подбора, на GPU с 24 ГБ памяти можно обеспечить лишь подбор в 24 параллельных потока).

Переключение с LUKS1 на LUKS2 с  argon2id.

Определяем на каком устройстве находится шифрованный раздел:

   lsblk

   ...
   └─nvme0n1p3    259:3    0 474,8G  0 part  
     └─nvme0n1p3_crypt
                  253:0    0 474,8G  0 crypt
       ├─vgubuntu--mate-root
       │          253:1    0 473,8G  0 lvm   /var/snap/firefox/common/host-hunspell
       │                                     /
       └─vgubuntu--mate-swap_1
                  253:2    0   980M  0 lvm   [SWAP]

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

   sudo cryptsetup luksHeaderBackup /dev/nvme0n1p3 --header-backup-file /tmp/luksheader


Проверяем версию LUKS:

   sudo cryptsetup luksDump /dev/nvme0n1p3

   ...
   Version:    1
   ...
   PBKDF:      pbkdf2

Если версия 1, то необходимо обновить заголовок до LUKS2.

   sudo cryptsetup convert /dev/nvme0n1p3 --type luks2

Проверяем, что с новым заголовком система по-прежнему грузится и если возникли проблемы восстанавливаем старый заголовок командой

   sudo cryptsetup luksHeaderRestore /dev/nvme0n1p3 --header-backup-file путь_к_скопированному_luksheader

Ещё раз выполняем cryptsetup luksDump и проверяем алгоритм в секции Keyslots, если указано "pbkdf2" или "argon2i" следует обновить его до
"argon2id":

   sudo cryptsetup luksConvertKey /dev/nvme0n1p3 --pbkdf argon2id

Проверяем рузельтат:

   sudo cryptsetup luksDump /dev/nvme0n1p3

   ...
   Version:           2
   ...
   Keyslots:
     0: luks2
        ...
        PBKDF:      argon2id
        ...

    0: luks2
        ...
        PBKDF:      argon2id
        ...


URL: https://mjg59.dreamwidth.org/66429.html
Обсуждается: https://www.opennet.ru/tips/info/3220.shtml

Ответить | Правка | Cообщить модератору

Оглавление

Сообщения [Сортировка по времени | RSS]


2. "Перевод шифрованного раздела на LUKS2 и более надёжную функцию формирования ключа"  +1 +/
Сообщение от Kuromi (ok), 21-Апр-23, 17:51 
Для справки - GRUB его вроде как не поддерживает пока.
Так во всяком случае тут говорят - https://lwn.net/Articles/929343/
Ответить | Правка | Наверх | Cообщить модератору

3. "Перевод шифрованного раздела на LUKS2 и более надёжную функцию формирования ключа"  +2 +/
Сообщение от фф (?), 24-Апр-23, 16:37 
я правильно понимаю - если у меня на компе меньше гига оперативки, то я не смогу расшифровать раздел даже если знаю правильный пароль?
Ответить | Правка | Наверх | Cообщить модератору

4. "Перевод шифрованного раздела на LUKS2 и более надёжную функцию формирования ключа"  +1 +/
Сообщение от ivan_erohin (?), 27-Апр-23, 12:05 
> PBKDF2, не обеспечивающая должную стойкость от подбора с использованием

GPU.

ого ! неужели я смогу расшифровать то, что зашифровал 10 лет назад (и благополучно забыл пассфразу) ?

Ответить | Правка | Наверх | Cообщить модератору

5. "Перевод шифрованного раздела на LUKS2 и более надёжную функцию формирования ключа"  –1 +/
Сообщение от Ivan (??), 27-Апр-23, 12:16 
А не лучше ли использовать встроенную шифрацию диска nvme? Многие модели ее поддерживают.
Проц вообще грузить не будет...
Ответить | Правка | Наверх | Cообщить модератору

6. Скрыто модератором  +/
Сообщение от ivan_erohin (?), 28-Апр-23, 06:03 
Ответить | Правка | Наверх | Cообщить модератору

7. "Перевод шифрованного раздела на LUKS2 и более надёжную функцию формирования ключа"  +/
Сообщение от Ivan (??), 28-Апр-23, 10:11 
Почему? Шифрует ведь диск, а не мать
Ответить | Правка | К родителю #5 | Наверх | Cообщить модератору

8. "Перевод шифрованного раздела на LUKS2 и более надёжную функцию формирования ключа"  –1 +/
Сообщение от Neon (??), 04-Май-23, 12:53 
И у производителя диска лежит любовно спрятанный бэкдор для дешифрации.
Ответить | Правка | К родителю #5 | Наверх | Cообщить модератору

13. "Перевод шифрованного раздела на LUKS2 и более надёжную функцию формирования ключа"  +1 +/
Сообщение от Аноним (13), 20-Май-23, 09:34 
если даже так, то кому попало он его не даст, максимум тамошним спецслужбам с наличием ордера, так что нам здесь беспокоится не о чем.
Ответить | Правка | Наверх | Cообщить модератору

10. "Перевод шифрованного раздела на LUKS2 и более надёжную функцию формирования ключа"  +1 +/
Сообщение от Аноним (10), 06-Май-23, 21:55 
Код прошивки накопителя открыт? Нет? Ну, тогда, извини, может там дыры эпических масштабов. Как было у Crucial, где данные были зашифрованы ключом, а ключ лежал ничем не защищенный. Обычно ключ шифруется паролем пользователя, чтобы, не зная пароля, невозможно было расшифровать ключ шифрования и данные. Но парни из Crucial решили сделать по-своему: пользователь вводил пароль, прошивка сравнивала хэш пароля с сохраненным хэшем. При совпадении прошивка брала незашифрованный ключ и им расшифровывала данные.

Атакующий мог подцепиться физически, вычитать ключ из флеша и привет.

Наслаждайтесь вашим проприетарным шифрованием.

Ответить | Правка | К родителю #5 | Наверх | Cообщить модератору

11. "Перевод шифрованного раздела на LUKS2 и более надёжную функцию формирования ключа"  +/
Сообщение от Qq (?), 10-Май-23, 18:22 
Защита от разных моделей угроз. Есть накопители имеющие дефолтное шифрование, что бы ты туда не писал - хранится оно зашифрованным, но для доступа к данным никакой пароль не нужен, вернее его знает контроллер и по умолчанию даёт доступ (может даже не разрешать пользователю установить свой пароль для включения, это не всегда один и тот же что и для шифрования). Команды типа «secure erase» в этом случае просто убивают ключ превращая данные в труху мгновенно. Кстати, это так же используют как ещё один уровень wear leveling.

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

Ответить | Правка | К родителю #5 | Наверх | Cообщить модератору

12. "Перевод шифрованного раздела на LUKS2 и более надёжную функцию формирования ключа"  +/
Сообщение от Аноним (12), 15-Май-23, 15:38 
> Защита от разных моделей угроз

Если ваши угрозы - это кто-то хочет включить ваш компьютер без спроса, то можно диск и не шифровать вообще. Шифрование диска подразумевает, что 1) никто, кроме обладателя ключа, не может прочитать данные на диске (и тут можно пойти по пути шифрования всего диска, только раздела или заюзать ФС с шифрованием, но имхо первые два варианта проще); 2) никто не может поменять содержимое диска так, чтобы это было незамечено (хотя для полной защиты от этого нужно таскать метаданные и бутлоадер на отдельном носителе, но это неудобно в случае с системным диском, поэтому и так сойдёт).
Так же желательно, чтобы данные не были намертво прибиты к носителю, на котором они находятся, а значит хардварное шифрование с ключом, который нужно выковыривать паяльником - это защита от самого себя, а не от того, кто ваш диск *уже* украл. Плюс доверие к любой компании в том, что она будет заботится о вашей приватности, равно нулю: либо так было дешевле, либо защита детей™. Ну и баги никто не отменял. Помните недавный прикол с андроидами (вроде только на пикселях определённой версии, но что-то мне подсказывает дело не в конкретном телефоне), когда чтобы расшифровать накопитель всё что понадобилось - это воткнуть в телефон симку с заранее известным PUK-кодом, ввести его и вуа-ля - телефон каким-то образом без вашего личного секрета всё сам расшифровал (скорее всего что-то похожее как и с Crucial, про который писал Аноним выше, только тут достаточно было чипу, хронящему ключ, сказать "ок" и он побежал расшифровывать раздел, без паролей, без ничего).

Ответить | Правка | Наверх | Cообщить модератору

14. "Перевод шифрованного раздела на LUKS2 и более надёжную функцию формирования ключа"  +/
Сообщение от px (??), 07-Июн-23, 15:22 
Ключ в открытом виде пересылается через интерфейс и его, теоретически, можно физически сдампить
Ответить | Правка | К родителю #5 | Наверх | Cообщить модератору

9. "Перевод шифрованного раздела на LUKS2 и более надёжную функцию формирования ключа"  +/
Сообщение от Аноним (9), 06-Май-23, 14:54 
> Перевод шифрованного раздела на LUKS2 и более надёжную функцию формирования ключа

Чтобы кому положено могли более надёжно тырить данные: https://www.opennet.ru/opennews/art.shtml?num=56513

Ответить | Правка | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




Спонсоры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2023 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру