Пара вопросов про LUKS FDE

В теме криптографии (и в LUKS в частности) я нуб

Ниче не трогай, выбирай дефолт. Не потому, что" ты типа нуб и таким и оставайся", наоборот, твоё любопытство более чем похвально («неправильно», «да+да», «все так»), а потому что дефолт тщательно продумано и адекватен. Поиграйся с опциями, посмотри результат, не забудь вернуть дефолт.

(«неправильно», «да+да», «все так»)

Если это ответ на мои вопросы, не могли бы вы уточнить по пункту 1: все же PBKDF2 используется и при использовании keyfile? Насчет дефолтов, перелистал кучу мануалов большинство рекомендуют хэш sha512 и aes-xts-plain64 (дефолт) c длиной ключа 512 бит. Посмотрел на результаты cryptsetup benchmark на машине, в принципе это адекватные рекомендации.

LUKS поверх RAID/LVM.

Конечно, lvm подозрительней, чем диск размеченный таблицей разделов. А с появлением dm-integrity в luks2, намного больше стало смысла делать raid из шифрованных контейнеров. Но initrd, которые в дистрибутивах, расчитаны на открытие только одного контейнера и надо дорабатывать самому.

LVM в достаточной мере умеет raid, поэтому другой програмный raid скорей мешать будет.

На диске нет таблицы разделов и метаданных lvm вне/за пределами криптоконтейнера, так как реализовано LUKS -> LVM (mbr и /boot на флэшке).

все же PBKDF2 используется и при использовании keyfile?

Да, насколько мне известно. И это хорошо, потому что у кого-то может keyfile и фотка любимой супруги, а у кого-то файлик с условным 12345supersecret.

Разве не стоит ли в таком случае увеличить –iter-time (дефолт 1 сек), чтобы осложнить брутфорс? Скажем до 5 сек (отразиться только на luksOpen). Это на тему дефолтов. Я почему уточняю - просто возможно есть какие-то неочевидные грабли.

не стоит. зачем удлинять себе загрузку на 5 лишних секунд помноженные на кол-во шифрованных дисков. брутфорсом не поломаешь люкс с нормальным паролем.

Ок, всем спасибо за ответы.

PBKDF2 и выбор хэша. Я правильно понимаю,что данные параметры влияют только при использовании пароля для криптоконтейнера, а при использовании keyfile нет? (поскольку PBKDF2 это стандарт формирования ключа на базе пароля)

Нет, неправильно, LUKS использует мастер-ключ непосредственно для шифрования и ключевые слоты для ключей(пароли, ключевые файлы), на основе которых разблокируется зашифрованный мастер ключ(это называется KEK — key encryption key). Именно по этой причине LUKS(в отличие от «голого» dm-crypt) не завершается с ошибкой при длине ключевого файла меньше длины ключа шифрования.

«Голый» dm-crypt да, ключевые файлы не хеширует вообще, потому завершится с ошибкой при слишком малом размере файла или обрежет его при слишком большом.

Опция –align-payload, которая управляет смещением криптоконтейнера от начала тома/диска. Может использоваться в качестве дополнительной меры security through obscurity

Опять... «security through obscurity» это своеобразная модная фраза в кругах тех, кто далёк от криптографии(а часто и ИБ вообще), но искренне уверен в обратном(так что к Вам это не относится). Такие «эксперты» вешают данную фразу как ярлык куда ни попадя, наверняка используют её при попытках рассуждать о стеганографии и анонимности.

Настоящие специалисты, например, знают, что сокрытие тех же метаданных когда возможно — хорошая, годная практика. Те же специалисты знают один из самых главных принципов построения безопасной системы — сокращение(сиречь сокрытие) доступной для атаки площади. Приведу пример: у нас есть операционная система с веб-сервером, на которой параллельно запущена уязвимая, но не имеющая доступа к сети(недоступная «снаружи») программа. Стало быть, эксплуатировать эту уязвимость сложнее в разы. Так вот, подобные «эксперты» наверняка считают, что блокирование ненужного доступа к этой программе извне с помощью того же брандмауэра = «security through obscurity».

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

