Data-at-rest encryption (Русский)

From ArchWiki
Состояние перевода: На этой странице представлен перевод статьи Data-at-rest encryption. Дата последней синхронизации: 22 июля 2022. Вы можете помочь синхронизировать перевод, если в английской версии произошли изменения.

Ссылки по теме

В этой статье рассматриваются программы для шифрования хранимых данных (данных в состоянии покоя, data at rest), которые на лету шифруют и дешифруют данные на блочном устройстве, разделе диска или в каталоге. Примеры блочных устройств — жёсткие диски, флэш-накопители и DVD.

Шифрование хранимых данных следует рассматривать только как дополнение к существующим механизмам безопасности операционной системы — сфокусированное на защите физического доступа, в то время как другие части системы обеспечивают такие вещи, как сетевая безопасность и контроль доступа пользователей.

Шифрование всего диска (full-disk encryption, FDE) описано в статье dm-crypt/Encrypting an entire system.

Зачем использовать шифрование?

Шифрование данных в состоянии покоя гарантирует, что файлы всегда хранятся на диске в зашифрованном виде. Файлы становятся доступными для операционной системы и приложений в читаемой форме, только когда система включена и разблокирована доверенным пользователем (данные в процессе использования — data in use, или в процессе перемещения — data in transit). Неавторизованный человек, просматривающий содержимое диска напрямую, вместо реальных файлов увидит лишь что-то похожее на случайный шум.

Например, это может предотвратить несанкционированный просмотр данных, когда компьютер или жёсткий диск:

  • расположен в месте, к которому могут получить доступ недоверенные лица, пока вас рядом нет
  • потерян или украден, как в случае с ноутбуками, нетбуками или внешними устройствами хранения данных
  • в ремонтной мастерской
  • выброшен после окончания срока службы

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

Важно: Шифрование хранимых данных не защитит от вообще всех существующих угроз.

Вы по-прежнему будете уязвимы:

  • к злоумышленникам, которые могут проникнуть в вашу систему (например, через интернет) во время её работы — после того, как вы уже разблокировали и смонтировали зашифрованные части диска;
  • к злоумышленникам, которые могут получить физический доступ к компьютеру во время его работы (даже если вы используете блокировщик экрана) — или даже вскоре после его работы, если у них есть ресурсы для проведения cold boot attack;
  • к правительственным организациям, которые не только обладают ресурсами для проведения вышеупомянутых атак, но и могут просто заставить вас отдать свои ключи/пароли, используя различные методы принуждения. В большинстве недемократических стран мира, а также в США и Великобритании, это может быть законно для правоохранительных органов, если у них есть подозрения, что вы можете скрывать что-то интересное;
  • к терморектальному криптоанализу. Смотрите также XKCD #538.

Чтобы иметь шанс противостоять профессиональным злоумышленникам, способным вскрыть вашу систему перед её использованием, требуется очень мощная система шифрования диска (например, полное шифрование системы с проверкой подлинности и без незашифрованного загрузочного раздела). И даже в этом случае она не сможет предотвратить все типы взлома (например, аппаратные кейлоггеры). Лучшее, что можно сделать, — это аппаратное шифрование всего диска и доверенная загрузка (Trusted Computing).

Важно: Шифрование также не защитит вас от того, что кто-то просто сотрёт ваш диск. Для сохранения данных рекомендуется регулярно создавать резервные копии.

Шифрование данных системы

Хотя шифрование только пользовательских данных (часто расположенных в домашнем каталоге или на съёмных носителях, например DVD с данными) является самым простым и наименее навязчивым методом, он имеет ряд существенных недостатков. В современных компьютерных системах существует множество фоновых процессов, которые могут кэшировать и хранить информацию о пользовательских данных или части самих данных в незашифрованных областях жёсткого диска, таких как:

  • подкачка
  • /tmp (временные файлы, создаваемые пользовательскими приложениями)
    • (возможные способы решения: избегать таких приложений; монтировать /tmp как ram-диск)
  • /var (файлы журналов, базы данных и т.п.; например, locate хранит индекс всех имён файлов в /var/lib/plocate/plocate.db).

Решением является шифрование и системных, и пользовательских данных, что предотвращает несанкционированный физический доступ к секретным данным, которые могли осесть в кэшах системы. Недостаток такого подхода в том, разблокировка зашифрованных частей диска должна происходить ещё в начале загрузки. Также преимуществом шифрования данных системы является то, что оно усложняет установку вредоносных программ, таких как кейлоггеры или руткиты, злоумышленнику с физическим доступом.

