ПаранойяО шифровании разделов винчестера с использованием ключа на USB-флешке на *ubuntu и debian

В установщике alternate-дистрибутива *ubuntu и debian есть возможность зашифровать раздел, но только паролем.
В инете я нашёл статью о шифровании с возможностью хранить ключ на флешке, но, к сожалению, с таким шифрованием система неправильно выходила из спящего режима — она просто запускалась с нуля, а не просыпалась в старое состояние.
В этой статье я расскажу, как сделать так, чтобы и шифрование было с ключом на USB-флешке, и спящий режим (hibernate) оставался работоспособным.
Неправильный выход из спящего режима происходил потому, что подключение swap-раздела происходило на слишком позднем этапе загрузки (а именно в swap сохраняется состояние системы при уходе в спящий режим). А слишком позднее подключение swap-раздела в свою очередь происходило поздно потому, что этот раздел зашифрован (а это обязательно, т.к. в памяти лежат ключи к подключённым зашифрованным разделам, и они могут попасть в swap, соответственно его тоже нужно шифровать).

  1. Итак, я начал с установки системы с alternate-диска ubuntu с обычным шифрованием (по паролю). Для debian тут подойдёт его стандартный установщик, т.к. он тот же, что и у ubuntu в alternate-диске.
    Я сделал шифрованный раздел, в нём LVM, а в нём раздел для /home и swap. Можно шифровать хоть корень, главное, чтобы был отдельный раздел /boot.
    На этом этапе установщик настраивает всё для работы шифрования и спящего режима.
  2. Делаем файл с ключом:
    # dd if=/dev/random of=/путь/к/файлу/с/ключом/на/флешке bs=1 count=256<br />
    Кстати, на флешке может быть только EXT3 или FAT. Другие ФС скрипт, который достаёт ключи на этапе загрузки (п7), не понимает.
    Ключу лучше назначить права 0400, иначе будет ругаться на безопасность.
  3. После этого в рабочей системе меняем парольный ключ на файловый с флешки:
    # cryptsetup luksAddKey /dev/наш_шифрованный_раздел /путь/к/файлу/с/ключом/на/флешке
  4. Проверяем количество ключей нашего раздела:
    # cryptsetup luksDump /dev/sda2<br />
    Должно быть два key slot'а, которые «ENABLED». Нулевой — это старый с паролем, первый — это наш новый с ключом в файле.
  5. Удаляем старый ключ:
    # cryptsetup --key-file /путь/к/файлу/с/ключом/на/флешке luksKillSlot /dev/наш_шифрованный_раздел 0
  6. Проверяем так же, как в п4, но теперь должен остаться только один key slot, который «ENABLED».
    Собственно сам ключ мы сменили, теперь нужно донастроить систему так, чтобы всё монтировалось как надо и спящий режим работал.
  7. В /etc/crypttab меняем запись о нашем зашифрованном разделе:
    Вместо none пишем путь к файлу ключа в таком вот виде: :
    Путь к устройству флешки берём так: идём /dev/disk/by-uuid/ и видим кучу ссылок с длинными буквоцифренными именами. Все эти ссылки ссылаются на винчестеры/флешки/.., и их разделы, которые есть в нашей системе. А имена их — это UUID'ы (типа уникального серийного номера). В результате путь вида "/dev/disk/by-uuid/7a5f666f-f018-4c29-b5b6-5ebecc777bf8" будет всегда указывать на один и тот же раздел моей флешки куда бы я её не воткнул. А чтобы злоумышленник смог её подменить, ему нужно, чтобы раздел на его флешке имел точно такой же UUID (правда, это не сложно). Если вы хотите, чтобы ваша флешка идентифицировалась не по UUID, а, например, по label раздела, тогда вам в /dev/disk/by-label. А если по имени устройства (например: ata-Hitachi_HTS541616J9AT00_SB0442SJEGB1RH), то в /dev/disk/by-id/.
    В результате должен получиться примерно такой путь:
    /dev/disk/by-uuid/7a5f666f-f018-4c29-b5b6-5ebecc777bf8:/keys/my.key<br />
    После опции «luks» добавляем путь к скрипту, который при загрузке в initramfs будет доставать наш ключ: keyscript=/lib/cryptsetup/scripts/passdev.
    В результате получим что-то вроде этого:
    sda2_crypt /dev/disk/by-uuid/731993e3-acd4-4ce8-9a5b-ccf8e5d074ef /dev/disk/by-uuid/7a5f666f-f018-4c29-b5b6-5ebecc777bf8:/keys/my.key luks,keyscript=/lib/cryptsetup/scripts/passdev
  8. Обновляем initramfs командой:
    # update-initramfs -u
  9. Перезагружаемся и наблюдаем, как всё монтируется автоматом при наличии флешки и не показывает даже сообщений об ошибке при её отсутствии (не знаю почему, но, ИМХО, так даже лучше =)).