Рекомендую отодвинуть эту модную фразу и использовать ровно в двух случаях:

1. Когда видите, как кто-то пытается реализовать собственную криптосистему(никогда так не делайте без крайней необходимости!) и пытается всеми силами скрыть от всего мира принципы её работы, прикрываясь собственной безопасностью, по сути не давая провести нормальный криптоанализ и вредя тем самым самому себе. Такой случай использования — единственный классический.

2. Когда видите, как кто-то использует фразу не для случая под номером 1(ирония и сарказм не в счёт). В таком случае фраза-маркер поможет моментально определить некомпетентного человека, к словам которого необходимо относиться как минимум скептически(зачастую они бесполезны, нередко — вредны).

Но вернёмся к теме обсуждения.

Опция –align-payload

Бывает очень полезна в определённых случаях, например при необходимости быстро зашифровать диск без возможности создать отдельный раздел(некоторые файловые системы не умеют уменьшаться).

может ли указание данного параметра вручную повлиять на производительность чтения/записи на диск (стоит ли оставить по дефолту?)

Если коротко: может, стоит.

LUKS поверх RAID/LVM (с detached header). Стоит ли так реализовывать ... по которым можно будет определить, что на диске может присутствовать данные (а не что диск просто стерт/пуст)?

Тут так просто не ответить, нужны дополнительные данные, для начала: какова конечная цель всего процесса?

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

1. Ключ LUKS проще представить как пароль в файле. Он используется ровно точно так же как и пароль-с-клавиатуры: для расшифовки ключа шифрования контейнера.

2. Да, может негативно повлиять. Это надо было трогать только во времена первых ssd.

3. "Стоит ли" - ну, собственно, в вопросе и ответ. Если есть какая-то конкретная необходимость, то вопрос о стоимости стаёт вторичен.
   А если её нет, то и смысла нет никакого.

Да,да, именно так, меры в пунктах 2+3 рассматривались как дополнительные к основной (шифрованию) для уменьшения «поверхности атаки», т.е. для усложнения взлома контейнера. Поэтому это не в чистом виде security through obscurity, возможно, я не очень удачно подобрал термин.

Тут так просто не ответить, нужны дополнительные данные, для начала: какова конечная цель всего процесса?

Цель максимально осложность обнаружение того факта, что диск зашифрован/используется шифрование. Для этого нужно по-максимуму убрать все метаданные.

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

Такой сценарий не рассматривается. Рассматривается сценарий, что ноутбук может быть единожды утерян/украден или изъят.

Да, может негативно повлиять. Это надо было трогать только во времена первых ssd

Можете по-поподробнее? Почему нужно было для первых ssd эту опцию вручную выставлять, к чему ее игнорирование приводило?

«Стоит ли» - ну, собственно, в вопросе и ответ.

В принципе,я пришел к выводу,что не стоит. И raid и lvm оставляют на диске метаданные. Присутствие этих метаданных может породить подозрение, что диск все-таки непуст/используется,а мне бы хотелось,чтобы диск выглядел как стертый/неиспользуемый. Поэтому я вариант RAID -> LUKS и LVM -> LUKS отбрасываю, остановившись на LUKS -> LVM.

Цель максимально осложность обнаружение того факта, что диск зашифрован/используется шифрование.

Ну и также попытки взлома брутфорсом, в случае если есть на это подозрение. Поэтому в качестве допмеры и рассматривалась манипуляция с –align-payload. Да-да, я понимаю, что для взлома LUKS нужны немалые вычислительные ресурсы, но вопрос в том,что если эта опция не в ущерб чему/не имеет сильный негативный импакт на производительность в целом, почему бы ее не использовать для усиления сокрытия/стойкости к взлому?

ну как это поможет «скрытости/стойкости», если

$ sudo dd if=/dev/nvme0n1p1 bs=4096 count=1|strings
LUKS
xts-plain64
sha256

