Содержание статьи
Значимость и проблема FDE
Дела с шифрованием запоминающих устройств обстоят забавным образом: оно повсюду и нигде одновременно. Начиная от мобильных устройств, где оно играет особо важную роль (причем большинство пользователей об этом даже не догадываются), и заканчивая большими дата-центрами. В то же время исследования, проведенные за последние десять лет в разных странах, включая Великобританию, Германию и США, показывают, что не только обычные пользователи, но и корпорации не сильно пекутся о личных данных.
К сожалению, на этом проблемы не заканчиваются. Большинство нынешних систем полнодискового шифрования (Full Disk Encryption — FDE) обеспечивают конфиденциальность данных, но не их целостность. Это означает, что злоумышленник может физически изменить байт информации на диске и пользователь не сможет обнаружить, что и где изменилось и откуда сбои. Все потому, что сектор открытого текста равняется сектору шифротекста, а метаинформацию хранить негде.
Искажение данных может произойти не только в результате прямого воздействия злоумышленником, но и по чистой случайности: неплотно воткнутый кабель, перезапись данных утилитой, которая не распознает формат LUKS, и так далее.
Проблему целостности данных решает аутентифицированное шифрование (Authenticated Encryption with Associated Data — AEAD). Это не новая тема, и активные исследования вместе с конкурсами на лучший алгоритм (см. CAESAR) ведутся десятки лет. Но для реализации AEAD в полнодисковом шифровании нужно придумать, где хранить дополнительные данные (те самые AD).
Зачем шифровать
Если ты еще сомневаешься, что полнодисковое шифрование — нужная штука, то подумай вот о чем: оно не только помогает сохранить в тайне твою очень важную инфу и пикантные фоточки, защищая тебя от разного рода мошенничества и шантажа, но и предохраняет диск от изменений. Например, тебя могут на какое-то время разлучить с твоим компьютером, и речь не только о «маски-шоу», но и, например, о дотошном погранконтроле. Как в таких случаях убедиться, что на диске не появилось чего-то нового? Ну и последний, чисто эмоциональный аргумент: просто представь, какой неистовый баттхерт будет у кого-то, когда он не сможет получить доступ к твоим данным, — даже если там нет ничего интересного!
Решение
Ребята из Чехии несколько лет разрабатывали решение для Linux, которое сможет предоставить FDE с функцией AEAD. Главными критериями для этого были:
- обеспечить работу без дополнительного оборудования;
- сделать возможным применение на самых обычных дисках, которые доступны в магазине, а не по спецзаказу;
- использовать родной размер сектора;
- реализовать возможность восстановления данных в случае перебоя питания;
- использовать (и писать) только свободный код и алгоритмы.
Результатом разработки стали новые объекты (targets) для device mapper: dm-integrity, обновленный dm-crypt с аутентифицированным шифрованием и формат LUKS2. Их поддержка включена в ядро Linux начиная с версии 4.12, а новые шифры AEGIS и MORUS (финалисты CAESAR) доступны с 4.18.
Подробнее о dm-integrity, dm-crypt и LUKS2
dm-integrity эмулирует блочное устройство с дополнительными тегами в каждом секторе и использует их для хранения метаинформации. Поддерживает журналирование, которое можно опционально включить — например, чтобы можно было восстановить данные после сбоя питания. Применяется как в паре с dm-crypt для предоставления AEAD, так и отдельно — для контроля целостности данных без шифрования. Управляется утилитами cryptsetup, если нужно шифрование, или integritysetup, соответственно, без него.
dm-crypt поддерживает режимы AEAD для шифров и рандомизацию вектора инициализации (Initialization Vector). На каждую запись в сектор ядром генерируется случайный Initialization Vector. К примеру, в режиме XTS вектор шифруется хитрым образом, что позволяет брать для него предсказуемый номер сектора (plain или plain64).
LUKS2 — это вторая версия формата LUKS с расширенными возможностями. Были устранены некоторые проблемы и ограничения, однако большинство идей LUKS1 остались. Среди новых возможностей:
- поддержка затратных для памяти функций формирования ключа (key derivation function — KDF);
- реализован новый вид заголовка (бинарный + JSON), добавлен механизм контрольных сумм, заголовок дублирован (кроме области ключей) из соображений безопасности;
- ключам можно назначать приоритет;
- JSON позволяет расширять возможности формата, не модифицируя бинарную структуру;
- в заголовке реализованы токены, которые связаны со слотами для ключей и описывают, где взять пароль. Токены могут быть использованы для поддержки механизмов внешнего хранения ключей.
Посмотреть формат заголовка LUKS2 полностью и изучить каждое поле можно в спецификации.
Argon2 — та самая, затратная для памяти и центрального процессора, KDF. В Linux доступны два варианта: Argon2i и Argon2id.
На данный момент шифры AEAD, которые есть в ядре (AES-GCM и ChaCha20-Poly1305), имеют короткий (96-bit) одноразовый код (nonce). Это означает, что вероятность коллизии слишком большая (с точки зрения криптографии) и ее нельзя игнорировать, так как использование одноразового кода дважды (nonce reuse) фатально для AES-GCM. На всякий случай отмечу, что это не касается шифрования информации, передаваемой по сети.
Для обеспечения AEAD в FDE сейчас стоит использовать новые AEGIS или MORUS. Или же AES-XTS + HMAC, если нет доступа к 4.18. Проблема этой конструкции в том, что нужно хешировать сектор, а хеширование 4 Кбайт данных занимает какое-то время. Другими словами: это долго.
Поддержка dm-integrity включается в ядре опцией CONFIG_DM_INTEGRITY. В Arch Linux проверить, включена ли она у тебя, можно командой
$ zgrep -E "CONFIG_DM_INTEGRITY|CONFIG_BLK_DEV_INTEGRITY" /proc/config.gz
CONFIG_BLK_DEV_INTEGRITY=y
CONFIG_DM_INTEGRITY=m
В Ubuntu список конфигов ядра находится в разделе /boot, файл config-версия_ядра — грепай его, и узнаешь всю правду.
Стоит упомянуть, что авторы не пытаются переизобрести велосипед и придумать невиданную ранее концепцию. Подобное решение, но с другим подходом существует во FreeBSD и называется GELI. Здесь для обеспечения целостности данных используется HMAC.
Полнодисковое шифрование с LUKS2 на практике
Итак, у нас в арсенале скоро появятся новые алгоритмы и новые фичи. Но попробовать их не терпится уже сейчас, чем я и занялся.
WARNING
Работа над форматом LUKS2 еще не завершена, так что не рекомендуется использовать его в продакшене!
Тут же нас встречает первая проблема: поддержки со стороны загрузчиков просто-напросто нет. На данный момент ни GRUB, ни другие не умеют работать с LUKS2.
Отсутствие возможности грузиться с раздела LUKS2 при этом не конец света: /boot зашифруем в LUKS1. Кто-то возразит, что /boot — главный раздел и злоумышленнику, который получил доступ к нему, уже все равно, что у тебя в /. И это правда. Но к сожалению, пока что приходится работать с тем, что есть. LUKS1, конечно же, неплох, но мы сюда пришли новые фичи тестить. В любом случае LUKS2 находится в стадии допила напильником развития и модификации, поэтому о деплое в продакшен речи в любом случае не идет.
Тем временем сзади подкрался второй подвох: это ядро 4.18, которое, как ты помнишь, нужно для AEGIS и MORUS и которого на момент написания статьи нет ни в одном live-установщике. Единственная идея, которая мне приходит в голову, — это кастомный archiso, так как ежемесячный билд содержит только версию 4.17.11.
Продолжение доступно только участникам
Вариант 1. Присоединись к сообществу «Xakep.ru», чтобы читать все материалы на сайте
Членство в сообществе в течение указанного срока откроет тебе доступ ко ВСЕМ материалам «Хакера», позволит скачивать выпуски в PDF, отключит рекламу на сайте и увеличит личную накопительную скидку! Подробнее
Вариант 2. Открой один материал
Заинтересовала статья, но нет возможности стать членом клуба «Xakep.ru»? Тогда этот вариант для тебя! Обрати внимание: этот способ подходит только для статей, опубликованных более двух месяцев назад.
Я уже участник «Xakep.ru»