Доступные методы

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

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

Если вы не знакомы с подобными операциями, прочтите также раздел #Как работает шифрование ниже.

Доступные методы шифрования данных в состоянии покоя можно разделить на два типа по уровню их работы:

Шифрование поверх файловой системы

При шифровании поверх уже существующей файловой системы (stacked filesystem encryption) все файлы, записанные в папку с подключенным шифрованием, шифруются на лету, прежде чем базовая файловая система запишет их на диск, и расшифровываются каждый раз, когда файловая система считывает их с диска. Таким образом, файлы хранятся в файловой системе хоста в зашифрованном виде (это означает, что их содержимое, а также имена файлов/папок заменяются данными, выглядящими как случайный шум, примерно той же длины), но при этом в папке с подключенным шифрованием они выглядят так же, как и без шифрования, в виде обычных файлов / симлинков / хардлинков / и т. п.

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

Такими файловыми системами являются, например, eCryptfs и EncFS.

Оптимизированное для облачных хранилищ

Если вы используете шифрование поверх файловой системы, чтобы скрыть данные от используемых вами облачных хранилищ, стоит рассмотреть альтернативы файловым системам eCryptfs и EncFS, поскольку они не оптимизированы для передачи файлов через интернет. Существуют решения, разработанные специально для этой цели:

Некоторые облачные хралилища предоставляют свои приложения с поддержкой шифрования.

Шифрование блочного устройства

Методы шифрования блочных устройств, с другой стороны, работают ниже уровня файловой системы и обеспечивают шифрование всего, что записано на блочное устройство (то есть целый диск, раздел или файл, выступающий в качестве loop-устройства). Это означает, что пока блочное устройство не используется, всё его содержимое выглядит как большой кусок случайных данных, и нет возможности определить, какая файловая система и какие данные на нём содержатся. Доступ к данным происходит, опять же, путём монтирования защищённого контейнера (в данном случае блочного устройства) в произвольное место специальным образом.

В Arch Linux доступны следующие решения для шифрования блочных устройств:

loop-AES
loop-AES является потомком cryptoloop и представляет собой надёжное и быстрое решение для шифрования системы. Однако loop-AES считается менее удобным для пользователя, чем другие варианты, поскольку требует использования нестандартного ядра.
dm-crypt
dm-crypt — это стандартная функциональность шифрования device-mapper, предоставляемая ядром Linux. Она может использоваться непосредственно теми, кто хочет иметь полный контроль над всеми аспектами управления разделами и ключами. Управление dm-crypt осуществляется с помощью пользовательского инструмента cryptsetup. Она может использоваться для следующих типов шифрования блочных устройств: LUKS (по умолчанию), plain, и имеет ограниченные возможности для устройств loopAES и Truecrypt.
  • LUKS, используемый по умолчанию, представляет собой дополнительный уровень удобства, который хранит всю необходимую информацию о настройках для dm-crypt на само́м диске и абстрагирует управление разделами и ключами с целью упрощения использования и повышения безопасности.
  • Простой (plain) режим dm-crypt, будучи оригинальной функциональностью ядра, не предоставляет дополнительных удобств. С ним сложнее получить ту же криптографическую стойкость. При этом используются более длинные ключи (пароли или файлы ключей). Однако у него есть преимущества, описанные в следующем разделе #Сравнение типов шифрования.
TrueCrypt/VeraCrypt
Переносимый формат, поддерживающий шифрование целых дисков/разделов или файловых контейнеров, с совместимостью со всеми основными операционными системами. Разработка TrueCrypt прекращена его разработчиками в мае 2014 года. Его форк VeraCrypt прошёл аудит безопасности в 2016 году.

#Сравнение типов шифрования описывает практические последствия выбора того или иного метода. Смотрите также сравнение в этой статье про eCryptfs. Список статей о используемых методах, а также инструментах, не включенных таблицу, доступен в Category:Encryption (Русский) (на английском языке: Category:Encryption).

Сравнение типов шифрования

