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

Введение

Шифрование дисков будем производить стандартными средствами Ubuntu, причем ключ шифрования, как и раздел /boot, будет вынесен на сменный накопитель. Но зачем шифровать корневой раздел? Ведь можно зашифровать только /home? На то есть несколько причин. Первая — на основе конфигурационных файлов из /etc можно извлечь некоторую информацию, пускай даже она не относится к конфиденциальным данным. Вторая же — если вдруг содержимым диска заинтересуются, ты всегда сможешь сказать, что все так и было и что диск уже был забит псевдослучайными данными. Итак, что для этого понадобится?

• Флешка с MBR
• Ubuntu 12.10
• Чистый жесткий диск

В качестве алгоритма шифрования дисков будем использовать AES, поскольку он принят как стандарт и криптостоек, а в качестве средства — cryptsetup/LUKS. Чтобы иметь возможность добавить свободное место поверх зашифрованного тома, задействуем логические тома (LVM).

Создание шифрованного тома

Загрузившись с LiveCD, необходимо подготовить флешку: создать на ней второй раздел, где будет размещен /boot и ключ шифрования. Создавая раздел /boot с ФС ext2 вторым, мы убиваем двух зайцев — первый раздел будет виден во всех системах, и на нем можно хранить данные, а второй из Windows так просто не увидишь, что прибавляет неудобства любопытствующим. Для разбиения я использовал gparted, но тебе никто не мешает использовать, например, fdisk. После этого нужно подмонтировать новосозданный раздел и сгенерировать ключевой файл:

# mkdir /mnt/boot /mnt/flash # mount /dev/sdf1 /mnt/flash # mount /dev/sdf2 /mnt/boot # dd if=/dev/random of=/mnt/boot/key.bin bs=32 count=1

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

# dd if=/dev/random of=/mnt/boot/key.bin bs=1 count=512

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

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

# dd if=/dev/urandom of=/dev/sdd bs=8M

Заполнение необходимо, чтобы уменьшить вероятность успеха криптоанализа, если он будет производиться. Эта операция занимает довольно длительное время, поэтому запасись терпением. И только теперь уже можно запускать утилиту cryptsetup. Инициализируем диск в формате LUKS:

# cryptsetup -h=sha256 -c=aes-cbc-essiv:sha256 -s=256 luksFormat /dev/sdd /mnt/boot/key.bin

Разберем, что делает эта команда. Первый ключ указывает тип хеш-функции, которая будет использоваться для хеширования мастер-ключа. Второй ключ указывает алгоритм и тип шифрования. На этом я остановлюсь чуть подробнее. Что такое CBC? Как известно, AES — блочный шифр, который оперирует блоками по 128, 192 или 256 бит. Но, как правило, шифруют гораздо большие объемы информации. И возникает проблема — как шифровать, чтобы не было видно неслучайного распределения, из которого криптоаналитик может извлечь информацию. Умные люди решили ее таким образом: в первом блоке находится IV — случайный набор битов. И каждый последующий блок открытых данных XOR’ится с предыдущим блоком уже зашифрованных данных. Все вроде хорошо, но в случае шифрования дисков такая схема, по понятным причинам, неприменима (ты же не будешь ждать каждый раз по 10–20 минут, пока система расшифровывает нужный тебе участок?). В LUKS для решения проблемы произвольного доступа к информации применяется ESSIV — шифруются относительно небольшие блоки данных (посекторно), а вектор инициализации генерируется на основе номера сектора и хеша ключа. Такая схема также защищает от некоторых криптоатак. В частности, поэтому я и использую LUKS. Подтвердив свои намерения после запуска предыдущей команды, создаем отображение LUKS-устройства:

# cryptsetup -d=/mnt/boot/key.bin luksOpen /dev/sdd cryptodisk

Первый этап подготовки завершен — теперь в каталоге /dev/mapper появилось устройство cryptodisk, с которым можно обращаться, как с обычным диском.

Создаем LVM поверх шифрованного тома

В принципе, теперь можно на вновь созданный криптодиск ставить Ubuntu, но, как я уже писал, чтобы получить возможность увеличить место, поверх него лучше создать том LVM, что мы и сделаем. Проинициализируем физический том и создадим группу томов:

# pvcreate /dev/mapper/cryptodisk # vgcreate vg /dev/mapper/cryptodisk

Теперь в этой группе создадим логические тома:

# lvcreate -L1G -nswap vg # lvcreate -L6G -nroot vg # lvcreate -l 100%FREE -nhome vg

