Насколько безопасно (в плане взлома) бэкапить (dd) шифрованый винт?

Автор AlexNikol, 23 июля 2018, 18:09:45

« назад - далее »

0 Пользователи и 2 гостей просматривают эту тему.

AlexNikol

Имеется комп с Debian. При установке, стандартными средствами зашифрован (насколько помню, aes-xts) винт (кроме /boot). Возникло желание делать, периодически, бэкапы. Наиболее удобный, лично для меня, вариант - весь винт, при помощи dd, в файл на внешнем винте большего размера. Однако, внешний винт не всегда с собой, а воришки (сильно мотивированныве спереть данные) могут оказаться в доме и тогда, когда там будут одновременно и комп и внешний винт. Соответственно, они получат оригинальные винт и его образ за некоторое время до последнего использования. Соответственно, могут найти некие блоки, которые были изменены в промежутке между бэкапом и последним использованием. Может ли это облегчить злоумышленникам доступ к зашифрованым данным? Может ли это облегчить "взлом шифрования"? Или можно использовать такую схему бэкапа, не боясь за данные?


Modigar

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

qupl

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

AlexNikol

Цитата: Modigar от 23 июля 2018, 19:57:22Стоимость дешифровки информации, явно сильно выше стоимости самой информации.
Для случая небэкапленого шифрованого винта, существующего в одном экземпляре, это верно. А если есть его слепок за некоторое время до последнего использования, то меняется ли стоимость дешифровки информации? Насколько сильно? В конце концов, всегда можно выбрать альтернативный вариант бэкапа, просто архивируя нужные файлы в шифрованый контейнер на внешнем винте. Это гораздо менее удобно, т.к. в случае выхода из строя основного винта, придётся заново устанавливать и настраивать систему, вместо написания одной команды в консоли, копирующей образ винта на новый винт.

Цитата: Modigar от 23 июля 2018, 19:57:22А терморектальный криптоанализатор стоит копейки и расшифровывает любы алгоритмы.

Терморектальный криптоанализатор - штука подороже квартирной кражи. А может даже и подороже проникновения в квартиру и установки своего загрузчика с кейлогером в /boot. Сейчас уже давно не 90-е. Похищение человека, пытки, последующее убийство (чтобы в полицию не настучал или ещё чего не учудил) - гораздо более опасное для исполнителей и организаторов дело, чем простое проникновение в жилище в отсутствие хозяев дома. Соответственно, более дорогое и с совсем иным "порогом применения".

Цитата: qupl от 24 июля 2018, 07:02:15Домушникам данные ни к чему абсолютно. А те кто охотится за информацией достанет ее любыми способами , включая указанный Modigar.
Когда карманники получают твой телефон, это очень неприятно. Три месяца тебе и твоему контакт-листу, мощным потоком, идёт какой-то адов спам. Раз пять (за эти три месяца) узнаёшь от знакомых, что ты, оказывается, сбил пешехода и срочно нуждаешься в деньгах на взятку полицейским. Сомневаюсь, что домушники хоть чем-то лучше карманников. Посему, хотя бы простенькое шифрование должно быть везде. Тем более, с учётом аппаратного aes в современных процессорах.

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

Цитата: qupl от 24 июля 2018, 07:02:15Если уж параноить на счет двух слепков диска, то нужно идти до конца, хранить их в разных помещениях в сейфах, с разными кодами/ключами.
Гораздо проще и дешевле просто бэкапить ценную информацию на отдельном шифрованом контейнере внешнего винта. Это менее удобно, чем бэкап при помощи dd, но более удобно, чем сейфы в разных помещениях. Надо лишь разобраться, уменьшает ли бэкап dd-ой стойкость шифрования. Исходя из этого, выбрать наиболее удобный из приемлемых вариант. Самостоятельно разобраться пока не получается. Как получится, обязательно поделюсь.

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

Cообщение объединено 25 июля 2018, 00:05:22