UPD:
после примерно 4-х месяцев использования докладываю: всё работает, ничего не сломалось, остаётся только одна проблема: относительно большая нагрузка от шифрования — при интенсивном чтении/записи до трети моего celeron'а 1.4 ГГц.
На процессорах с аппаратной поддержкой aes (это Core2Duo и более поздние процы) вообще не заметно нагрузки от шифрования диска.

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

UPD: systemd не умеет passdev, поэтому при обновлении debian до 8, надо остаться на sysvinit (как это сделать написано в официальной информации о выпуске), а при чистой установке, соответственно, перейти с systemd на sysv.
  • +7
  • Q2W
  • 23 января 2010, 14:38

Комментарии (6)

Прелестно! В мемориз.
  • avatar
  • SPU
  • 23 января 2010, 19:58
  • #
  • 2
Хочу прокомментировать не в критику поста, а на счет шифрования дисков вообще.

Смысл шифрования и его стойкости в том, что НЕИЗВЕСТНО что именно зашифровано, в этом случае поможет только брутфорс. В случае шифрования диска задача нахождения ключа (пусть и длиной 256 символов) очень сильно упрощается, т.к. содержимое огромного количества файлов в фаловой системе известно (сама операционка), плюс точно известны сайфер и хэш-функция.
Получается отпугивалка для детей, а не реальная защита данных.
Ну, во-первых, я специально шифрую не всю систему от корня, а только /home, а там известно гораздо меньше.

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

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

Я, правда, не эксперт в криптографии, если что =)
Конечно не тупой xor :) Там в статье по ссылке написано:
Ciper name: aes
Cipher mode: cbc-essiv:sha256
Hash spec: sha1
Т.е. при попытке расшифровки алгоритм либо полностью известен, либо выбирается из очень ограниченного списка типовых. Пусть сам алгоритм и не такой простой, как xor, но, обладая информацией о части зашифрованного содержимого, можно если не полностью восстановить ключ, то по крайней мере существенно сократить диапазон для перебора. Размер ключа тут не очень важен, его длина больше влияет на скорость работы с зашифрованным диском.
Единственное, что может действительно усложнить расшифровку — это сохранение информации о алгоритме шифрования вместе с ключом, а сам алгоритм, естественно, тоже должен быть какой-то случайной последовательностью случайной длины более простых (типовых) алгоритмов, причем ключи для стыковки между ними тоже должны быть случайными. Но быстро это работать точно не будет :)
Пусть сам алгоритм и не такой простой, как xor, но, обладая информацией о части зашифрованного содержимого, можно если не полностью восстановить ключ, то по крайней мере существенно сократить диапазон для перебора.

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

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

По-моему, как раз-таки очень важен.
Вот представьте, что Вам известен 1Кб идущих подряд данных в зашифрованном (путь xor'ом) хранилище. Так вот мы можем рас'xor'ить ключ размером до килобайта этими известными данными.
А если ключ 2 Мб, то нам надо найти известный кусок идущих подряд данных.

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

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

Но быстро это работать точно не будет :)

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

А вообще, если Вы знаете, как убрать из зашифрованного тома инфу об алгоритме шифрования и длине ключа, было бы очень интересно.

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