Теперь можно форматировать их в файловые системы. Ты волен выбирать сам, я же использовал как для корневого тома, так и для vg-home старую добрую ext4 — на мой взгляд, мы и так слишком накрутили, чтобы использовать более новые ФС:

# mkswap /dev/mapper/vg-swap # mkfs.ext4 /dev/mapper/vg-root # mkfs.ext4 /dev/mapper/vg-home

Подготовка почти завершена — теперь надо бы записать UUID дисков и разделов, для чего выполни следующую команду:

# ls -l /dev/disk/by-uuid/ >/mnt/flash/by-uuid.txt

Нам осталось «всего лишь» установить Ubuntu на нешифрованный раздел/диск и перенести ее на шифрованный.

Подготовка и перенос Ubuntu

Теперь ставим на нешифрованный диск Ubuntu — конфигурацию делай по своему вкусу за исключением размещения /boot и загрузчика. Их необходимо поместить на флешке, где ты заблаговременно создал соответствующий раздел. После этого загружаемся с флешки, чтобы проверить, все ли встало корректно, устанавливаем с помощью apt-get пакеты lvm2 и cryptsetup — они удалились автоматически после установки Ubuntu — и добавляем/изменяем строчки /etc/fstab. Должно получиться нечто подобное (за исключением строчек с псевдофайловыми системами, которых, впрочем, в современных системах нет):

/etc/fstab UUID=dd7ca139-074a-4b1b-a116-3a42feab7459 /boot ext2 defaults 0 2 /dev/mapper/vg-root / ext4 errors=remount-ro 0 1 /dev/mapper/vg-home /home ext4 defaults 0 1 /dev/mapper/vg-swap none swap sw 0 0

Раздел /boot мы монтируем по UUID для того, чтобы при добавлении новых дисков не возникла путаница с их именами. Теперь идем в файл /etc/crypttab, он у нас примерно следующего содержания:

cryptodisk UUID=c34e4c91-1fa1-4802-88ca-9c3be5c99097 /boot/key.bin luks,cipher=aes-cbc-essiv:sha256

Далее нужно изменить initrd. В файл /etc/initramfs-tools/modules добавляем строчку:

dm_crypt

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

/etc/initramfs-tools/hooks/cryptokeys ... . /usr/share/initramfs-tools/hook-functions

Создаем каталог в образе initramfs

mkdir ${DESTDIR}/etc/crypto

Копируем ключ и cryptsetup

cp /boot/key.bin ${DESTDIR}/etc/crypto copy_exec /sbin/cryptsetup /sbin

И собственно скрипт для подключения криптодиска (выполняется во время загрузки initrd):

/etc/initramfs-tools/scripts/local-top/cryptokeys ... modprobe -b dm_crypt  while ! /sbin/cryptsetup -d=/etc/crypto/key.bin luksOpen /dev/disk/by-uuid/c34e4c91-1fa1-4802-88ca-9c3be5c99097 cryptodisk; do echo "Try again..." done

Цикл while необходим, если в дальнейшем ты добавишь разблокировку тома по паролю. Оба скрипта должны быть выполняемыми, иначе следующая команда их не увидит и будет создавать стандартный образ. Теперь можно давать команду обновления initrd:

# update initrd -u -k all -v

Мы чуть было не забыли про конфиг загрузчика. Имеется два пути его правки: один простой но неправильный — прямое редактирование файла /boot/grub/grub.cfg, второй тоже простой, но на сей раз верный. Некорректность первого способа в том, что при каждом обновлении ядра конфиг перезаписывается с использованием скриптов из /etc/grub.d/. Мы же пойдем другим путем — добавим скрипт, который как раз и будет генерировать правильные строчки в реальном грабовском конфиге. Однако есть одно «но» — при обновлении ядра тебе придется либо менять его каждый раз, либо оставаться на старом (последнее, на мой взгляд, предпочтительнее — см. врезку). Вот так примерно выглядят его строчки:

/etc/grub.d/40_custom menuentry "Ubuntu crypto" { recordfail=1 if [ -n ${have_grubenv} ]; then save_env recordfail; fi set quiet=1 insmod part_msdos insmod ext2 insmod gzio

UUID берем из заранее записанного файла

search --no-floppy --fs-uuid --set=root dd7ca139-074a-4b1b-a116-3a42feab7459

Раздел /boot для Grub считается корневым, поэтому пути к ядру и образу initrd указываются относительно его

linux /vmlinuz-3.5.0-17-generic root=/dev/mapper/vg-root ro initrd /initrd.img-3.5.0-17-generic }