Почему нужно было для первых ssd эту опцию вручную выставлять, к чему ее игнорирование приводило?

Ядро не знало правильных границ, от чего при записи одного блока девайсу приходилось перезаписывать два.
Обычный write amplification с невыровненными блоками.

ну как это поможет «скрытости/стойкости», если

Я выше написал, у меня detached header

А ну да,действительно.

Тогда тем более непонятно, зачем это тебе нужно. Вообще никакого смысла.

Нашел в одной статье использование –align-payload дополнительно к detached header. Как я говорил,в LUKS я нуб (мне неизвестно,можно ли сбрутфорсинг luks-контейнер без заголовка), поэтому сошлюсь на нее:

We are going to offset the start of the encrypted container on the main drive by x number of 512 bytes. This further complicates decoding attacks because the beginning of the encrypted area is unknown. We sacrifice a tiny amount of storage area for what may be an arguably negligible security-by-obfuscation technique.

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

LUKS без заголовка «сбрутфорсить» ровно настолько сложно, насколько сложно это для использованного симметричного шифра. Если это какой-нибудь AES-256 — перебор невозможен(не в нашей вселенной). Ну а если кто-то сможет перебором взломать напрямую AES, тогда... Ну, это уже проблемы другого порядка.

Её необходимо очень аккуратно использовать, иначе подозрения можно лишь усилить. Единственный надёжный вариант тут — шифровать всё до последнего сектора, чтобы диск и правда выглядел стёртым.

--align-payload очень полезен для шифрования файлов и, например, создания многослойных контейнеров. С его помощью можно и дважды(и трижды, и n-жды) зашифровать диск целиком, получив правдоподобно отрицаемый скрытый контейнер, прямо как у VeraCrypt. Ну или объединить AES, Serpent и ещё какой-нибудь симметричный шифр, если паранойя позволяет предполагать, что в AES есть бекдор.

Разумеется, подобное применение требует знания принципов работы ФС и умения подобрать правильную ФС, а также выставить квоты. Если интересно — могу раписать тут подробнее.

Цель максимально осложность обнаружение того факта, что диск зашифрован/используется шифрование. Для этого нужно по-максимуму убрать все метаданные.

Такой сценарий не рассматривается. Рассматривается сценарий, что ноутбук может быть единожды утерян/украден или изъят.

В таком случае необходимо зашифровать все накопители целиком. Аппаратный RAID(бывают ноутбуки с таким?) работает с сырыми данными, потому разницы нет, программный же(тот же LVM) легко можно настроить для работы внутри зашифрованного диска.

Для сокрытия метаданных следует либо использовать отсоединённый заголовок, который необходимо хранить, например, на USB-карте(вместе с загрузочным сектором, например GRUB), либо шифровать диск «голым» dm-crypt, у которого заголовков нет вообще, а на USB хранить только загрузочный сектор(можно ещё ключевые файлы). Но для поддержки «сырого» dm-crypt тот же GRUB необходимо дорабатывать(патчить), а съёмный накопитель придётся использовать в любом случае, так что тут надо думать: или вам нужна правдоподобная отрицаемость скрытых контейнеров и эти самые контейнеры на диске(например, флешка с установленной прямо на неё декоративной ОС, загрузочный сектор которой используется для дешифрования основного накопителя, «внешние» контейнеры на котором содержат «подставные» файлы, а «внутренние» — боевую ОС), или просто возможность уничтожить данные удалённо при потере ноутбука, просто сломав флешку молотком или перезаписав случайными данными.

Если это какой-нибудь AES-256 — перебор невозможен(не в нашей вселенной). Ну а если кто-то сможет перебором взломать напрямую AES, тогда.

Ну а ка насчет взлома на больших вычислительных мощностях, на суперкомпьюете либо кластере (gpu)? Просто любопытно, это реально в настоящее время или нет.

Так вот у меня тоже сомнения возникли, решил поэтому уточнить. С одной стороны, при достаточной длине ключа и хорошем алгоритме сбрутить нереально, с другой эта опция может повлиять на производительность i/o, т.е стоит ли оно вообще (мож я что-то упускаю/не догоняю/не улавливаю дао).

