id: Гость   вход   регистрация
текущее время 13:29 19/03/2024
Автор темы: Гость, тема открыта 24/01/2011 12:02 Печать
Категории: криптография, софт, инфобезопасность, хард, свободный софт
http://www.pgpru.com/Форум/UnixLike/ВечноеВыолпнениеDdIfdevurandomOfdevsdX
создать
просмотр
ссылки

"Вечное" выолпнение dd if=/dev/urandom of=/dev/sdX


Решил переформатировать HDD в криптованный диск для бэкапов.
Следуя советам, данным на форуме, для перезаписи данных на диске дал команду:

Сначала думал сделать что-то типа или , но что-то подумалось мне, что это делается на текущую mount point, и – не знаю, прав я или нет, но мне показалось, что дать команду на раздел безопаснее.
И вот уже полсуток продолжается работа dd и нет ей ни конца, ни краю... Причем, sfill по одному разу или по два раза, имхо, давно бы уже прошла вся (обычно на такой же объем уходило неск. часов, но не полсуток, если конечно не делать sfill без аргументов -l или -ll, когда оно будет 30 с гаком раз перезаписывать.
И только сейчас сообразил, что /dev/urandom генерит данные постоянно, это же не клонирование с диска на диск, если его не остановить, то он будет делать это вечно, или пока компьютер/диск не сломаются :)
Мне кажется, что полсуток достаточно для 300-гигового диска, что называется, с "головой".
Как правильно определить/задать время для данной работы?
И еще возник вопрос, почему здесь рекомендуется юзать /dev/urandom, а не /dev/random?
Я посмотрел, это разные устройства, а не ссылки одного на другого. Согласно манам, /dev/random генерит еще более "случайные" данные. Разве он не лучше?
Или для этой цели такой необходимости нет, а времени/ресурсов займет больше?



 
На страницу: 1, 2, 3, 4, 5 След.
Комментарии
— SATtva (24/07/2012 13:20)   профиль/связь   <#>
комментариев: 11558   документов: 1036   редакций: 4118
Так надо использовать, как я понимаю, skip, а не seek

Наоборот.

И, соответственно, надо явно определять параметры ibs и obs или, при их равенстве, достаточно определить bs?

Второе.
— unknown (06/11/2012 15:13, исправлен 06/11/2012 15:14)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664

Хотелось бы вернуться к обсуждению "Как быстро заполнить раздел/том случайными данными в Unix, чтобы подготовить его к шифрованию?".


И предложить чуть более удобный вариант:


  1. Отформатируем диск под криптоконтейнер: cryptsetup -s 256 luksFormat /dev/[name]. Использовать стойкий пароль в этой методике необязательно, лучше легкозапоминаемый. Можно использовать "qwertyuiop".
  2. Откроем контейнер: cryptsetup luksOpen /dev/[name] /dev/[name_open]
  3. Поставим на заполнение нулями dd if=/dev/zero bs=1M of=/dev/[name_open]. Вариант с прогресс-баром: dd if=/dev/zero bs=1M | pv -s[device_size_in_gigs]G | cat – > /dev/[name_open]. Придумайте кто-нибудь, как совместить прогресс-бар от pv и оффсет при записи, например через второй dd вместо cat.
  4. После завершения закрываем контейнер: cryptsetup luksClose /dev/[name_open]
  5. Смотрим на список слотов cryptsetup luksDump /dev/[name]. Вспоминаем пароль "qwertyuiop" и удаляем все слоты (в нашем случае единственный нулевой): cryptsetup luksKillSlot /dev/[name] 0. Ещё раз смотрим, что ничего не осталось: cryptsetup luksDump /dev/[name].
  6. Этот пункт необязателен, но при желании можно дополнительно стереть заголовок, если контейнер не будет использоваться как LUKS: for a in $(seq 4); do dd if=/dev/urandom bs=1M count=4 of=/dev/[name]; done
  7. Заново отформатируем диск под криптоконтейнер: cryptsetup -s 256 luksFormat /dev/[name]. Теперь уже со стойким паролем для реального использования.