Аспект Шифрование блочного устройства Шифрование поверх файловой системы
Шифрует блочное устройство целиком файлы
Зашифрованные данные могут храниться... на диске целиком, на отдельном разделе или в файле, используемом как loop-устройство в каталоге в уже существующей файловой системе
Связь с файловой системой работает ниже уровня файловой системы: не имеет значения, является ли содержимое зашифрованного блочного устройства файловой системой, таблицей разделов, установкой LVM или чем-либо ещё добавляет дополнительный уровень к существующей файловой системе для автоматического шифрования/дешифрования файлов при каждой операции записи/чтения
Шифрование метаданных (количество файлов, структура каталогов, размеры, права доступа, даты изменения и т.п.) Да Нет
(хотя имена файлов и каталогов могут быть зашифрованы)
Возможность шифрования жёсткого диска целиком (вместе с таблицей разделов) Да Нет
Шифрование подкачки Да Нет
Может использоваться без предварительного выделения фиксированного объёма под хранение зашифрованных данных Нет Да
Может использоваться для защиты существующих файловых систем без доступа к блочным устройствам, например, общих ресурсов NFS или Samba, облачных хранилищ и т.д. 1 Нет Да
Возможность резервного копирования отдельных файлов без дешифровки Нет Да
  1. ну, в блочном шифровании можно использовать файл в качестве контейнера (loop-устройства), но возможности файловой системы всё равно не будут использоваться.

Сравнительная таблица

В столбце «dm-crypt +/- LUKS» указаны возможности dm-crypt как для режима шифрования LUKS («+»), так и для plain («-»). Если какая-то функция требует использования LUKS, это обозначается как «(с LUKS)». Аналогично «(без LUKS)» указывает на то, что использование LUKS является контрпродуктивным для достижения данной функции и следует использовать режим plain.

Общая информация Loop-AES dm-crypt +/- LUKS VeraCrypt ZFS eCryptfs EncFS gocryptfs fscrypt
Тип шифрования блочное устройство блочное устройство блочное устройство нативная ФС или блочное устройство стековая ФС стековая ФС стековая ФС нативная ФС
Примечание появился раньше других; возможно, самый быстрый; работает на старых системах стандарт де-факто для шифрования блочных устройств в Linux; очень гибкий форк TrueCrypt, может работать с томами TrueCrypt и VeraCrypt функция шифрования относительно новая (2019); шифрованные блочные устройства предоставляет компания ZVOL немного быстрее, чем EncFS; отдельные зашифр. файлы можно переносить между системами самый простой в использовании; можно управлять без прав root стремится стать преемником EncFS по умолчанию для шифрования Chrome OS и Android
Доступность в Arch Linux требуется компиляция своего ядра модули ядра: входит в состав стандартного ядра; инструменты: device-mapper, cryptsetup veracrypt ZFS#Installation модуль ядра: входит в состав стандартного ядра; инструменты: ecryptfs-utils encfs gocryptfs модуль ядра: входит в состав стандартного ядра; инструмент: fscrypt
Лицензия GPL GPL Apache License 2.0; некоторые части — TrueCrypt License v3.0 CDDL GPL GPL MIT GPL (ядро), Apache 2.0 (инструменты)
Шифрование реализовано в... пространстве ядра пространстве ядра пространстве ядра пространстве ядра пространстве ядра пространстве пользователя (FUSE) пространстве пользователя (FUSE) пространстве ядра
Метаданные шифрования хранятся в... ? с LUKS: заголовке LUKS начале/конце (расшифр.) устройства (описание формата) DSL (dataset & snapshot layer; talk/slides) заголовке каждого зашифр. файла файле настроек в зашифр. каталоге ? каталоге .fscrypt в корне каждой ФС
Ключ шифрования хранится в... ? с LUKS: заголовке LUKS начале/конце (расшифр.) устройства (описание формата) DSL (dataset & snapshot layer; talk/slides) файле ключа, который можно хранить где угодно файле ключа, который можно хранить где угодно

[1][2]

? каталоге .fscrypt в корне каждой ФС
Особенности использования Loop-AES dm-crypt +/- LUKS VeraCrypt ZFS eCryptfs EncFS gocryptfs fscrypt
Не-root пользователи могут создавать или удалять зашифрованные контейнеры Нет Нет Нет Да ограниченно Да Да Да
Графический интерфейс Нет Нет Да Нет Нет Да

опционально

Нет Нет
Поддержка автомонтирования при входе ? Да Да

с systemd и /etc/crypttab

