1.2, pavlinux (ok), 12:32, 27/12/2020 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
То есть, если спи...т диск, то ключик уже в комплекте?
/etc/cryptsetup-keys.d/luks-<UUID>.key
| |
|
2.3, Аноним (3), 23:12, 27/12/2020 [^] [^^] [^^^] [ответить]
| +1 +/– |
Видимо /etc/cryptsetup-keys.d должен быть симлинком на юсб-флешку, а еще лучше примонтированным сетевым устройством :)
| |
|
3.14, ОхотникНаОленей (?), 04:04, 10/01/2021 [^] [^^] [^^^] [ответить]
| +/– |
Это вообще видимо не для сокрытия данных, а скорее для контроля целостности загружаемого образа или я не понял нафига козе баян.
| |
|
2.9, Аноним (9), 16:11, 02/01/2021 [^] [^^] [^^^] [ответить]
| +/– |
угу, в комплекте. Лежит на зашифрованном разделе внутри образа. Без прав рута в работающей виртуалке доступ к нему получить затруднительно.
ключик нужен чтобы запихнуть его в initrd и пароль дважды не вводить. Можно /boot сделать отдельным, а в initrd запихнуть dropbear, тогда разлочивать можно будет по ссх. Правда если совсем параноить, то надо проверять, что незашифрованная часть не менялась.
| |
|
|
2.6, Аноним (-), 14:04, 28/12/2020 [^] [^^] [^^^] [ответить]
| +1 +/– |
Насколько я понял, luks2 отличается от luks1 новым форматом заголовка (header).
Так, слоты для ключей (keyslot) переведены в json формат, и убрано ограничение на их количество (в luks1 не более 7, в luks2 по умолчанию 32).
Также добавлены новые алгоритмы (Argon2i и Argon2id) кодирования парольной фразы (passphrase | keyfile) основной смысл которых - повысить время перебора (bruteforce) для атакующей стороны.
В заголовке теперь хранится резервная копия слотов.
Из-за этого размер заголовка увеличился с 2 до 16 MiB, и теперь имеет плавающий (в большую сторону) размер.
В плане шифрования данных они идентичны.
Вот тут некоторые подробности:
gitlab.com/cryptsetup/cryptsetup/-/wikis/FrequentlyAskedQuestions
| |
|
3.11, Аноним (11), 05:18, 05/01/2021 [^] [^^] [^^^] [ответить]
| +/– |
Чуть менее очевидная разница в том, что на данный момент многим программам, например grub2, о luks2 известно менее, чем о luks1, как следствие не все фишки работающие с первым можно повторить со вторым. Например, шифрованный /boot.
| |
|
|
1.5, Аноним (5), 13:33, 28/12/2020 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
Автор забыл во вводной части указать кейсы его подхода с общим описанием идеи, а вычленять это из простыни не охота.
Для страждущих рекомендую эту серию материалов: wiki.archlinux.org/index.php/dm-crypt
зы
в простыне виднеется ошибка для /etc/crypttab:
cr_root UUID=<uuid> luks none
последние два слова нужно поменять местами.
| |
|
2.10, XoRe (ok), 23:15, 02/01/2021 [^] [^^] [^^^] [ответить]
| +/– |
Представьте, что у вас 23 личности. И каждая хочет себе зашифрованную виртуалку...
| |
|
1.12, Pavel Piatruk (?), 06:29, 06/01/2021 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
отличная статья, но много осталось за кадром -- например, внедрение ключа в initrd для centos. Я уже написал альтернативный скрипт, для более бездумного копипастинга. На выходе VMDK для загрузки шифрованной VM в режиме UEFI. Протестировано в vmware.
| |
1.13, Pavel Piatruk (?), 06:32, 06/01/2021 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
P.S. Интересно, присутствует ли угроза подмены EFI файлов ( они на незашифрованном разделе ) и установки keylogger'a? Или там все подписано и их нет смысла менять?
| |
1.15, alexk (??), 05:23, 14/01/2021 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
А нахрена все это? Установщики перестали поддерживать шифрование при установке?
| |
|