id: Гость   вход   регистрация
текущее время 22:45 11/12/2019
Автор темы: gpg_list, тема открыта 07/08/2014 14:35 Печать
Категории: криптография
создать
просмотр
ссылки

шифрование бекапа


1. Чем лучше зашифровать флешку с бекпом:truecrypt или dm-crypt(в посл. случае объясните, как пользоваться без luks-а)?
2. Операционка зашифрована luks-ом. В случае затирания/повпеждения заголовка раздела, можно ли восстановить его и как или прощай информация?


 
На страницу: 1, 2 След.
Комментарии
— unknown (07/08/2014 14:42, исправлен 07/08/2014 14:48)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664

1. TrueCrypt как бы уже того. Cryptsetup без LUKS — нехорошо в плане стойкости и управления, но компромиссные варианты возможны. На форуме есть любители использовать такое ради некоторой отрицаемости.
2. При затирании заголовка затирается ключ криптоконтейнера и он не может больше открыться никаким паролем. Прощай информация — и это хорошо, и правильно для быстрого уничтожения данных.

— gpg_list (07/08/2014 14:57)   профиль/связь   <#>
комментариев: 6   документов: 1   редакций: 0

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

Мне не столько ради отрицаемости,сколько ради большей сохранности шифрованных данных от себя любимого.
С TrueCrypt нехорошая история приключилась, но исходники 7.1 есть, они вроде без дыр. Ждем форка.
— Гость (07/08/2014 22:02)   <#>

См. Пункт 3.


Обсуждалось здесь. Можно, если есть бэкап заголовка — опции luksHeaderBackup, luksHeaderRestore, --header-backup-file, --header. Если хочется бессигнатурно, можете или вообще не использовать хидер* или хранить его в отдельном файле**.

Если не идёт речь про винду, то TC не нужен.

*Тогда вы или лишаетесь способа легко убивать мастер-ключ, или вам придётся делать внутри криптотома ещё один LUKS, где будет менеджмент ключей.
**Понятно, что к нему тоже могут быть бэкапы.
— Гость (07/08/2014 23:16)   <#>

Когда смотрю на luksDump для раздела, у которого была удалена последняя пассфраза (все слоты DISABLED), не понимаю: под LUKS отформатирован, параметры показываются. Хочу теперь снова сделать luksAddKey, а нельзя, надо делать luksFormat заново. Почему тогда заголовок не затирается весь рандомом при затирании последнего слота? Какой толк помечать такие разделы, как принадлежащие LUKS? Опять эти «удобства»?


Можно.
— Гость (07/08/2014 23:17)   <#>

Она тут ни при чём — достаточно использовать машинносгенерированные пароли.
— gpg_list (08/08/2014 10:11)   профиль/связь   <#>
комментариев: 6   документов: 1   редакций: 0

Т.е. cryptsetup --header-backup-file=<путь, куда сохр. файл> <девайс, с чьего заголовка нужно снять копию >
В итоге у меня должен появиться файл с копией заголовка. Как его восстановить?

Шифровать флешку решил все-таки трукриптом.
— gpg_list (08/08/2014 11:33)   профиль/связь   <#>
комментариев: 6   документов: 1   редакций: 0
зашифровал флешку, примонтировал, форматнул

пишу

мне выводит

Это норм.?
З.Ы. флешка норм. раб., только смущает выше приведенный вывод.
— unknown (08/08/2014 11:35)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664
/comment82365:
[sarcasm]
Достаточно подбросить монетку 256…512 раз, запомнить последовательность нулей и единиц, и научиться переводить это в Base64 по памяти.
[/sarcasm]
— Гость (09/08/2014 03:54)   <#>

Сбэкапить:
# cryptsetup luksHeaderBackup /dev/sda --header-backup-file Backup_for_sda
— это сделает бэкап в файл Backup_for_sda в текущей директории. Восстановить заголовок из бэкапа на основной том (опасная процедура, делайте бэкап перед этим):
# cryptsetup luksHeaderRestore /dev/sda --header-backup-file Backup_for_sda
Можно не восстанавливать заголовок из бэкапа, а просто указать его как внешний при монтировании:
# cryptsetup --header Backup_for_sda luksOpen /dev/sda sda_crypt
Ну, и потом подмонтировать его:
# mount /dev/mapper/sda_crypt /path/to
Естественно, предполагается, что все нужные файлы находятся в текущей директории. Если это не так, то нужно указывать путь к Backup_for_sda.
— Гость (09/08/2014 03:58)   <#>

А зачем? Пароль заучивается сразу в печатных символах. Как я понимаю, при -h sha512 в plain mode он прохэшируется и получится правильный случайный бинарный мастер-ключ. К тому же, нет необходимости учить именно случайный пароль — достаточно, чтоб он был высокоэнтропийным (для защиты от словарных атак). Всё равно он будет хэшироваться.
— gpg_list (09/08/2014 13:36)   профиль/связь   <#>
комментариев: 6   документов: 1   редакций: 0
Ну, и потом подмонтировать его:


Минутку. Примонтировать к чему?
Я так понимаю. Открываю заш. разд.

и примонтирую

так ?

А зачем? Пароль заучивается сразу в печатных символах...


Высокоэнотропийные пароли генерируются с помощью спец.прогр. Для меня пароль вида fry.,783>jyb%2(? в символов 15-20 будь то он сгенерирован случайно или не случайно незапоминаем.
— unknown (09/08/2014 16:33)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664
Удобство LUKS в том, что контейнер шифруется высокоэнтропийным случайным ключом, который записывается в шифрованном виде в слот заголовока, а результат итерированного хэширования пароля с солью PBDKDF служит сначала для расшифрования этого ключа, а затем уже этим ключом — самого шифроконтейнера. Это позволяет использовать несколько разных паролей для одного контейнера.

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

Это позволяет быстро создать контейнер с не очень стойким паролем P0. Затем добавить более стойкий пароль P1 и перейти на него, сохранив P0. Если пароль P1 не вспомнить, то можно откатиться на P0 и только когда P1 надёжно выучен, можно стереть P0 и оставить только P1. Затем можно внедрять P2 и т.д. Подразумевается, что за время T практического разучивания с одновременным использованием к моменту X пароли из текущей пары {Pn, Pn-1} будут достаточно стойкими.

Также подразумевается условие, что техники моментального разучивания пароля 128…256 гораздо неудобнее, непрактичнее и недоступнее пошаговых, позволяющих итеративное усложнение и усвоение одновременно с использованием, но с разменом некоторого времени T на безопасность. По этой же причине, до достижения состояния надёжного запоминания стойкого пароля, его не рекомендуется бэкапить на промежуточные носители.

Без LUKS этого всего не достичь. Как, например и иерархического доступа: авторасшифровки одного контейнера при расшифровке пароля к другому (так чтобы сам ключ к другому контейнеру не лежал в открытом виде на ФС предыдущего), но с возможностью и расшифровки другим паролем по отдельности.
— Гость (09/08/2014 21:26)   <#>

«/path/to» означает, что надо вместо этого подставить /путь/к, т.е. правильный путь для вашего случая. Может быть, это будет /mnt, а, может, и что-то другое.


cryptsetup --header Backup_for_sda luksOpen /dev/sda sda_crypt

mount /dev/mapper/sda_crypt /mnt/как/же/задрали/юзеры/которые/всё/хотят/иметь/совершенно/не/зная/матчасти


Если хочется куда-то ещё и /boot примонтировать, который идёт отдельным разделом, то пожалуйста, но я выше предполагал, что у вас шифруется весь носитель. Если шифруется только раздел на нём, то замените везде sda на sda1 или какой там у вас раздел. Список выводится командой fdisk -l -u /dev/sda.


Случайность приписывается способу генерации, а не конкретному паролю. Разбиралось здесь.
— gpg_list (10/08/2014 01:05, исправлен 10/08/2014 01:14)   профиль/связь   <#>
комментариев: 6   документов: 1   редакций: 0

полегче. Я прежде чем придумать текущую схему неделю матчесть изучал, а потом еще неделю с грубом мучался.
Если я вас правильно понял, вы предлагаете вынести заголовок на флешку. Я сам прикидывал такой вариант, но до реализации не дошел.
Итак у меня есть два раздела:
/dev/sda1 /boot
/dev/sda2 luks
Я делаю рез. копию заголовка. Сам заголовок стираю. Перезагружаю комп. Запускается биос, затем груб,т.к. заголовка нет, груб напишет мне какую-нибудь х*ню. Следовательно для запуска уст. ОС нужен лифСД?
Что-то я ничего не понимаю. Как мне запустить ОС, если заголовок находится на флешке? Пожалуйста, разъясните, как работает ваша схема.
P.S.все выше написанное мои размышления. на железе ничего не испытывал,т.к. сначала хотелось бы понять принцип, а потом уж эксперементировать.


Я имел ввиду то, что подобный пароль запомнить ооооочень трудно, практически невозможно.

— Гость (10/08/2014 02:58)   <#>

Не на флэшку, а в какой-нибудь файл, я не конкретизировал.


Каким образом?


Здрасьте, приехали! Перечитайте своё название темы и заданные вопросы. Вы спросили как сделать бэкап содержимого на флэшку, вам ответили. Теперь вы спрашиваете как с неё грузиться. Вы хотя бы немного отдаёте себе отчёт в том, что загрузка с бессигнатурного шифрованного носителя и работа с бессигнатурно шифорванным бэкапом — разные вещи? И про первое вы вопрос не задавали. Тем не менее, вам выше по треду уже дали ссылку, которая отвечает на поставленный вопрос.


Для кого как.
На страницу: 1, 2 След.
Ваша оценка документа [показать результаты]
-3-2-1 0+1+2+3