либо шифровать диск «голым» dm-crypt, у которого заголовков нет вообще, а на USB хранить только загрузочный сектор(можно ещё ключевые файлы)

А есть ли какой-то сравнительный обзор а-ля «голый» dm-crypt vs luks, что лучше/надежнее/лучше по производительности итд?

Но для поддержки «сырого» dm-crypt тот же GRUB необходимо дорабатывать(патчить), а съёмный накопитель придётся использовать в любом случае

У меня и так такая реализация, MBR и /boot на флешке, основной диск расшифровывается в момент загрузки из initramfs (туда добавлены ключ и хидер). Я вариант с дополнительным шифрованием еще и /boot раздела не рассматриваю (grub+luks1), по мне это избыточно.

–align-payload очень полезен для шифрования файлов и, например, создания многослойных контейнеров.

Есть какой-нибудь вменяемый мануал? Интересно посмотреть варианты с многослойностью

Ну на одном мощном компьютере, если шифр неуязвим(AES считается таковым на данный момент), это порядка нескольких вигинтиллионов(>> 10^63) лет, на суперкомпьютере 100 петафлопс это быстрее в миллион раз(какие-то «жалкие» 10^60), суммарная производительность топ-500 — > 2 экзафлопс, что быстрее в 200 раз, производительность сети Bitcoin — где-то 10 зеттафлопс (в 5000 раз больше), данных по суммарной производительности всех компьютеров у меня нет, но предположим, что она в 10 000 раз больше, чем у битка, т.е. 100 000 зеттафлопс, или в триллион раз больше, чем у нашего одного мощного компьютера, т.е. в 10^12 раз, т.е. перебор займёт всего-то 10^50 лет, что «лишь» в 10^40, или в 10 000 000 000 000 000 000 000 000 000 000 000 000 000 раз больше возраста всей вселенной.

Впечатляет :). А это для какой длины ключа? 256?

Еще просьба уточнить, в LUKS при использовании aes-xts, длина ключа получается пополам,т.е 256 -> 128 (512 -> 256 соотвественно)?

Да, 256. Рекомендую всегда использовать только его, потому как AES сейчас уже везде имеет аппаратную поддержку, благодаря которой работает быстрее почти любого накопителя. 256 не в два раза сильнее 128, поскольку каждый бит удваивает криптостойкость.

Да, если в двух словах, то так. Всегда следует использовать aes-xts-plain64, потому что просто plain имеет проблемы на больших накопителях.

А есть ли какой-то сравнительный обзор а-ля «голый» dm-crypt vs luks, что лучше/надежнее/лучше по производительности итд?

Есть, лучшего обзора чем официальный FAQ не найти.

Есть какой-нибудь вменяемый мануал? Интересно посмотреть варианты с многослойностью

Нет, по крайней мере мне такой неизвестен, потому планирую написать самостоятельно и опубликовать у себя.

Но если совсем сжато, то мы берём и создаём файл с нулями, например dd if=/dev/zero of=/home/user/container.img bs=1M count=1000, далее на него можно либо luksFormat, либо plainOpen, далее создаём нежурналируемую ФС(например ext2), помещаем какие-нибудь файлы и снова делаем luksFormat/plainOpen, но уже с --align-payload/--offset — это и будет нашим скрытым контейнером. Чтобы можно было писать файлы на «внешний контейнер» без риска сломать скрытый, нужно будет каждый раз при возникновении подобной потребности выставлять квоты ФС, для чего используется специальный набор linux quota tools.

Рекомендую всегда использовать только его, потому как AES сейчас уже везде имеет аппаратную поддержку

Хм, я не вижу особо какой-то большой разницы для 256 и 512 в выводе cryptosetup benchmark на подопытной машине?

Для XTS я подразумевал именно 512 под 256. Конечно особой разницы не будет, в худшем случае 15-20%, не более того, зато 256 способен выдержать перебор на квантовом компьютере с использованием алгоритма Гровера.

