Шифрование накопителей: почему DEC, XTS и ГОСТ-LUKS2 — не одно и то же¶
Канонический источник: Теорию режимов см. в XTS, CTR, ACPKM. Здесь рассматриваются нормативные профили хранения, а не определения примитивов.
Новый нормативно-технический источник для дисков¶
Р 1323565.1.042-2022 — действующие рекомендации по режиму DEC (Disk Encryption with Counter Mode) для носителей с блочной структурой, введены 1 декабря 2022 года. Официальное описание прямо указывает на режим DEC. Это отдельная конструкция, а не ещё одно название XTS.
В НАЙС.ОС уже подтверждена работа kuznyechik-xts-plain64 в dm-crypt/LUKS2: шифрование/расшифрование через AF_ALG, создание тестового контейнера, ext4, запись, закрытие и повторное открытие. Такая схема использует алгоритм «Кузнечик» как базовый блочный шифр, а для сектора применяется XTS. Результат не следует публиковать как подтверждение выполнения рекомендаций DEC.
Сравнение¶
| Свойство | XTS с «Кузнечиком» | DEC по Р 1323565.1.042-2022 |
|---|---|---|
| Область | Блочные устройства dm-crypt | Носители с блочной структурой |
| Режим | XTS | DEC, счётчиковый режим |
| Проверенный пример НАЙС.ОС | kuznyechik-xts-plain64 |
Испытаний не проводилось |
| Подтверждение реализации | cryptsetup status + чтение данных |
Требуется самостоятельная реализация и испытания |
| Подлинность секторов | XTS не обеспечивает встроенную аутентификацию | Требования целостности необходимо анализировать отдельно |
Архитектура дискового шифрования¶
LUKS2 (метаданные, ключевые слоты, проверка пароля)
└─ dm-crypt (блочное устройство)
└─ Kernel Crypto API
├─ Кузнечик — блочный алгоритм
└─ XTS — режим обработки секторов
└─ файловая система (например, ext4)
При работе с шифрованным корневым разделом наличие «Кузнечика» в ядре не заменяет компоненты разблокировки LUKS2 в initramfs. Для других дисков разблокировка может происходить после старта системы. Смена режима работающего зашифрованного диска не производится заменой строкового значения в crypttab: криптографический формат существующих данных изменится, потребуется миграция с резервной копией.
Безопасная проверка текущего тома¶
Это диагностические команды. Первую выполняют для открытого тома, вторую — для тестового LUKS-файла. luksDump показывает параметры защиты ключевого слота отдельно от шифра данных. Пример kuznyechik-xts-plain64 и полученные выводы описаны в лабораторном руководстве НАЙС.ОС.
Какие документы нужны для новых разработок¶
Рекомендации DEC следует читать вместе с требованиями к используемому блочному алгоритму и режиму, моделью угроз и ограничениями реализации. Не следует переносить опубликованные тестовые векторы XTS на DEC или наоборот.
Источники: Р 1323565.1.042-2022, официальный статус и область применения; ГОСТ Р 34.12-2015 и 34.13-2015, каталог ТК26; полное руководство по ГОСТ-дискам в НАЙС.ОС.
Терминология и нормативные границы¶
- Блочный алгоритм: преобразует блок по ключу.
Кузнечик— 128 бит;Магма— 64 бита. ГОСТ Р 34.12-2015. - Режим применения: определяет обработку потока или сектора. XTS и DEC различаются конструкцией и требованиями; ГОСТ Р 34.13-2015 не следует смешивать с рекомендациями DEC.
- Контейнер: LUKS2 хранит метаданные, параметры защиты ключа и слоты; не является ГОСТ-шифром.
- Инфраструктура запуска: dm-crypt, драйвер Linux Crypto API, initramfs, конфигурация разблокировки и восстановление после сбоя.
Модель угроз для дискового шифрования¶
Защита блоков адресует утрату/хищение выключенного носителя при сохранении секретности ключей. Она сама по себе не гарантирует защиту от администратора уже разблокированной системы, вредоносного ПО на работающем сервере, подмены метаданных или незаметной модификации секторов. XTS предназначен для конфиденциальности и не предоставляет AEAD-целостность. Потребность в целостности на уровне хранения — отдельное архитектурное решение.
Что означает «ГОСТ из коробки» для дисков¶
Успешный тест kuznyechik-xts-plain64 доказывает конкретный путь: cryptsetup → dm-crypt → xts(kuznyechik) → запись/чтение. Он не доказывает DEC, ГОСТ-защиту ключевых слотов LUKS2 или работу зашифрованного корня из initramfs. Для каждой архитектуры применяется самостоятельный приёмочный протокол.
Проверка до промышленного применения¶
Не экспериментируйте на работающем томе. Создайте отдельный тестовый образ, проверьте его параметры, запись и полное закрытие/повторное открытие, сохранение данных и восстановление из резервной копии. Зафиксируйте версию RPM cryptsetup, ядро, точный режим и набор ключевых слотов. Проверьте отсутствие случайного вывода ключевого материала в журнал. Для зашифрованного корня отдельно протестируйте сценарий перезагрузки, недоступности ключевого хранилища и резервного восстановления.
Смотрите XTS, Кузнечик, ГОСТ Crypto API и руководство LUKS2.