Comments 20
Я выбрал XFS, но это далеко не единственный вариант
и не самый лучший для флешки я бы сказал
xfs проще поломать внезапным отключением чем какую нибудь банальную ext*, а вообще для флешек специально вроде была какая-то фс, f2fs или типо того
Насколько я знаю, F2FS (и например NILFS2) предназначены для тех флешек, где нет FTL и wear levelling'а. Для обычных флешек и SSD, которые корчат из себя блочное устройство, нужды в них нет. XFS вроде как может потерять данные (в файлах), но не метаданные (целостность файловой системы не нарушится), т.к. журналирует только метаданные. Можно взять например BTRFS, где обеспечивается атомарность вообще всего, причём не журналом, а CoW, излишняя фрагментация при этом не роляет (т.к. речь про флешку или SSD). Бонусом будет упаковка записываемых данных на лету, что немного ускоряет чтения и записи на медленных устройствах.
Проблема с шифроваными томами еще и в том, что вводя пароль в консоли его можно оставить в истории shell. Да, в рамках вектора атак и рисков для статьи это не важно, но стоит помнить об истории консоли, и, для bash, вводить команду с пробелом в начале строки (как пример).
Вообще, более правильно, в добавок к парольной аутентификации, добавить авторизацию по файлу ключа. Который держать на отдельной флешке.
Верное замечание, только оно налогает дополнительные требования на наличие дубликата ключа и его безопасное хранение.
Я бы лучше рекомендовал посмотреть на вариант OTP в виде кодогенератора. Правда, я не помню точно есть ли такой функционал у LUKS без привязки к специфическим аппаратным токенам.
Судя по ману cryptsetup, из коробки он такого не умеет. Но есть вот такая фиговина.
Ок, вы можете изменить время и заснепшотить — как вы угадаете криптоключ если генерация идет через него? Ок, можно генерировать коды используя еще один код, который я должен вводить в приложение и плюсом я должен прочитать код, сгененрированый ОТП на машине. Т.е. мы имеем вопрос и поле для ответа, где ответ нужно сгенерировать с использованием вопроса и моего пароля...
а для расшифровывания нужен сам ключ, так такого функционала в LUKS нет и не предвидится
vaultdrive из команды в статье не пароль, а имя будущего блочного устройства (хотя пароль мог быть таким же)
вводя пароль в консоли его можно оставить в истории shell
Ничего подобного. В тексте данной статьи действительно есть такие слова, сбивающие с толку:
$ cryptsetup open /dev/sdX vaultdrive
Я придумал фразу (а точнее, просто пароль в одно слово) «vaultdrive».
Но в данном контексте "vaultdrive" — это не пароль (возможно автор статьи и использовал такой пароль, но это осталось за кадром). Это просто имя, которое будет задано для виртуального дешифрованного устройства в папке /dev/mapper/.
Пароль будет запрошен во время выполнения программы и в историю bash не попадет.
Какие инструменты используете для аналогичных задач на macOS и Windows?На Windows — однозначно Veracrypt. Под Linux его тоже можно применять для файл-контейнеров или внешних дисков, только не для шифрования системы.
Автор, почемы ты не расказываешь про процедуру расшифровки дисков?
Если время сильно ограничено, злодеи действительно могут украсть накопитель и взять работу на дом. Особенно легко это им удаётся, если он внешний и подключён через USB.
Не особенно легко: внешний накопитель может быть заперт в сейф, а сейф м.б. на сигнализации. Сейфов м.б. 2 или больше, и нужно прежде угадать, какой ломать. Но LUKS, конечно, и при сейфах полезен.
После этого появится предупреждение об удалении всех данных (которые могли всё ещё оставаться на диске).
На самом деле luksFormat предыдущие данные не стирает. Она перезаписывает суперблок (где например хранятся ключи для шифрования секторов диска, которые при последущем luksOpen будут расшифрованы вашим паролём). Если диск ранее был под LUKS, то перезапись этих ключей конечно сделает всю инфу недоступной, т.к. она будет расшифровываться в рандом. Однако, если до luksFormat диск не был зашифрован, то за исключением суперблока вся остальная инфа на нём останется и лишь будет перезаписываться по мере записи на зашифрованный диск.
Чтобы такого не происходило, можно делать так: dd if=/dev/urandom of=/dev/sdX до luksFormat. /dev/zero тут использовать нежелательно, т.к. потом будет видно, куда зашифрованные данные на диск уже писались (рандомная каша), а куда нет (нули). Ещё можно сделать dd if=/dev/zero of=/dev/mapper/name на уже открытый шифрованный раздел, при шифровании нули превратятся в кашу (т.к. каждый сектор шифруется по-своему).
Linux Unified Key Setup: как защитить флэшки и внешние диски от взлома