И последний вопрос: какой хэш порекомендуете? Из почерпаного в интернетах следует, что алгоритм следует подбирать с меньшим количеством хэшей/сек для усложнения перебора. Судя по выводу cryptsetup я вижу два кандидата - это sha512 и whirpool.

Cryptsetup поддерживает почти все криптографические примитивы, доступные в ядре. Проверить доступность можно с помощью /proc/crypto. Если есть возможность, желательно использовать sha3-512, проверить доступность можно командой cat /proc/crypto | grep sha3

Если нет — sha512 тоже пойдёт, это хорошо изученная и на данный момент надёжная функция свёртки.

Итого, подведем резюме:

1. Смысла играться с PBKDF2 (–iter-time, – hash) и допобфускациями (–align-payload) особо нет, так как при длинах ключей 128/256 и использовании AES сбрутфорсить контейнер на данный момент невозможно от слова совсем, поэтому никакой погоды они не сделают.

2. С целью сокрытия/обфускации использовать detached header и не использовать LUKS поверх других тенологий (типа LUKS over RAID, LUKS over LVM), так как они оставляют метаданные на устройстве в открытом виде.

Все верно, есть какие-либо дополнения/замечания итд?

Смысла играться с PBKDF2 (–iter-time, – hash) и допобфускациями (–align-payload) особо нет

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

С целью сокрытия/обфускации использовать detached header и не использовать LUKS поверх других тенологий (типа LUKS over RAID, LUKS over LVM), так как они оставляют метаданные на устройстве в открытом виде.

Да. На диске никаких открытых данных быть не должно.

Все верно, есть какие-либо дополнения/замечания итд?

Есть — желательно сделать копию заголовка LUKS, записать на какой-нибудь надёжный накопитель и хранить в безопасном месте. Перенеся заголовок на USB мы увеличили вероятность повредить/потерять заголовок, без которого дешифровать данные нельзя никак. Согласитесь — потерять или сломать usb-карту намного легче, чем целый ноутбук.

Если в модель угроз входит полиция — необходимо обязательно выкидывать/продавать шифрованные накопители в случае изъятия и использовать вместо них новые, в потивном случае при повторном изъятии все всё поймут и применят бандитский криптоанализ.

Никогда не следует использовать одинаковые пароли и ключи для разных дисков, например для накопителя ноутбука и внешнего, на который периодически сохраняются резервные копии. Хотя в LUKS, в отличие от «голого» dm-crypt, всё же встроена довольно сильная защита от дураков(поскольку пароль или ключевой файл шифрует лишь уникальный ключ, и только этот ключ используется для работы с данными. plainOpen хеширует пароль однократно, так что одинаковый пароль полностью ломает всю защиту), утечка ключа всё равно приведёт к компрометации всех накопителей с одинаковым паролем.

Периодическая смена паролей — хороший тон, но пароли у «боевых» накопителей следует менять много чаще, чем у резервных, которые должны храниться в безопасном месте. Хорошая практика — менять пароли раз в год, LUKS позволяет удобно делать это без полного перешифрования всех данных. Подозрения на взлом = смена паролей, без вариантов и немедленно.

Чтобы шифрование диска хорошо работало, необходимо обеспечить хотя бы минимальную защиту рабочей среды. Первым делом стоит обезопасить оперативную память, включив lockdown ядра, хотя бы в режиме integrity. Желательно включить мгновенное стирание(заполнение нулями) участков памяти, которые более не используются, если ядро поддерживает такую опцию. Тема очень обширная на деле, в двух словах и не описать.

Пока как-то так.

Да, все это само собой прилагается. Ок, благодарю всех за ответы (в особенности SM5T001), сейчас неясностей по best pactices не осталось, тему можно закрывать.

Паранойики, вам тут в LUKS2 новые шифры завезли, а вы с дырявоускоренными AES играетесь. И с DM-integrity он проседает на чтении (хотя на запись там все проседают)