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

Можно пересобрать рамдиск так, чтобы он обходил вызов cryptsetup при полнодисковом шифровании. Будет что-то вроде "partition not found" или «том не найден», или вообще загрузка посторонней системы. А можно вставить в скрипты рамдиска какую-то свою команду, которая бы вызывала кусок скрипта с нормальным cryptsetup только при определённых условиях — нажатии комбинации клавиш, хотя бы малоприметный read с таймаутом.

Но это чисто внешняя защита: грамотный противник, способный провести экспертизу, разберёт и рамдиск построчно, и подозрительные разделы заметит.

Да мне собственно внешняя защита и интересна. Так сказать "от дурака". Зачастую в моей модели угрозы нет никаких спецов, кроме продажных студентов "Юго-Запада Москвы".. Если m0fx64 в своем AcodeMorse реализует – посмотрю готовый вариант. Я так понял, если ты говоришь о плясках с ramdisk, то упомянутый мной TrueCrytp не в тему, потому, что он эту опцию видимо только на винде и поддерживал..(
А постороннюю систему загружать – это в духе:
#!/bin/bash if [ -n "$3" ]; then ARG_ERR=ERR; fi if [ -z "$1" ]; then ARG_ERR=ERR; fi if [ -n "$ARG_ERR" ]; then echo "usage: ramdisk <size in MB> [device name]" exit fi MB_SIZE=$1 let "MB_SIZE *= 2048" echo Creating ${MB_SIZE} 512-blocks ramdisk CREATED_RAMDISK=`hdid -nomount ram://${MB_SIZE}` echo New block device: ${CREATED_RAMDISK} if [ -n "$2" ]; then DISK_NAME=$2 else DISK_NAME=`basename ${CREATED_RAMDISK}` fi echo Creating volume with label: ${DISK_NAME} newfs_hfs -v ${DISK_NAME} /dev/r$CREATED_RAMDISK echo Mounting in /Volumes/${DISK_NAME} diskutil mount ${CREATED_RAMDISK}
В общем смысла, если правде в глаза смотреть, с этой "внешней" защиты – как с козла молока, правильно я понял?
А как еще можно сделать скрытую OS, кроме средств TrueCrypt? Ну т.е. тупо написать скрипт, который будет дешифровывать криптоконтейнер, распаковывать к примеру тот же AcodeMorse, подгружать его в виртуалку и после работы – обратно упаковывать?

Да, можно, но я не готов сейчас об этом говорить. Идея в том, что вы можете указать опции загрузки ядру на лету (в загрузчике). Вы также можете грузиться с бессигнатурно шифрованного диска (нужен только загрузчик; рекомендуется lilo или syslinux). Вы можете даже сразу установить на бессигнатурно шифрованный диск Debian, прям во время инсталла создать дополнительный нейтральный iso или образ для флэшки и сразу начать грузиться, как надо. Также можно грузиться с нейтрального LiveCD или LiveUSB.

Всё это уже оттестировано и работает, но, повторюсь, я не готов сейчас об этом говорить. Как я понял, есть скрипт cryptroot в рамдиске, он очень умный, ему можно подсовывать даже те шифрованные cryptsetup'ом разделы, которые в plain mode. Ядру надо будет указать что-то типа cryptopts="cipher=... hash=... size=... source=... target=...". Конечно, там не так всё просто, и если сейчас начинать это описывать, нужно создавать огромный документ с объяснением матчасти, внутренней кухни рамдиска и его создания, а также всех подводных камней... Если что, в самом рамдиске не будет ничего такого, что напрямую указывало бы на "специальность задач, для которых его используют".

P.S. Unknown'а не слушайте, в данном случае он просто не в теме. :-)

Согласен, я не любитель таких извратов.
В принципе конечно можно каждый раз в GRUB входить и редактировать по памяти, что передавать ядру, и для cryptsetup помнить все режимы, оффсеты и пр. Если это у кого-то отлажено, работает и удобно организовано, то я рад, но действительно не в теме :)

Гость (29/07/2014 17:15), супер! Это то, что нужно. Правда для меня пока не подъемно. Буду по мере возможности изучать.

Да, как-то так. Там не много команд, достаточно указывать опции каждый раз, и всё.


Да, в рамках рабочей группы я проинформирован, что решение уже есть и работает. У меня есть большая часть сырого материала, но готовых инструкций пока нет.

