id: Гость   вход   регистрация
текущее время 13:49 21/02/2018
Автор темы: ressa, тема открыта 29/07/2014 10:40 Печать
Категории: криптография, инфобезопасность, защита дисков, алгоритмы, операционные системы
https://www.pgpru.com/Форум/UnixLike/МаскировкаВводаПароляВCryptsetup
создать
просмотр
ссылки

Маскировка ввода пароля в cryptsetup


Форумчане, скажите, можно ли сделать в Crytpsetup затирание вывода консоли при вводе пароля на загрузку?
Как в TrueCrypt – фейковая ошибка, например "Invalid BOOT.INI file Booting from C:windows", таким образом ввести в заблуждение по поводу установленной системы и не реагировать на ввод неправильных паролей.
Спасибо


 
На страницу: 1, 2, 3, 4, 5, 6, 7, 8 След.
Комментарии
— Гость (21/03/2015 07:13)   <#>
Перечитал тред и сам ужаснулся. Теперь не верится, что через всё это когда-то пришлось пройти... Я даже уже успел забыть, что однопроходного решения вроде так и не было найдено, и если всё повторять заново, похоже, хак с реинсталляцией загрузчика из-под другой системы всё равно понадобится.
— unknown (21/03/2015 14:02, исправлен 23/03/2015 09:51)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664

Здесь был гипероффтоп. Пусть он будет там.

— unknown (21/03/2015 14:51)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664

Вы хотите бессигнатурно шифровать, делать множество нетривиальных вложений томов и т.д. В Debian был баг-репорт, что при даже не самом навороченном вложении шфированных томов некая матрёшечная конструкция некорректно отмонтировалась при poweroff и накапливались ошибки. Тогда что-то пофиксили. Если вы городите что-то очень своё, то есть шанс поиметь проблемы с потерей доступа к данным после очередного выключения, обновления и т.д. Не говоря уже об общей оценке затрат сложности персонального поддержания на некоторые самопальные неискоробочные решения.
— Гость (21/03/2015 17:20)   <#>

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


К счастью, журналирование в ФС есть, это сильно спасает дело, но и бэкапы никто не отменял, естественно.


Угрозы со временем только растут, атаки становятся только сильнее, поэтому, чтобы сохранять паритет с противником и быть хотя бы на один шаг впереди, нужно развиваться и совершенствовать защиту.
— ressa (07/04/2015 17:11)   профиль/связь   <#>
комментариев: 1079   документов: 58   редакций: 59
Господа, подскажите, можно ли сделать загрузку OS по ключевому файлу и паролю с флешки?
Ну, к примеру сделать openssl rand -base64 16384, записать его на флешку и при включении компьютера система будет требовать его и ввод пароля?
— SATtva (07/04/2015 17:39)   профиль/связь   <#>
комментариев: 11524   документов: 1036   редакций: 4050
При полнодисковом шифровании так и делается, только openssl явно ни к чему. Как это сделать, зависит от конкретного дистрибутива, в Gentoo опции для сборки initrd можно определить с помощью genkernel.
— ressa (07/04/2015 17:41)   профиль/связь   <#>
комментариев: 1079   документов: 58   редакций: 59
SATtva, ну мне, как ламеру – что-то дебианоубунтуобразное. А почему openssl ни к чему? Так то по сути – плевать, что будет исполнять роль ключевого файла, правильно? Хоть тот же gpg-ключ или "семейная фотография".
— Гость (07/04/2015 18:05)   <#>

Обычно всё же нет. Во-первых, /boot, как правило, на том же диске, который и шифруется, а не на внешнем носителе, а, во-вторых, cryptsetup обычно работает без каких-либо ключевых файлов. Конечно, всё это можно наворотить при желании самому.
— SATtva (07/04/2015 18:08)   профиль/связь   <#>
комментариев: 11524   документов: 1036   редакций: 4050
Ок, скажем так, это достаточно распространённый подход.
— unknown (07/04/2015 18:19)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664

См. /usr/share/doc/cryptsetup/examples.
— Гость (08/04/2015 02:29)   <#>

Просто штатное полнодисковое шифрование — оно не для параноиков, посторонний внешний носитель для загрузки ещё таскать — неудобно, поэтому вот так. ☺


Только хотел сказать, что --key-file — это не произвольный файл, а файл для пассфразы, поэтому для двухфакторной аутентификации, видимо, понадобятся костыли (в отличие от того же cgd, где это по умолчанию делается всегда и штатно). Собственно, да, в examples приведён пример костыля. ☺ Кстати, тут это уже обсуждалось.
— Гость (28/04/2015 17:03)   <#>

Патчи к пунктам про общую (неупрощённую) схему бессигнатурки



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