? Да Да Да Да
Автоматическое размонтирование при неактивности ? ? ? Нет ? Да Да
[3] 		Нет
Безопасность Loop-AES dm-crypt +/- LUKS VeraCrypt ZFS eCryptfs EncFS gocryptfs fscrypt
Поддержка алгоритмов шифрования AES AES, Anubis, CAST5/6, Twofish, Serpent, Camellia, Blowfish,… (любые шифры, которые есть в Crypto API ядра) AES, Twofish, Serpent, Camellia, Kuznyechik AES AES, Blowfish, Twofish... AES, Blowfish, Twofish и любые другие доступные в системе шифры AES AES, ChaCha12
Проверка целостности нет опционально в LUKS2 нет CCM, GCM нет нет (по умолчанию)
HMAC (режим максимальной секретности) 		GCM нет
Поддержка соли ? Да
(с LUKS) 		Да Да Да ? Да Да
Поддержка каскада из нескольких шифров ? Не в одном устройстве, но можно сделать каскад блочных устройств Да

AES-Twofish, AES-Twofish-Serpent, Serpent-AES, Serpent-Twofish-AES, Twofish-Serpent

Нет ? Нет Нет Нет
Support for key-slot diffusion ? Да
(с LUKS) 		? ? ? ? ? Нет
Protection against key scrubbing Да Да
(без LUKS) 		? ? ? ? ? Нет
Поддержка нескольких (независимых друг от друга) ключей для одних и тех же зашифрованных данных ? Да
(с LUKS) 		? Нет ? Нет ? Да
Скорость Loop-AES dm-crypt +/- LUKS VeraCrypt ZFS eCryptfs EncFS gocryptfs fscrypt
Использование нескольких потоков ? Да
[4] 		Да Да ? ? Да Да
Аппаратное ускорение шифрования Да Да Да Да Да Да
[5] 		Да Да
Специфичное для шифрования блочных устройств Loop-AES dm-crypt +/- LUKS VeraCrypt ZFS
Поддержка (ручного) изменения размера зашифрованного блочного устройства на месте ? Да Нет Да
Специфичное для шифрования поверх ФС ZFS eCryptfs EncFS gocryptfs fscrypt
Поддержка файловых систем ZFS ext3, ext4, xfs (с оговорками), jfs, nfs... ext3, ext4, xfs (с оговорками), jfs, nfs, cifs...

[6]

любые ext4, F2FS, UBIFS
Возможность шифровать имена файлов Да
zfs(8) 		Да Да Да Да
Возможность не шифровать имена файлов Нет Да Да Да
[7] 		Нет
Оптимизации для работы с разреженными (sparse) файлами Да Нет Да Да Да
Совместимость Loop-AES dm-crypt +/- LUKS VeraCrypt ZFS eCryptfs EncFS gocryptfs fscrypt
Поддержка версий ядра Linux 2.0 или новее Режим CBC с 2.6.4, ESSIV 2.6.10, LRW 2.6.20, XTS 2.6.24 ? 2.6.32 или новее (в версии 0.8.3) ? 2.4 или новее ? 4.1 или новее
Доступ к зашифрованным данным из Windows ? ? Да Да
OpenZFS on Windows (repo) 		? Нет (нужны админ. права) Да (порт cppcryptfs) Нет
Доступ к зашифрованным данным из macOS ? ? Да Да
OpenZFS on OS X (repo) 		? Да
[8][устаревшая ссылка 2024-07-30 ⓘ] 		Да (бета) Нет
Доступ к зашифрованным данным из FreeBSD ? ? Да Да
ZFS on FreeBSD (нативно; repo) 		? Да
[9] 		? Нет
Используется в ? установщиках Debian и Ubuntu (шифрование системы)
установщике Fedora 		? ? ? ? ? Android, Chrome OS

Подготовка

Выбор способа шифрования

