Category: Хранение информации

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

Также, важно заметить, что вам потребуется операционная система на базе GNU/Linux (дистрибутив). Никаких дополнительных конфигурационных шагов кроме установки ОС вам совершать не придётся.

Начнём с основ. Для шифрования носителя (диска) мы будем использовать dm-crypt. Сам dm-crypt является де-факто «фундаментом» для прочих инструментов шифрования вроде LUKS, но его также можно использовать «напрямую», что мы и будем делать.

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

Из этого вытекает и основной минус: без «оглавления», которое обычно хранит все параметры за вас, вам нужно их запоминать (или хранить — об этом позже) самостоятельно.

Кроме этого, в dm-crypt нет «функции вычисления ключа» (KDF), как, например, в LUKS, а ваш «секрет» (пароль или ключевой файл) используется как ключ напрямую. Из-за этого вам необходимо использовать сгенерированный пароль, а не «придумывать» самостоятельно. В том числе и потому, что человек попросту не способен создавать достаточно «стойкие» комбинации.

Проехавшись по «основам», можно приступать к основной части. Как инструмент мы будем использовать утилиту cryptsetup, которая идёт предустановленной в абсолютном большинстве дистрибутивов Linux. Кроме этого, вам будут необходимы права суперпользователя (sudo su или su - root).

В первую очередь, определите имя вашего диска (он же block device) в системе:

lsblk

Если это новый диск, то скорее всего вы увидите одну строчку, как пример /dev/sdX (для устройств S/ATA) или /dev/nvme0nX (для дисков NVME), без разделов (/dev/sdX1) и с определённым количеством места. Именно системное имя блокового устройства мы будем использовать как «ярлык» в дальнейшем.

Определив свой «целевой» диск, теперь надо определиться с параметрами шифрования. У вас на выбор есть три шифра:

• Rijndael (AES)
• Serpent
• Twofish

Интернет-ресурс «Может, вам повезёт?» рекомендует использовать именно Serpent и не рекомендует использовать AES. В том числе и потому, что Serpent более совершенен и не имеет даже теоретических способов его атаковать.

Далее необходимо выбрать алгоритм хэширования вашего «секрета» (пароля). У вас на выбор есть два кандидата:

• Secure Hashing Algorithm (SHA) 512
• Whirlpool

Вам стоит использовать именно SHA-512, если нет предпочтения в сторону «европейских решений», к которым относится Whirlpool.

В последнюю очередь необходимо выбрать вектор инициализации. Из «вариантов»:

Если вас сильно «заботит» производительность, выбирайте plain64. «Может, вам повезёт?» же рекомендует выбирать essiv:sha256.

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

{шифр}-xts-{вектор инициализации} --hash {хэш} --key-size 512

Важно: параметр --key-size можно уменьшить, но так как режим работы XTS (ciphertext stealing) «съедает» половину длины ключа, фактически 512 битов равняется 256. Делать же это крайне не рекомендуется.

Рекомендуемые интернет-ресурсом «Может, вам повезёт?» параметры:

serpent-xts-essiv:sha256 --hash sha512 --key-size 512

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

Далее вам необходимо инициализировать диск через утилиту cryptsetup с выбранными вами параметрами:

cryptsetup open --type plain --cipher {ваши параметры} {путь к блоковому устройству диска, т. е. /dev/sdX} crypt

Эта же команда будет использоваться для расшифровки диска в дальнейшем.

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

Как вариант — для этого можно использовать утилиту KeepassXC, которая имеет встроенный генератор паролей и вполне подходит для такого рода «задач».

Главное — задайте сложный пароль для базы данных (от 32 символов и выше), а также храните её на отдельном неприметном носителе (классика — «флешка» в каком-либо труднодоступном месте).

Касательно длинны пароля, можно ставить все 128 символов. При полном наборе знаков без учёта расширенного ASCII это даст вам около 800 битов энтропии. «Мелочиться» смысла нет, ведь вы этот пароль «руками» вводить не будете.

После успешной инициализации контейнера он будет доступен по пути /dev/mapper, как пример — /dev/mapper/crypt. Дабы начать использовать контейнер, вам необходимо создать файловую систему:

mkfs.ext4 /dev/mapper/crypt

Вместо ext4 можно использовать btrfs:

mkfs.btrfs /dev/mapper/crypt

Если вам важна целостность данных, выбирайте btrfs. В остальных случаях файловой системы ext4 должно хватить.

Примонтируйте контейнер:

mount --mkdir /dev/mapper/crypt /media/crypt

В большинстве случаев по умолчанию ваш пользователь не сможет изменять файловую систему. Задайте нужные права доступа:

chown -R {имя пользователя} /media/crypt

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

umount /media/crypt
cryptsetup close crypt

Если вы задали своё имя контейнера, замените crypt на собственное.

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

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

На это накладываются особенности современных дисков — если в классических жёстких дисках файл можно удалить простой перезаписью секторов, ведь есть чёткое понимание, куда этот файл записан, то в современных SSD, eMMC и прочих носителях flash-памяти такая «перезапись» просто «убьёт» диск.

Дело в том, что «ячейки» flash-памяти имеют ограниченный ресурс, и могут попросту «посыпаться» от выработки циклов записи/перезаписи. Для того, чтобы ОС часом не «угробила» носитель, в каждом условном SSD существует контроллер с технологией Wear Leveling — то есть, вместо записи файла в одно «место», как это делается в жёстких дисках, контроллеры SSD «разносят» файл по всей поверхности.

Отсюда и название — распределение нагрузки. Проблема в том, что ОС не понимает, куда на самом деле записана информация, а следовательно не может перезаписать «удаленный» файл. Это приводит к тому, что любой мало-мальский криминалист или «продвинутый» пользователь ПК может «вытащить» удаленный файл даже из «скрытой» области SSD, которая предназначена для замены «поврежденных» ячеек.

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