Вместо этого в качестве обманки можно взять какой-нибудь Live-USB и записать его на диск подобно этой инструкции. Брать Tails — значит, подчёркивать осведомлённость в некоторых технологиях, но можно взять какой-нибудь нейтральный Live-образ. В принципе, его можно создать даже самому под свои нужды. Ничего такого туда устанавливать не надо, но в довесок можно (по аналогии всё с той же инструкцией) сделать для обманки отрицаемый скрытый раздел, из которого после запуска системы можно каждый раз доустанавливать нужный софт (Tor, macchanger или ещё что-то специфичное) и подключать какие-то нейтральные данные. Если отрицаемый скрытый раздел не подключается, будет обычная нормальная рабочая Live-система с ограниченными возможностями. К ней можно даже сделать обманный нешифрованный раздел с нейтральными данными, но он, в принципе, будет вреден: будет видна частота изменения данных, когда последний раз монтировали систему и т.д.

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


openssl не нужен, как уже выше, кажется, отмечалось. Достаточно бессигнатурного cryptsetup'а с адресацией нужных блоков, а внутри него сделанной ФС с данными. Это делается проще, из коробки, и в целом оно более безопасно/надёжно.


Как ясно из этого треда и вышеприведённых обсуждений, «live» тут не нужен. Скрытая система — полноценная система, установленная куда-то там внутрь матрёшки из LVM'ов и cryptsetup'ов. Системе всё равно, куда она установлена, лишь бы был правильный загрузочник и /etc/fstab.


Ввиду вышесказанного патча к п. 2, посторонние LiveCD/LiveUSB не нужны — вместо них можно воспользоваться обманкой, раз она тоже будет Live-системой. Основное требование к обманке — то, что по ней не должно быть возможным сказать, сколько раз её грузили, как долго в ней работали, какие сайты открывали и т.д.


Как уже было выше сказано, ничего из этого не нужно. Достаточно просто штатно грузануться с карточки/флэшки или что там используется, в командной строке initramfs'а подключить нужные LVM и cryptsetup'ы, а потом набрать exit — загрузка пройдёт.


У флэш и прочих карточек есть интерфейсы низкоуровневого доступа, которые принудительно записывают нули во все ячейки [1], [2]. Это делается намного быстрее, чем полное заполнение флэш-носителя какими-то данными через стандартные интерфейсы взаимодействия с ним. В общем, можно как-то комбинировать эти методы.


Посторонная Live-систеима не нужна, как выше уже было отмечено (разве что для подстраховки).


На загрузочнике скрытой ОС стоит просто /boot, а в нём есть и гипервизор со всеми вытекающими. Live-система тут уже ни при чём.

P.S. Если в матрёшке какие-то LUKS-разделы нужны только для возможности быстрого удаления, на них можно ставить пустые или простые пароли.
— pgprubot (22/05/2015 19:39, исправлен 22/05/2015 19:42)   профиль/связь   <#>
комментариев: 511   документов: 2   редакций: 70

Раз загрузочный носитель всё равно затирается:


Снова подсоединяем MicroSD-карточку. Затираем её.

можно на него помещать как скрипты для автоматического монтирования дисков, так и LUKS-заголовки к ним:


... Проще хранить заголовок LUKS'а в каком-то третьем устройстве в файле, тогда бессигнатурность будет иметься изначально и штатно, а подключаться такие тома будут одной простой командой.

Т.е. аутентичный режим plain mode нужен только при шифровании образа загрузчика. Этот образ нужно будет при каждой загрузке расшифровывать вручную из-под того или иного LiveUSB и записывать на флэшку/карточку.

— pgprubot (27/05/2015 02:51, исправлен 27/05/2015 02:54)   профиль/связь   <#>
комментариев: 511   документов: 2   редакций: 70

Но:


Загручику lilo плохеет, он вываливается в командную строку, но если там всё пдключить, то через некоторое время он-таки добирается до нужных разделов и ОС запускается(!).

Установка проходит штатно, но поддержка графики так и недостестировалась: после apt-get update и apt-get upgrade ядро так обновилось, что больше ОС не загрузилась. При старте системы на ранних стадиях загрузки ядро стабильно падает в панику, и ничего не помогает.

Т.е., похоже, всё было не так. С lilo загрузчик установился сразу, всё работало, но система не пережила upgrade. С grub2 загрузчик штатно нормально не поставился, понадобились ручные фиксы, но зато после этого система стала нормально штатно апгрейдиться/апдейтиться.


Можно было бы тщательней поковырять вариант с lilo, но непонятно, насколько он считается штатным и поддерживаемым в Debian. К примеру, правильно ли он фиксится/апдейтится (как grub2) при установке гипервизора Xen и dom0-ядер Linux?

— Yellow (06/07/2015 12:47)   профиль/связь   <#>
комментариев: 64   документов: 0   редакций: 4
Пожалуйста, уточните архитектуру бессигнатурки с grub2. Я так понимаю, что на HDD есть бессигнатурное шифрование, и отдельно имеется носитель с Live-OS. Для загрузки скрытой ОСи, в этом случае, используется grub с live-носителя?
На страницу: 1, 2, 3, 4, 5, 6, 7, 8 След.
Ваша оценка документа [показать результаты]
-3-2-1 0+1+2+3