Какой способ шифрования подойдёт вам, зависит от ваших целей (смотрите раздел #Зачем использовать шифрование?) и параметров системы.

Помимо прочего, вам нужно будет ответить на следующие вопросы:

От какого типа «злоумышленников» вы хотите защититься?
  • Случайный пользователь, шныряющий по вашему диску, когда компьютер выключен, украден и т.д.
  • Профессиональный криптоаналитик, который может получить долговременный доступ на чтение/запись к вашей системе до и после её использования
  • Любой промежуточный вариант
Что вы хотите зашифровать?
  • Только пользовательские данные
  • Систему и пользовательские данные
  • Только конфиденциальные данные, то есть часть данных
Как быть с подкачкой, /tmp и т.д.?
  • Отключить или смонтировать как ram-диск
  • Зашифровать подкачку
    • Файл подкачки как часть шифрования всего диска
    • Шифровать раздел подкачки отдельно
Как следует разблокировать зашифрованные части диска?
  • Пароль
    • Такой же, как пароль для входа в систему
    • Отличается от пароля для входа в систему
  • Файл ключа (например, на USB-накопителе, который вы храните в безопасном месте или носите с собой)
  • Оба варианта вместе
Когда следует разблокировать зашифрованные части диска?
  • Перед загрузкой
  • Во время загрузки
  • При входе в систему
  • Вручную по требованию (после входа в систему)
Как следует организовать работу с несколькими пользователями?
  • Никак
  • Использовать общий пароль (или файл ключа), известный каждому пользователю
  • Независимые друг от друга пароли (или файлы ключей) для одной и той же зашифрованной части диска
  • Отдельные зашифрованные части диска для разных пользователей

Ответив на эти вопросы, вы сможете сделать необходимый технический выбор (смотрите раздел #Доступные методы выше и раздел #Как работает шифрование ниже), касающийся:

  • метода шифрования: шифрование поверх файловой системы или шифрование блочного устройства
  • управления ключами
  • алгоритма и режима шифрования
  • хранения метаданных
  • расположения «нижнего каталога» (при использовании стековой файловой системы)

Примеры

На практике это может выглядеть примерно так:

Пример 1
Простое шифрование данных пользователя (внутренний жёсткий диск) с использованием виртуальной папки ~/Private в домашнем каталоге пользователя, зашифрованной с помощью EncFS
  • зашифрованные версии файлов хранятся на диске в каталоге ~/.Private
  • разблокируется по требованию с помощью отдельного пароля
Пример 2
Частичное шифрование системы, домашние каталоги пользователей шифруются с помощью eCryptfs
  • разблокируется при входе пользователя с помощью пароля для входа в систему
  • разделы подкачки и /tmp зашифрованы с помощью dm-crypt с LUKS, с использованием автоматически генерируемого на каждый сеанс временного ключа
  • индексирование/кэширование содержимого раздела /home с помощью slocate (и подобных приложений) отключено.
Пример 3
Шифрование системы — весь жёсткий диск, кроме раздела /boot (однако /boot можно зашифровать с помощью GRUB), зашифрован с помощью dm-crypt с LUKS
  • разблокируется во время загрузки с помощью пароля или USB-накопителя с файлами ключей
  • Возможно, разные пароли/ключи для каждого пользователя — независимо отзываемые
  • Возможно шифрование нескольких дисков или гибкая разметка разделов с помощью LUKS on LVM
Пример 4
Скрытое/простое шифрование системы — весь жёсткий диск зашифрован с помощью plain dm-crypt
  • USB-загрузка с использованием отдельного пароля плюс USB-накопителя с файлом ключа
  • проверка целостности данных перед монтированием
  • раздел /boot располагается на вышеупомянутом USB-накопителе
Пример 5
Шифрование файлового контейнера — заранее созданный файл служит зашифрованным контейнером для данных пользователя
  • Файл вроде ~/.volume.img шифруется с помощью dm-crypt/Encrypting a non-root file system#File container
  • Периодическое резервное копирование путём копирования всего контейнера на удалённый хост

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

Выбор надёжного пароля

Смотрите Безопасность#Надёжность пароля.

Подготовка диска

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

Предотвращение восстановления ранее хранившихся данных

Шифрование диска не меняет того факта, что отдельные сектора перезаписываются только по необходимости, когда файловая система создаёт или изменяет данные, хранящиеся в этих секторах (смотрите раздел #Как работает шифрование ниже). Сектора, которые файловая система считает «неиспользуемыми в данный момент», остаются нетронутыми и могут содержать остатки данных от предыдущих файловых систем. Единственный способ убедиться, что все данные, которые вы ранее хранили на диске, не могут быть восстановлены, — стереть их вручную. Для этой цели не имеет значения, используются ли нулевые или случайные байты (хотя стирание нулевыми байтами будет намного быстрее).

Предотвращение раскрытия информации об использовании зашифрованного диска

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

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

После того как вы определились, какой вид стирания диска использовать, обратитесь к статье Securely wipe disk для получения технических инструкций.

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

Как работает шифрование

Этот раздел предназначен для ознакомления с концепциями и процессами, которые лежат в основе обычных способов шифрования дисков.

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

Базовый принцип

Для шифрования диска каждое блочное устройство (или отдельный файл в случае шифрования поверх файловой системы) делится на сектора равной длины, например 512 байт (4096 бит). Шифрование/дешифрование выполняется отдельно для каждого сектора, поэтому n-ый сектор блочного устройства или файла на диске будет хранить зашифрованную версию n-ого сектора исходных данных.

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

             ╔═══════╗
    сектор 1 ║"???.."║
             ╠═══════╣         ╭┈┈┈┈┈┈╮
    сектор 2 ║"???.."║         ┊ ключ ┊
             ╠═══════╣         ╰┈┈┬┈┈┈╯
             :       :            │
             ╠═══════╣            ▼             ┣┉┉┉┉┉┉┉┫
    сектор n ║"???.."║━━━━━━━(дешифровка)━━━━━━▶┋"абв.."┋ сектор n
             ╠═══════╣                          ┣┉┉┉┉┉┉┉┫
             :       :
             ╚═══════╝

 зашифрованное блочное                          расшифрованные
        устройство или                          данные в памяти
         файл на диске

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

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

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

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

Смотрите также Wikipedia:Authenticated encryption.

Ключи, файлы ключей и пароли

Примеры хранения и защиты мастер-ключа с помощью файла ключей:

Хранение файла ключа открытым текстом

Обычное хранение главного ключа в файле (в читаемой форме) является самым простым вариантом. Этот файл — так называемый «keyfile» — можно записать на USB-накопитель, который будет храниться в безопасном месте и подключаться к компьютеру только при необходимости смонтировать зашифрованные части диска (например, во время загрузки или при входе в систему).

Хранение в защищённой паролем форме на само́м диске

Мастер-ключ (и, соответственно, зашифрованные данные) можно защитить паролем, который нужно будет запомнить и вводить каждый раз, когда нужно будет смонтировать блочное устройство или папку с шифрованием. Подробности описаны в разделе #Метаданные шифрования ниже.

Случайная генерация на лету для каждого сеанса

Иногда, например, при шифровании подкачки или раздела /tmp, нет необходимости хранить постоянный мастер-ключ. Можно генерировать новый случайный ключ для каждого нового сеанса без вмешательства пользователя. Это означает, что после размонтирования все файлы, записанные в такой раздел, не смогут быть расшифрованы никем — что в данных конкретных случаях вполне нормально.

Метаданные шифрования

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

Обычно применяется так называемое «растяжение ключа» («key stretching») к паролю с помощью «функции формирования ключа» («key derivation function»), и полученный таким образом ключ используется для дешифровки главного мастер-ключа (который ранее хранился в зашифрованном виде): 

 ╭┈┈┈┈┈┈┈┈╮                             ╭┈┈┈┈┈┈╮
 ┊ пароль ┊━━━━━⎛     функция      ⎞━━━▶┊ ключ ┊
 ╰┈┈┈┈┈┈┈┈╯  ,──⎝формирования ключа⎠    ╰┈┈┬┈┈┈╯
 ╭──────╮   ╱                              │
 │ соль │──´                               │
 ╰──────╯                                  │
 ╭───────────────────────────╮             ▼          ╭┈┈┈┈┈┈┈┈┈┈┈┈┈╮
 │ зашифрованный мастер-ключ │━━━━━━━━(дешифровка)━━━▶┊ мастер-ключ ┊
 ╰───────────────────────────╯                        ╰┈┈┈┈┈┈┈┈┈┈┈┈┈╯

Функция формирования ключа (например, PBKDF2 или scrypt) специально делается медленной (она применяет много итераций хэш-функции, например, 1000 итераций HMAC-SHA-512), так что узнать пароль путём перебора всех возможных вариантов становится невозможно в разумное время. При обычном использовании эта функция выполняется всего один раз, так что медленная её работа не является проблемой. Также в качестве аргумента функции передаётся дополнительный кусочек данных, так называемая «соль» — она генерируется случайным образом один раз во время начальной настройки шифрования диска и хранится в открытом виде как часть метаданных. Поскольку в разных установках значение соли будет разным, её использование лишает злоумышленников возможности использовать предварительно подготовленные («радужные») таблицы, которые позволили ли бы ускорить подбор пароля, если бы соли не было.

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

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

Ещё один способ реализации двухфакторной аутентификации — дополнение описанной выше схемы получения ключа математическим «комбинированием» пароля с байтовыми данными, считываемыми из одного или нескольких внешних файлов (расположенных на USB-накопителе или подобных устройствах), перед передачей их в функцию формирования ключа. Файлы могут быть любыми, например, обычными изображениями в формате JPEG, что позволит применить #Правдоподобное отрицание. Однако в данном контексте они всё равно называются «файлами ключей».

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

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

                       ╭┈┈┈┈┈┈┈┈┈┈┈┈┈╮
                       ┊ мастер-ключ ┊
   файл на диске:      ╰┈┈┈┈┈┈┬┈┈┈┈┈┈╯
  ┌ ─ ─ ─ ─ ─ ─ ─ ─ ┐         │
  ╎╭───────────────╮╎         ▼          ╭┈┈┈┈┈┈┈┈┈┈┈┈╮
  ╎│ зашифрованный │━━━━(дешифровка)━━━━▶┊ ключ файла ┊
  ╎│ ключ файла    │╎                    ╰┈┈┈┈┈┬┈┈┈┈┈┈╯
  ╎╰───────────────╯╎                          │
  ╎┌───────────────┐╎                          ▼          ┌┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┐
  ╎│ зашифрованное │◀━━━━━━━━━━━━━━━━━━━━(де/шифровка)━━━▶┊ расшифрованное ┊
  ╎│ содержимое    │╎                                     ┊ содержимое     ┊
  ╎│ файла         │╎                                     ┊ файла          ┊
  ╎└───────────────┘╎                                     └┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┘
  └ ─ ─ ─ ─ ─ ─ ─ ─ ┘

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

При шифровании блочного устройства используется один мастер-ключ на устройство и, следовательно, на все данные. Некоторые методы позволяют создать несколько паролей для одного устройства, некоторые — нет. Некоторые используют вышеупомянутые функции для защиты мастер-ключа, а другие предоставляют полный контроль над безопасностью ключа пользователю. Два примера объясняются криптографическими параметрами, используемыми dm-crypt в plain или LUKS режимах.

При сравнении параметров, используемых обоими режимами, можно заметить, что plain-режим dm-crypt имеет параметры, относящиеся к расположению ключа (например, --keyfile-size, --keyfile-offset). Для LUKS они не нужны, поскольку каждое блочное устройство содержит в начале заголовок с метаданными. В заголовке указаны используемый алгоритм шифрования, сам зашифрованный мастер-ключ и параметры для функции формирования ключа. Последние, в свою очередь, задаются опциями при начальном шифровании мастер-ключа (например, --iter-time, --use-random).

Преимущества и недостатки различных техник можно узнать в сравнительной таблице или на конкретных страницах.

Смотрите также:

Алгоритмы и режимы шифрования

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

Для шифрования диска используются «блочные шифры», которые работают с блоками данных фиксированной длины, например, 16 байт (128 бит). На момент написания данной статьи наиболее распространёнными шифрами являются:

размер блока размер ключа комментарий
AES 128 бит 128, 192 или 256 бит одобрен АНБ для защиты информации «SECRET» и «TOP SECRET» правительства США (при использовании ключа размером 192 или 256 бит)
Blowfish 64 бита 32–448 бит один из первых беспатентных безопасных шифров, который стал общедоступным, поэтому очень хорошо зарекомендовал себя в Linux
Twofish 128 бит 128, 192 или 256 бит разработан как преемник Blowfish, но не получил столь широкого распространения
Serpent 128 бит 128, 192 или 256 бит Считается самым безопасным из пяти финалистов конкурса AES[10][11][12].

Шифрование/дешифрование сектора (#Базовый принцип) достигается путём разделения его на небольшие блоки, соответствующие размеру блока шифра, и следования определённому набору правил последовательного применения шифра к отдельным блокам (так называемый «режим шифрования»).

Простое применение шифра к каждому блоку отдельно без изменений (так называемый «режим электронной кодовой книги» — «electronic codebook (ECB)») не будет безопасным, так как если одни и те же 16 байт открытого текста будут всегда давать одни и те же 16 байт шифротекста, то злоумышленник сможет легко распознать паттерны в шифротексте, хранящемся на диске.

Самым простым (и распространённым) режимом шифрования, используемым на практике, является «режим сцепления блоков шифротекста» — «cipher-block chaining (CBC)». При шифровании сектора в этом режиме каждый блок данных открытого текста объединяется математическим способом с шифротекстом предыдущего блока перед его шифрованием. Для первого блока, так как перед ним нет предыдущего блока, используется специальный предварительно сгенерированный блок данных, хранящийся вместе с криптографическими метаданными сектора и называемый «вектор инициализации» — «initialization vector (IV)»: 

                                          ╭─────────────╮
                                          │вектор       │
                                          │инициализации│
                                          ╰───────┬─────╯
                 ╭  ╠══════════╣       ╭─ключ     │      ┣┉┉┉┉┉┉┉┉┉┉┫
                 │  ║          ║       ▼          ▼      ┋          ┋         . СТАРТ
                 ┴  ║"????????"║◀━━━(шифр)━━━━━━━(+)━━━━━┋"Привет, "┋ блок   ╱╰────┐
           сектор n ║          ║                         ┋          ┋ 1      ╲╭────┘
     в файле или на ║          ║──────────────────╮      ┋          ┋         '
 блочном устройстве ╟──────────╢       ╭─ключ     │      ┠┈┈┈┈┈┈┈┈┈┈┨
                 ┬  ║          ║       ▼          ▼      ┋          ┋
                 │  ║"????????"║◀━━━(шифр)━━━━━━━(+)━━━━━┋"мир !!! "┋ блок
                 │  ║          ║                         ┋          ┋ 2
                 │  ║          ║──────────────────╮      ┋          ┋
                 │  ╟──────────╢                  │      ┠┈┈┈┈┈┈┈┈┈┈┨
                 │  ║          ║                  ▼      ┋          ┋
                 :  :   ...    :        ...      ...     :   ...    : ...

                      шифротекст                         открытый текст
                        на диске                         в памяти

При дешифровке процедура аналогичная, только в обратном порядке.

Стоит обратить внимание на генерацию уникального вектора инициализации для каждого сектора. Самый простой вариант — вычислить его предсказуемым образом из легкодоступного значения, такого как номер сектора. Однако это может позволить злоумышленнику с постоянным доступом к системе выполнить watermarking attack. Чтобы предотвратить это, можно использовать метод под названием «Encrypted salt-sector initialization vector (ESSIV)» для генерации векторов инициализации таким образом, чтобы для потенциального злоумышленника они выглядели совершенно случайными.

Существует также ряд других, более сложных режимов для шифрования дисков, которые имеют встроенную защиту от таких атак (и, следовательно, не требуют ESSIV). Некоторые из них также могут дополнительно гарантировать подлинность зашифрованных данных (то есть подтвердить, что они не были изменены/повреждены кем-то, кто не имеет доступа к ключу).

Смотрите также:

Правдоподобное отрицание

Смотрите Wikipedia:ru:Правдоподобное отрицание.

Сценарии резервного копирования зашифрованного диска

Создавайте резервные копии пользовательских данных, чтобы не потерять их. Как правило, резервная копия зашифрованных данных также должна быть зашифрована.

Шифрование блочного устройства

Есть несколько вариантов; можно создать резервную зашифрованного блочного устройства в виде образа, например, /dev/sdx, или создать резервную копию файловой системы внутри зашифрованного контейнера, например, /dev/mapper/dm_name, или создать резервную копию файлов, например, с помощью rsync. В следующих разделах описаны преимущества и недостатки каждого варианта.

Резервное копирование блочного устройства

Резервная копия блочного устройства:

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

Резервное копирование файловой системы или файлов

Резервная копия файловой системы или файлов:

  • не зашифрована как есть
  • должна быть зашифрована перед передачей по сети или при сохранении на диск, что требует дополнительных усилий
  • не обязательно шифруется с тем же уровнем безопасности, что и рабочая копия
  • не содержит заголовок LUKS
  • может занимать лишь столько места, сколько занято в файловой системе; смотрите, например, partclone
  • позволяет использовать расширенные стратегии резервного копирования, такие как инкрементное резервное копирование, сжатие или дедупликация
  • требует ручного восстановления контейнера шифрования на новый диск, например, путём восстановления резервной копии заголовка LUKS

Резервное копирование заголовка LUKS

При использовании LUKS можно выполнить резервное копирование заголовков LUKS: может иметь смысл периодически проверять и синхронизировать эти резервные копии, особенно если выполнялся отзыв паролей.

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