После редактирования этого файла необходимо изменить строчку еще одного файла — /etc/default/grub с тем, чтобы при загрузке данный пункт меню выбирался по умолчанию. Для этого воспользуемся sed’ом.

# sed 's/GRUB_DEFAULT=0/GRUB_DEFAULT="Ubuntu crypto"/g' -i /etc/default/grub

По желанию можно выключить ненужные тебе пункты меню. Для этого просто сними право выполнения со всех ненужных скриптов в /etc/grub.d/. Теперь можно обновить основной конфиг:

# update-grub

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

# cp -r --preserve=all /mnt/uncrypted/* /mnt/vg-root/ # cp -r --preserve=all /mnt/uncrypted/home/* /mnt/vg-home/

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

Добавление/изменение ключей

Допустим, тебе понадобилось изменить ключ — ты его скомпрометировал или просто создал политику смены и хочешь ей неукоснительно следовать. Что для этого нужно? Прежде всего сделать резервную копию заголовка тома LUKS — если все будет нормально, после смены ключа ты ее сможешь уничтожить. Делаем мы ее, понятно, на нешифрованный раздел:

# mount /dev/sdf1 /mnt/flash # cryptsetup luksHeaderBackup /dev/disk/by-uuid/c34e4c91-1fa1-4802-88ca-9c3be5c99097 --header-backup-file /mnt/flash/luksHeader.bin

После этого сделаем копию файла ключа (просто скопируем его) и сгенерируем новый ключ:

# dd if=/dev/random of=/boot/new_key.bin bs=1 count=512

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

# cryptsetup luksDump /dev/disk/by-uuid/c34e4c91-1fa1-4802-88ca-9c3be5c99097

Добавляем новый ключ в систему:

# cryptsetup luksAddKey /dev/disk/by-uuid/c34e4c91-1fa1-4802-88ca-9c3be5c99097 /boot/new_key.bin --key-file /boot/key.bin

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

# mv /boot/new_key.bin /boot/key.bin # update-initramfs -u

Перезагружаемся, чтобы убедиться, что мы ничего не сломали, и удаляем старый ключ:

# cryptsetup luksKillSlot /dev/disk/by-uuid/c34e4c91-1fa1-4802-88ca-9c3be5c99097 0 --key-file /boot/key.bin

Снова перезагружаемся. Если и в этот раз все в порядке, с облегчением вздыхаем. Мы успешно сменили ключ.

Восстановление доступа к закриптованному тому

Предположим, ты потерял ключ. Что делать? Главным образом — не паниковать. Если у тебя есть резервная копия заголовка и ключ, который ты применял до ее создания, но ты не можешь загрузиться с него, то для восстановления доступа производим следующее. Грузимся с LiveCD и монтируем носитель с бэкапом. После этого восстанавливаем заголовок:

# cryptsetup luksHeaderRestore /dev/sdd --header-backup-file /mnt/flash/luksHeader.bin

Подключаем шифрованный том с использованием резервной копии старого ключа:

# cryptsetup -d=/mnt/flash/old_key.bin luksOpen /dev/sdd cryptodisk

И производим восстановительные работы (чрутимся, пробрасываем каталог с резервной копией, монтируем /boot, копируем резервную копию ключа в /boot/key.bin и обновляем initramfs). Перезагружаемся — все готово. Но что, если ты каким-то непостижимым образом затер все свои кейслоты и у тебя нет резервных копий заголовка? Если ты после этого еще и перезагрузился, могу тебя поздравить — твои данные невосстановимы. Если же ты не перезагрузился… что ж, есть шанс, что тебе удастся восстановить том. Для этого тебе прежде всего необходимо извлечь мастер-ключ, который хранится в памяти:

# dmsetup table --target crypt --showkey /dev/mapper/cryptodisk

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

# cat master-key.txt | xxd -r -p >master-key.bin

Размер файла master-key.bin в случае тех параметров создания криптотома, которые использовались в статье, должен составлять 32 байта. После извлечения мастер-ключа ты должен загрузиться с LiveCD и проинициализировать том заново с использованием данного мастер-ключа и твоего нового ключа шифрования — надеюсь, как его генерировать, описывать не надо:

# cryptsetup -h=sha256 -c=aes-cbc-essiv:sha256 -s=256 luksFormat /dev/sdd /mnt/boot/key.bin --master-key-file=/mnt/flash/master-key.bin

Производим процедуры по восстановлению, описанные чуть выше.

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

Package: linux-generic linux-headers-generic linux-image-generic linux-restricted-modules-generic Pin: version 3.5.0-17.28 Pin-Priority: 1001