— Гость (06/11/2012 18:24)   <#>
Вариант имеет ряд сущностных ограничений.

  1. Забудьте про /dev/[name], DOSовские разделы диска — прошлый век, LVM позволяет использовать диск без разбития на разделы. Противнику не надо знать, как он разбит. Мы хотим получить полный диск случайных данных: никаких сигнатур, никаких заголовков LUKS, никаких таблиц разделов, никаких указний ничего и ни на что.
  2. cryptsetup пишет сигнатуры. Чтобы этого избежать, надо использовать либо старый интерфейс к нему, куда сразу указывать ключ, либо добавлять LUKS-заголовок через dm. Идея: через dd считываем нужные сектора диска в файл в tmpfs, запиливем ему magic и расшифровываем OpenSSL'ем. Это будет LUKS-заголовок. Далее подключаем его через dm как часть общего диского пространства. В конце применяем к полученному виртуальному устройству LUKS (cryptsetup) стандартным образом (сигнатуры теперь будут, но они не записываются на диск).

Что это даёт: никаких сигнатур, расшифровывается в любом Linux.
— SATtva (06/11/2012 21:17)   профиль/связь   <#>
комментариев: 11558   документов: 1036   редакций: 4118
В огороде бузина, в Киеве — дядька.
— Гость (06/11/2012 21:33)   <#>
Не, ну если таблица разделов не смущает, то вперёд. А если смущает, то прийдётся дядьке бузину поесть.
— Гость (06/11/2012 21:45)   <#>
Точнее, если в Linux можно работать непосредственно с /dev/sda вместо /dev/sda{N}, то для зачистки диска методика unknown'а работать будет. Для шифрования я бы предпочёл иное, а не дефолтный метод.
— unknown (06/11/2012 22:07, исправлен 06/11/2012 22:11)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664

  1. В FAQ сейчас так и есть. Где вы здесь увидели именно разделы диска? Пришлось даже давать пояснение по поводу LVM. Но здесь была задача ничего не навязывать. Если /dev/mapper/[name], то это м.б. логический том, может быть всё устройство, м.б. физический том, м.б. "старый досовский раздел", как кому удобно, может кто-то cd-дисками ещё пользуется и исошки для них шифрует. В /dev лежат и UID'ы томов и указания на всё устройство целиком, под [name] ничего конкретного специально не имелось ввиду.
  2. Безсигнатурное шифрование — отдельная и не такая простая задача. Кому-то она критична, может городить велосипед уже сейчас, но раз это не внедрили в стандартную поставку, то тому есть объективные причины — трудно соблюсти баланс между гибкостью и теоретической безопасностью и сокрытием, как требованием практической безопасности.

Это не полная инструкция, а частный вопрос, поэтому навязывание LVM и бессигнатурное шифрование решено исключить.


P.S. Есть идея собрать "продвинутые методы использования cryptsetup и пр." в один раздел, по аналогии с Tor.


Пока есть три наработки, при чём это не велосипеды и не костыли, а чуть допиленные стандартные (хотя и малораспространённые) решения:


  1. Сравнительно безопасное (на уровне разумных компромиссов) использование гибернейта в шифрованный своп с возможностью при желании быстрого уничтожения ранее накопленной в нём информации без его размонтирования (на живой рабочей системе).
  2. Использование продвинутых опций помещения скриптов в crypttab для цепочечной генерации ключей: открытие одного контейнера даёт доступ к другим контейнерам. На самих контейнерах никаких промежуточных файлов с ключами не лежит, применяется хэширование ключа, полученного из пароля и висящего в памяти, для вывода другого ключа.
  3. Использование специального интерфейса ядра для безопасной работы с ключами и паролями (это вместо извращений с fifo и tmpfs): распределение по слотам, кэширование, деактивирование по таймауту, повторное использование одного пароля (ключа) ко многим контейнерам по дескриптору его слота в ядре.

Все эти варианты:


  1. Повышают гибкость.
  2. Потенциально снижают безопасность (больше для любителей экспериментировать).
  3. Никак не связаны с задачей сокрытия или отрицания факта работа с шифрованными FS.

Если у кого-то уклон больше на сокрытие и бессигнатурное шифрование, то приветствуется публикация своих инструкций для совместного развития.

— SATtva (06/11/2012 22:14)   профиль/связь   <#>
комментариев: 11558   документов: 1036   редакций: 4118
Использование специального интерфейса ядра для безопасной работы с ключами и паролями

Это модуль ядра ENCRYPTED_KEYS?
— unknown (06/11/2012 22:26, исправлен 06/11/2012 22:29)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664

