РегистрацияШифрование дискет
Похоже что для шифрования дискет LUKS не подходит, т.к. его заголовок больше доступного дискового пространства 1.44 МБ. cryptsetup luksFormat работает без предупреждений, но luksOpen выдаёт сообщение о нехватке места. Можно ли уменьшить размер заголовка? Среди штатных опций такой возможности не обнаружил.
Если LUKS не подходит, какие другие варианты лучше соответствуют – EncFS, ecryptfs, loop-aes? В идеале безсигнатурное шифрование, хотя сомневаюсь что существует удобное решение, поэтому такое условие не обязательно.
комментариев: 511 документов: 2 редакций: 70
Идея проста и понятна: LUKS-том состоит из заголовка и данных. Заголовок можно бессигнатурно (plain mode) зашифровать тем же самым паролем, что и сам LUKS, тогда сигнатур не будет вообще. При смене пароля нужно будет расшифровать заголовок, поменять LUKS-ключ в слотах на новый, а потом им же (т.е. тем же паролем) перешифровать заголовок LUKS'а (затереть, потом из бэкапа восстановить правильный заголовок, но уже на новый пароль в бессигнатурном шифровании). Этим достигается решение задачи, где есть всё:
Минус в том, что
Все эти затеи могут оказаться ненужными, потому что проще хранить заголовок LUKS'а в каком-то третьем устройстве в файле, тогда бессигнатурность будет иметься изначально и штатно, а подключаться такие тома будут одной простой командой.
комментариев: 511 документов: 2 редакций: 70
На каком-то уровне протестированный пример:
Всему виной, как всегда, баги:
В версии 1.6.6 ненужный оффсет можно удалить таким хаком:
Не самый тривиальный момент (и плохо описанный в документации) — то, что аргументом luksFormat является внешнее устройство (или файл) для хидера, а не то целевое блочное устройство, которое мы будем шифровать. Последнее вообще в этом случае не указывается в luksFormat-команде. Т.е. luksFormat создаёт только заголовок LUKS'а на чём-то (по сути — метод выведения мастер-ключа), а потом этот заголовок можно будет применять к любому блочному устройству для его шифрования. Т.е. не нужно писать --header {устройство,файл} в luksFormat-команде. man cryptsetup:
Первая фраза противоречит второй. Т.е. нет такой опции --header у luksFormat — это будет ошибкой синтаксиса, если указать.
Общие замечания:
P.S. Ещё одна полезная заметка на тему внешних хидеров.
комментариев: 511 документов: 2 редакций: 70
Ввиду предыдущего комментария мотивация вполне ясна. Более-менее рабочие оттестированные варианты (применение — на свой страх и риск):
Количество слотов «кустарного LUKS'а» сейчас 8, это заголовок размером 4KB (у аутентичного LUKS — 4k секторов, т.е. 2 MB), но можно поставить один или два, тогда оверхед будет, соответственно, 0.5KB или 1KB. Правда, при этом mkfs.ext4 будет ругаться на выравнивание и грозиться проблемами со скоростью работы:
чего нет при 8-ми слотах.
Открытие устройства — по сути, три команды, не требующие каких-то вычисляемых переменных, как в примере с LUKS, т.е. их легко ввести без скрипта вручную. Что ещё хорошо — для plain mode поддерживается --shared, которым не воспользоваться c LUKS (поэтому там понадобилась дополнительная команда — хак с отображением пространства с помощью dmsetup).
Для удобной смены пассфразы нужно минимум 2 слота. Пример с добавлением второго слота выше приведён (смысл понятен), но закомменчен. Т.е. расшированное содержимое всех использованных слотов-секторов одинаково (оно и есть мастер-ключ), но они зашифрованы разными пассфразами. Может возникнуть ошибка, когда в разных слотах используется одинаковая пассфраза (к примеру, в первом и во втором), тогда шифрованное содержимое у них будет одинаковым, что разрушит бессигнатурность/отрицаемость. Для этого применён трюк -o 1 -p 1 вместо просто -o 1 для второго слота. В этом случае даже при одинаковых пассфразах шифртексты будут разными. Это соответствует в точности тому, как если бы сразу расшифровали два первых слота-сектора одной пассфразой (-b 2 -o 0 -p 0) и увидели совпадение содержимого первого расшифрованного сектора со вторым на открывшемся (крипто)устройстве. Т.е. «бессигнатурный криптораздел» для второго слота-сектора состоит не из него самого, а из него + первый сектор, поэтому мы делаем отступ (-p 1) — пропускаем первый сектор, чтобы расшифровать только второй.
Возможно, есть ещё какие-то нетривиальные уязвимости схемы, но пока их не вижу. Непосредственное хранение мастер-ключа на диске (пусть и шифрованное) тоже немного смущает:
UPD: Поскольку мастер-ключи разных криптоустройств генерятся случайным образом и всегда будут разными, plain-текст, зашифрованный в «слотах», тоже всегда будет разным (т.е. два разных криптоустройства с одинаковым мастер-ключом недопустимы). Следовательно, можно использовать одинаковые пассфразы для разных криптоустройств — ключами, выводимыми из этих пассфраз, всегда будут шифроваться разные мастер-ключи. Т.е. это предупреждение* неактуально для слотов в силу специфики их содержимого.
Кстати, в варианте с LUKS'ом какое-то частичное совпадение plain-текстов в слотах всё равно будет (хотя бы из-за общих метаданных и сигнатур), поэтому там предупреждение остаётся в силе, т.е. нельзя использовать одинаковые пассфразы для бессигнатурного слоя разных устройств.
* В plain mode одинаковые пассфразы ведут к одинаковым ключам, а одинаковые ключи на одинаковых plain-текстах дадут одинаковые шифртексты.