Паранойя →
Ричард Столлман назвал Facebook системой слежения
Не забудьте "лайкнуть". ;-)
- +2
- fog
- 25 января 2012, 09:44
- blogs.computerra.ru/22561
- 2
Паранойя → О шифровании разделов винчестера с использованием ключа на USB-флешке на *ubuntu и debian
В установщике alternate-дистрибутива *ubuntu и debian есть возможность зашифровать раздел, но только паролем.
В инете я нашёл статью о шифровании с возможностью хранить ключ на флешке, но, к сожалению, с таким шифрованием система неправильно выходила из спящего режима — она просто запускалась с нуля, а не просыпалась в старое состояние.
В этой статье я расскажу, как сделать так, чтобы и шифрование было с ключом на USB-флешке, и спящий режим (hibernate) оставался работоспособным.
Неправильный выход из спящего режима происходил потому, что подключение swap-раздела происходило на слишком позднем этапе загрузки (а именно в swap сохраняется состояние системы при уходе в спящий режим). А слишком позднее подключение swap-раздела в свою очередь происходило поздно потому, что этот раздел зашифрован (а это обязательно, т.к. в памяти лежат ключи к подключённым зашифрованным разделам, и они могут попасть в swap, соответственно его тоже нужно шифровать).
UPD: после примерно 4-х месяцев использования докладываю: всё работает, ничего не сломалось, остаётся только одна проблема: относительно большая нагрузка от шифрования — при интенсивном чтении/записи до трети моего celeron'а 1.4 ГГц.
На процессорах с аппаратной поддержкой aes (это Core2Duo и более поздние процы) вообще не заметно нагрузки от шифрования диска.
UPD: на хабре выложили очень похожую схему шифрования, но с целью шифровать сервер. Ценная мысль — ключ от сервера лучше всего держать где-то в интернетах, а если сервер заберут, ключ там можно испортить/удалить. Правда, не решена проблема с нагрузкой от шифрования, что для серверов весьма критично чаще всего.
UPD: systemd не умеет passdev, поэтому при обновлении debian до 8, надо остаться на sysvinit (как это сделать написано в официальной информации о выпуске), а при чистой установке, соответственно, перейти с systemd на sysv.
В инете я нашёл статью о шифровании с возможностью хранить ключ на флешке, но, к сожалению, с таким шифрованием система неправильно выходила из спящего режима — она просто запускалась с нуля, а не просыпалась в старое состояние.
В этой статье я расскажу, как сделать так, чтобы и шифрование было с ключом на USB-флешке, и спящий режим (hibernate) оставался работоспособным.
Неправильный выход из спящего режима происходил потому, что подключение swap-раздела происходило на слишком позднем этапе загрузки (а именно в swap сохраняется состояние системы при уходе в спящий режим). А слишком позднее подключение swap-раздела в свою очередь происходило поздно потому, что этот раздел зашифрован (а это обязательно, т.к. в памяти лежат ключи к подключённым зашифрованным разделам, и они могут попасть в swap, соответственно его тоже нужно шифровать).
- Итак, я начал с установки системы с alternate-диска ubuntu с обычным шифрованием (по паролю). Для debian тут подойдёт его стандартный установщик, т.к. он тот же, что и у ubuntu в alternate-диске.
Я сделал шифрованный раздел, в нём LVM, а в нём раздел для /home и swap. Можно шифровать хоть корень, главное, чтобы был отдельный раздел /boot.
На этом этапе установщик настраивает всё для работы шифрования и спящего режима. - Делаем файл с ключом:
Кстати, на флешке может быть только EXT3 или FAT. Другие ФС скрипт, который достаёт ключи на этапе загрузки (п7), не понимает.# dd if=/dev/random of=/путь/к/файлу/с/ключом/на/флешке bs=1 count=256<br />
Ключу лучше назначить права 0400, иначе будет ругаться на безопасность. - После этого в рабочей системе меняем парольный ключ на файловый с флешки:
# cryptsetup luksAddKey /dev/наш_шифрованный_раздел /путь/к/файлу/с/ключом/на/флешке - Проверяем количество ключей нашего раздела:
Должно быть два key slot'а, которые «ENABLED». Нулевой — это старый с паролем, первый — это наш новый с ключом в файле.# cryptsetup luksDump /dev/sda2<br /> - Удаляем старый ключ:
# cryptsetup --key-file /путь/к/файлу/с/ключом/на/флешке luksKillSlot /dev/наш_шифрованный_раздел 0 - Проверяем так же, как в п4, но теперь должен остаться только один key slot, который «ENABLED».
Собственно сам ключ мы сменили, теперь нужно донастроить систему так, чтобы всё монтировалось как надо и спящий режим работал. - В /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/.
В результате должен получиться примерно такой путь:
После опции «luks» добавляем путь к скрипту, который при загрузке в initramfs будет доставать наш ключ: keyscript=/lib/cryptsetup/scripts/passdev./dev/disk/by-uuid/7a5f666f-f018-4c29-b5b6-5ebecc777bf8:/keys/my.key<br />
В результате получим что-то вроде этого:
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 - Обновляем initramfs командой:
# update-initramfs -u - Перезагружаемся и наблюдаем, как всё монтируется автоматом при наличии флешки и не показывает даже сообщений об ошибке при её отсутствии (не знаю почему, но, ИМХО, так даже лучше =)).
UPD: после примерно 4-х месяцев использования докладываю: всё работает, ничего не сломалось, остаётся только одна проблема: относительно большая нагрузка от шифрования — при интенсивном чтении/записи до трети моего celeron'а 1.4 ГГц.
На процессорах с аппаратной поддержкой aes (это Core2Duo и более поздние процы) вообще не заметно нагрузки от шифрования диска.
UPD: на хабре выложили очень похожую схему шифрования, но с целью шифровать сервер. Ценная мысль — ключ от сервера лучше всего держать где-то в интернетах, а если сервер заберут, ключ там можно испортить/удалить. Правда, не решена проблема с нагрузкой от шифрования, что для серверов весьма критично чаще всего.
UPD: systemd не умеет passdev, поэтому при обновлении debian до 8, надо остаться на sysvinit (как это сделать написано в официальной информации о выпуске), а при чистой установке, соответственно, перейти с systemd на sysv.