Да, оно:


Linux Key Management Utilities
Keyutils is a set of utilities for managing the key retention facility in the kernel, which can be used by filesystems, block devices and more to gain and retain the authorization and encryption keys required to perform secure operations.
Homepage: http://people.redhat.com/~dhowells/keyutils/
— Гость (06/11/2012 22:29)   <#>
раз это не внедрили в стандартную поставку, то тому есть объективные причины
Не думаю. Ряд программ шифрования в UNIX сигнатур не имеют, но в LUKS это не так, потому что, как всегда, "удобство" (возможность определить что на разделе) и "незачем скрывать наличие шифрованных данных". действительно, как юзерофильные рюшечки в гноме будут определять, что раздел шифрован, если у него нет сигнатур? А тут всё юзерофильненько: всунул диск, всплыло окошко с вводом пассфразы.

Если у кого-то уклон больше на сокрытие и бессигнатурное шифрование, то приветствуется публикация своих инструкций для совместного развития.
Это всё понятно. Как появится время добразобраться, напишу инструкцию, хотя на уровне proof of concept уже сейчас очевидно, что это будет работать. Ряд извращений с device mapper уже тестировался.
— unknown (06/11/2012 22:39)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664

Как-то натыкался, что если например в gnupg отрезать все заголовочные байты в самом простом симметричном шифровании, то посредством дописывания этих байтов при помощи самого gnupg можно различать такой файл от полученного из /dev/urandom. Где гарантия, что другие программы при "бессигнатурном" шифровании не сохраняют специфический формат пакетов?


Опционально могли бы сделать, как в Truecrypt. Проблемы в надёжности при смене форматов, при долговременном хранении с целью прочитать на всех последующих версиях системы, при необходимости обеспечить равнозначную стойкость к перебору по словарю, при условии, что от противника не скрыли таки факт шифрования и он заведомо знает, что это не белый шум, а контейнер и в каком он формате, проблема с управлением ключами в слотах и др.
— Гость (06/11/2012 23:32)   <#>
Самый короткий способ заполнения устройства случайными данными



ABCDEF – ключ и пароль в 16-ричном виде, можно использовать $(hexdump -e '1/1 "%02x"' /dev/urandom). Для избежания несущественной ошибки в конце записи можно заменить



Вместо openssl можно использовать любую другую программу шифрующую stdin на stdout. Например gpg с отключением сжатия (хотя в начале будет двоичная pgp-сигнатура). Поточный шифр наверное будет быстрее работать.

Для отображения прогресса в более распространённом способе, описанном unknown-ом, удобна также команда mbuffer



В новых версиях cryptsetup заголовок luks вроде бы можно вынести в файл на другом устройстве (об этом писал разработчик в рассылке), поэтому в хитростях связанных с использованием dmsetup больше нет необходимости. Хотя возможно удобнее использовать cryptsetup без расширения luks с явно заданным ключом (или dmsetup с целью crypt). Ключ поместить на другой носитель и защитить паролем с помощью самописного скрипта. Тогда есть возможность самому выбрать и настроить алгоритм расширения пароля – pbkdf2, scrypt и т.п.

Если вся система на одном диске то в использовании lvm нет особого смысла, только лишнее усложнение. Таблицу разделов не создавать, всю систему зашифровать на /dev/sda, а swap, если нужен, разместить в файле (предварительно заполненном до нужного размера, например нулями), а не создавать под него раздел. Учитывая что при современных объёмах оперативной памяти он почти не используется, на производительности это не сказывается, swap нужен только для подстраховки. Если и использовать lvm для объединения дисков, то поверх их шифрования.
— Гость (07/11/2012 02:50)   <#>

Всюду советуется разбивать дисковое пространство на разделы, чтобы на разных разделах были разные ФС. Это для устойчивости к сбоям ФС. Если на диске будет крутиться несколько гостевых ОС, то и файловые системы для них должны быть разными. Ну, и про стратегическое удобство на будущее не забываем.


Да, это интересно. Не помню, чтобы вы об этом писали ранее (в отличие от пунктов 1 и 2).


Потненциально в смысле «а вдруг мы что-то не учли»?