В общем и целом, кое чего нашел на https://www.pgpru.com/faq/zaschitadiska#h42-14. Надеюсь, за рекламу не будет сочтено, т.к. по теме "практической криптографии" там много интересного, неплохое сборище параноиков, а лицензия CreativeCommons требует указывать на них ссылку при цитировании. Под спойлером будет простыня оттуда, которая хоть и не совсем по теме, но несколько проясняет вопрос.
Открыть содержимое (спойлер)
ЦитироватьОчень удобно создавать криптоконтейнер в виде файла, ведь это даёт возможность легко делать резервные копии на различных носителях, просто скопировав этот файл. Также его легко отправить на сервер для пересылки или хранения. Почему однако не рекомендуется делать копии контейнеров таким образом?

Есть несколько причин, почему не стоит делать копии одного и того же контейнера или создавать его в виде файла поверх файловой системы.


Раньше для шифрования криптоконтейнеров в сответствующих програмах использовался обычный режим CBC (cipher block chaining – режим сцепления блоков, изобретённый для шифрования отдельных файлов) с простой привязкой IV (вектора инициализации) к номеру сектора файловой системы. Позднее выявились вполне практичные атаки multiscan – "атака уборщицы" (обнаружение фрагментов известного открытого текста без знания ключа в нескольких копиях контейнера или при доступе к одному и тому же закрытому контейнеру в разные моменты времени, когда его содержимое поменялось), watermarking (обнаружение подобранного открытого текста – доказательство наличия специально сформированных, незаметно помеченных и подброшенных пользователю файлов в контейнере без знания ключа – например при отправке их по электронной почте или при скачивании со специально созданного подставного сайта) и атаки на подмену (целенаправленная подмена с предсказуемым результатом фрагментов известных файлов путём изменения шифртекста контейнера без знания ключа).


Для борьбы с этими уязвимостями изобрели специальные более продвинутые режимы – CBC-ESSIV, LRW, XTS. В них постарались применить методы доказуемой безопасности для обоснования стойкости против подобных атак. Но эти доказательства пока признаны неполными и ограниченными, а качественный режим шифрования дисков так и не создан. Нет единого мнения – можно ли создать стойкий, но экономичный Narrow block режим шифрования или необходим обязательно Wide block режим.


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


Доказательства стойкости Narrow block режимов ограничены. И их стойкость к атакам multiscan не рассматривалась, исследовались только ситуации противодействия атакам watermarking и против подмены. Возможно, в случае multiscan эти режимы будут уязвимы как к подмене и watermarking, так и к другим атакам.


Всё что пока удалось сделать исследователям – перенести эти атаки из достаточно практических в более теоретическую область. Но полноценный доверяемый стандарт на дисковое шифрование так и не создан.


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


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


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


На основании многих причин рекомендуется придерживаться следующей стратегии при работе с криптоконтейнерами.


Использовать шифрование, привязанное только к конкретному носителю (физическому или логическому разделу диска), но не в виде файла поверх файловой системы. Современные программы шифрования позволяют изменять размер шифрованных разделов без потери данных.
Не делать побитовые копии контейнеров. При необходимости делать резервную копию содержимого – создать контейнер на другом носителе (можно использовать тот же пароль – мастер-ключ шифрования всё равно сгенерируется другой) и перенести данные в него.
При невозможности создания нового контейнера на самом резервном носителе (CD, DVD, удалённые серверы, отправка по почте) – дополнительно для этой цели создавать новый одноразовый контейнер, каждый раз заново перед записью или отправкой и уничтожать его лишние копии (которые например остались на винчестере после записи или отправки) или использовать другой способ шифрования.
Не монтировать контейнеры с удалённых недоверямых серверов и не размещать их там для этой цели.

Эти требования могут быть ослаблены при наличии у пользователя достаточной квалификации в степени оценки угрозы безопасности его данным.
[свернуть]
Исходя из процитированного, прихожу к выводу, что тем, кто болеет паранойей на поздних стадиях, не следует делать побитовые копии шифрованых разделов. Вроде как, единого мнения о безопасности такого действия нет, а сомнения вполне резонны. С другой стороны, если паранойя на начальных (разумных) стадиях, для личного компа, при модели угроз "простые воришки", можно пренебречь такой опасностью при использовании современных реализаций, вроде aes-xts. Попробую обсудить (на pgpru) вопрос пихания образа зашифрованого диска в криптоконтейнер для целей побитового бэкапа. Потом перескажу суть в этой теме. Раз уж начал тему, надо довести её до конца и полностью разжевать.

qupl

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

Cообщение объединено 26 июля 2018, 09:30:28