Перые методики шли с вываливанием в single mode, откуда вы цепляете plain mode шифрование и LVM внутри него, а потом переходите в многопользовательский режим, и всё ОК. Позже было оттестирован способ с указанием опций ядру на лету. Ещё позже — тестирование разных загрузочных медиа, как стандартных, так и специально созданных. Наконец, последний шаг — как это сделать сразу при установке Debian: установить его на бессигнатурный полностью шифрованный диск и заодно тут же приготовить загрузочный диск/USB. Этот квест тоже был пройден. Может быть, есть ещё какие-то подводные непройденные камни, я так навскидку не скажу.

Это бессигнатурка-лайт. Полная будет включать в себя паравиртуалку и сокрытие в неспользуемых местах диска. Для загрузки лучше всего подойдёт, пожалуй, А вообще, есть об этом смысл тут писать? Просто есть разные мнения, и опасения высказывались разными людьми и здесь и в других местах. Оно, конечно, достаточно хорошо защищено от полного раскрытия всех деталей "как и каким образом это делается", но всё же надо понимать, что это bleeding edge в security-технологиях, они разрабатываются специалистами для решения специальных задач. Вы не прочитаете нигде в открытых источниках о том, как это сделать, даже в английских. И в рассылке Debian вам тоже никто не блюдечке не преподнесёт инструкцию, как получить weaponized Debian.

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


В том-то и дело, что cryptroot в рамдиске довольно умён, самому ничего изобретать не надо. Если вы не укажите опции в ручную, он ничего не найдёт и напишет ошибку загрузки. Если укажете правильные опции, он запросит пароль, и если этот пароль правильный, то загрузка пойдёт как по маслу.

С созданием рамдиска там тоже весело: например, если LUKS не установлен, cryptroot не будет положен в рамдиск при его создании, т.е. вы полностью останетесь без автоматики подключения шифрованного дискового пространства. Если установлен, туда могут утечь UID'ы ваших разделов и путь/имя root-устройства (какой-нибудь /dev/VG-NAME/root), что тоже плохо. Однако, там есть варианты конфигурации, при которых всё более-менее ОК.

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


Конечно, поэтому никто и не рекомендует так делать. :-)

Спасибо большое за ответы. Надеюсь, что у меня получится поднять знания до этого уровня. В любом случае – очень признателен.

Через границу банановой республики — да. А через серьёзные страны лучше возить только чистые носители или с системой, в которой нет никакого рэндома.

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

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

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

Именно так и советуют делать в EFF:
Defending Privacy at the U.S. Border: A Guide for Travelers Carrying Digital Devices.

Ну, такова жизнь, значит.


Пусть бэкапят на здоровье. Главное, что они не смогут это сделать тайно, а то, что у данных появится нелегитимный бэкап, я учту.


Это они всегда могут сделать и по любому поводу — например, из-за посещения linuxjournal.com.


Скачать сколько? Терабайт данных? Ага, ага. Я имел в виду случай, когда нужно вести. Случай, когда без этого можно обойтись, очевиден. Там по ссылке, кстати, в таких случаях советуют позже высылать шифрованный диск по почте. Это плюс в том плане, что это не повиляет на пропуск на границе столь непосредственно, но минус в том смысле, что вы не будете знать, досматривали ли его (правда, unknown где-то кидал ссылку на то, что можно так покрасить его блёстками, что вскрыть, не оставляя следов, будет невозможно).

У меня есть часть дисков, которые не используются. Я их очищу, допустим, рандомом. Потом надо будет их везти с собой. Мне их что, принципиально потом ещё раз нулями перезаписывать, всем назло?

(правда, unknown где-то кидал ссылку на то, что можно так покрасить его блёстками, что вскрыть, не оставляя следов, будет невозможно).

В таком случае есть safe-packages, если, опять таки, я правильно понял.
На счет терабайта данных я не подумал, для меня это немыслимый объем. Но, опять таки, в зависимости от цели и ценности этих данных. Если риск большой – уж лучше потратить сутки, и даже более – на скачивание их, нежели рискуя провозить. По поводу почты – снова, ну даже если в сейф-пакет упаковать – придет он распечатанный, забэкапят данные – кому претензии предъявлять и, главное, зачем уже?) Поздно ведь, отчасти личность скомпрометирована.