За счёт чего так получается? Информация об имеющихся сигнатурах и форматах является внешней по отношению к предложенным методам бессигнатурного шифрования. Да, такую информацию надо откуда-то брать и тщательно проверять. Или вы намекаете, что там отличие чисто криптографическое? Сам криптотекст должен быть неотличим от /dev/urandom, иначе это ненадёжное шифрование. Потенциально можно иметь формат с сигнатурами во многих местах, т.к. пространство может шифроваться кусками, каждое начало/конец которых каким-то образом отмечены (но я про такое не слышал); хотя для современных файловых систем это действительно так: при форматировании диска определённые данные записываются не только в заголовок, но и в ряд мест на файловой системе.


Обратная совместимость — фича программного функционала, а не интерфейса. Все претензии к разработчикам.


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

Нормальное шифрование под винду с хорошими фичами тоже было "невозможно", но потом пришёл ntldr и всё сделал. Linux же пока так и не нашёл своего ntldr'а.

P.S: Вроде бы у OpenBSD'шного vnconfig и NetBSD'шного cgd сигнатур нет. Т.е. отродясь не было. Никогда. Про FreeBSD'шный geli не знаю (т.е., возможно, также). У cgd ключевой файл всегда есть и всегда внешний по отношению к ФС, хранит salt. У LUKS ограниченное количество слотов, а у cgd из одного можно нагенерить хоть миллион разных salt-файлов, где каждый будет замапплен на свою пассфразу для одного и того же криптораздела. Мастер-ключ при этом не меняется, как и в LUKS. Чем интерфейс к cgd хуже LUKS, кроме как удобства «воткнул диск — и сразу рут и оно автоматически распозналось»? Всё, как всегда, упирается во всё то же:
"незачем скрывать наличие шифрованных данных"
— Гость (07/11/2012 08:35)   <#>
незачем скрывать наличие шифрованных данных

Честному человеку нечего скрывать!
— unknown (07/11/2012 10:15, исправлен 07/11/2012 10:57)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664
Или вы намекаете, что там отличие чисто криптографическое? Сам криптотекст должен быть неотличим от /dev/urandom, иначе это ненадёжное шифрование.

Контрольные суммы пакетов, в GnuPG они называются MDC. Если к файлу из /dev/urandom дописать заголовок GnuPG, то GnuPG пишет, что в файле непонятный формат пакетов. Если вернуть заголовок настоящему файлу, то даже при неправильно введённом пароле он напишет, что пакеты MDC есть, но они битые.


Сам шифртекст может и не быть случайным. Поверх шифрования ("снаружи") м.б. слой коррекции ошибок или ещё какая вспомогательная информация. Например, чисто умозрительно, идут рэндомные блоки IV1, IV2, C1 а затем IV3 = Hash( IV1 || IV2 || C1 ), затем IV3, IV4, C2 и т.д. с целью защиты от каких-нибудь ошибок или манипуляций. По отдельности случайно, а вместе — нет. В недисковом шифровании такая избыточность может встречаться.


ABCDEF – ключ и пароль в 16-ричном виде, можно использовать $(hexdump -e '1/1 "%02x"' /dev/urandom).

В том то и дело, что нужно, иначе при отключенном IV один и тот же пароль будет давать всегда одинаковый шифртекст, да и сам пароль в этом методе должен быть стойким. В отличие от метода с cryptsetup, где можно использовать известный противнику пароль


Вместо openssl можно использовать любую другую программу шифрующую stdin на stdout.

Напугали же. Теперь все боятся полагаться на какую-либо внешнюю программу.


Она, помимо всего прочего, может оказаться ненамного быстрее dd if=/dev/urandom и уж всяко не быстрее шифрования нулей самим cryptsetup.


Просто, использование только самого cryptsetup:


  1. Заведомо самое надёжное. Получаем заполнение на том же режиме шифрования, который и будет использоваться.
  2. Самое быстрое. Всё таки исполняется на уровне модулей ядра.
  3. При наличии AES-криптоакселератора в проце и его поддержки ядром, п.2 особенно актуален.
  4. Если криптоакселератор поддерживает быстрый ГСЧ и ядро может заворачивать его в /dev/random или /dev/hwrandom, тогда лучше использовать его вместо всех этих комманд. Так и проще, и надёжнее.
На страницу: 1, 2, 3, 4, 5 След.
Ваша оценка документа [показать результаты]
-3-2-1 0+1+2+3