id: Гость   вход   регистрация
текущее время 19:32 26/07/2017
Автор темы: Гость, тема открыта 22/04/2013 18:49 Печать
Категории: приватность, инфобезопасность, защита дисков, отрицаемое шифрование
создать
просмотр
ссылки

Отрицаемое шифрование


Какими методами можно обеспечить действительно сильное отрицаемое шифрование? Допустим власти/бандиты могут и будут применять силу, чтобы выбить ключи.
В трукрипте возможен только 1 скрытый контейнер, и это всем известно, поэтому ректотермальный криптоанализ будет применяться до тех пор, пока не раскроете оба ключа, даже если вы не создавали этот скрытый контейнер.


Как можно обеспечить неизвестное заранее число скрытых контейнеров?
Тут http://en.wikipedia.org/wiki/Deniable_encryption прочитал про rubberhose, который обеспечивает это и защиту от разных способов анализа зашифрованных данных, но проект не обновлялся с 2000 года, и не понятно, насколько он надежен на практике.
Еще прочитал про возможность создавать контейнеры с заданым смещением на диске, как тут
http://sourceforge.net/projects/stlth/files/


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


Какие способы вы посоветуете? Может есть относительно простые в использовании утилиты?


 
На страницу: 1, 2, 3, 4, 5, ... , 7, 8, 9, 10, 11 След.
Комментарии
— Гость (24/04/2013 23:22)   <#>

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

Ещё одна важная деталь — мы считаем, что пользуемся обычным диском с крутящимися частями. С SSD в плане отрицаемости плохо будет, и решение, что делать с SSD, мне неочевидно.


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


Нет, вся цель этого наворота — отрицать какую-либо причастность к каким-либо данным сразу. Скажешь одно слово — скажешь и второе, его вытянут. Стратегия должна быть как на допросе: всё отрицать, ни в чём не сознаваться. Объяснять, зачем затёр диск, тоже можно естественно: "взял с рук и не был уверен, что там осталось от данных предыдущего владельца (вдруг пиратка или ещё что похуже было). Вот, чтобы не рисковать, всё и затёр." Зачем LiveCD — тоже просто: recovery disk на случай чего, если слетит основная система.


В /comment63574 не зря было написано
Например, как формализовать понятие пытки, признания? Вопрос интересный, глубокий. Или вот тот же паяльник. Какова оптимальная стратегия его применения? Не всё там так просто.

Вы исходите из экстремального случая всемогущих бандитов, которые могут убивать, кого захотят, не имея никаких издержек, а у вас нет ни прав, ни сил, ни возможностей хоть как-то противостоять этому. По такой логике всегда оптимально убивать любых свидетей (Помазун одобряэ). Убивая свидетеля, решаешь одну задачу ценой оставления ещё большего числа других, куда более серьёзных улик. Оптимальный план должен предусматривать в том числе случаи, когда "не попёрло". А если бандитам за убийство 10 лет зоны дадут? Им действительно так нужна ваша информация, чтобы рисковать 10-ю годами собственной жизни? А если, попадя в лапы правосудию, всплывёт не только инцидент с вами, но и другие случаи, по которым в совокупности бандитам могут пожизненное дать? Поэтому я призываю к экономическому подходу, к подходу рисков и издержек.

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


Система — LiveCD. Он грузится, если сделан по уму, так: файловая система монтируется, файлы считываются в память, дальше возникает образ диска в оперативной памяти. Все изменения файлов отражаются в памяти, а содержимое LiveCD не меняется ни на бит. Компьютер выключил — все данные из ОЗУ исчезли. Если не диск специально руками ничего не писал, на нём тоже не будет никаких изменений.

Полезные хинты: UnionFS, SquashFS.


Тут тоже есть решение, но не такое удобное, как LiveCD. Короче, грузимся с LiveCD, считываем данные через dd с диска вышеописанным способом, расшифровываем их и кладём на MicroSD-карточку. Туда будет записан загрузчик, гипервизор и базовая часть ОС. Дальше ПК выключаем и грузимся с MicroSD-карточки. Если загрузка организована правильно, карточку можно будет после загрузки и монтирования (unionFS) всего нужного вытащить, а ОС продолжит работать до перезагрузки. Тем временем карточку можно затереть, чтобы не было следов. Беда в том, что означенные действия придётся повторять каждый раз при перезагрузке, но работать оно будет.
— Гость (24/04/2013 23:48)   <#>
Система — LiveCD. Он грузится, если сделан по уму, так: файловая система монтируется, файлы считываются в память, дальше возникает образ диска в оперативной памяти. Все изменения файлов отражаются в памяти, а содержимое LiveCD не меняется ни на бит. Компьютер выключил — все данные из ОЗУ исчезли. Если не диск специально руками ничего не писал, на нём тоже не будет никаких изменений.

Не, я про файловую систему обманной операционки, то есть ту что на диске.
То есть, при изменении шифрованных данных через LiveCD останутся ли какие-то сведения в файловой системе на основном диске или, может, еще где о дате изменения битов в этой шифрованной части диска?
Наверное нет, даже если весь диск замонтирован из LiveCD (а монтирование всего диска не нужно, чтобы считать нужный шифрованный блок, верно?), в файловой системе даты хранятся для файлов, а свободное место – это не файлы для нее. То есть изменение свободного места никакой информации после перезагрузки не оставит о дате изменения или типа того. Я плохо на этом лоу левеле ориентируюсь просто.
А почему
SSD в плане отрицаемости плохо будет
— Гость (24/04/2013 23:55)   <#>
Портабельная версия в астрале находится?
где бы она не находилась, коммент касается этого заявления:
поэтому TrueCrypt на ПК = обоснованные подозрения существования скрытых контейнеров.
а если его там нет? то следовательно и контейнеров нет? или что мы понимаем тогда под аббревиатурой "ПК". необходимо уточнение. или так: если на ПК нет ТС, то = ищем носитель с ТС где то рядом. так? если не находим носитель = на ПК нет криптоконтейнеров. так?
— Гость (24/04/2013 23:58)   <#>
Наверное нет, даже если весь диск замонтирован из LiveCD
а если на LiveCD есть ТС, значит ли что где то рядом есть криптоконтейнер(ы)?
— Гость (25/04/2013 01:32)   <#>

Адресное пространство диска состоит из секторов. Сколько их, какие разделы и пр. можно узнать, выполнив из-под рута команду
# fdisk -l -u /dev/sda
(вместо sda подставьте свой диск, он светится в выводе команды df -h). Это самый нижний уровень. Размер сектора — что-то типа 0.5kB.

При разбиении диска на разделы сектора делятся между разделами так, чтобы не перекрываться. Например, если всего секторов 100, то от 0 до 10 секторов — первый раздел, от 11 до 23 — второй, от 24 до 100 — третий. Могут быть дыры в адресации между разделами. Информация о том, где начинается и где заканчивается каждый раздел, хранится в так называемой таблице разделов — это первые сектора в начале диска. Например, если вы тупо весь диск затёрли рандомом, никаких разделов на нём не создано, таблицы разделов нет.

Device mapper (dm) интересен тем, что может объединять произвольные сектора на диске в логические единицы и работать с ними формально так же, как с дисковыми разделами. Правильно такие группы секторов, как и разделы дисков, называются "блочными устройствами".

Шифрование в Linux/BSD кладётся поверх блочного устройства. Если оно бессигнатурное, то всё хорошо: каждый сектор перед записью на диск шифруется, что фактически означает замену одних случайных битов в секторах на другие. Не зная ключа шифрования, их не отличить. Чему шифруемый сектор соответствует, шифрованию не важно (т.к. то — более высокий уровень абстракции).

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


Верно. Вы монтируете (подключаете) только то, что вам нужно. Хотите — нескрытый раздел и файловую систему на нём, хотите — скрытый. Естественно, чтобы всё было чисто, работая с LiveCD не надо монтировать те файловые системы, которые отвечают за обманную ОС и обманные нешифрованные файловые системы, т.к. иначе будет заметно, что они монтировались с внешнего носителя, а не с самой обманной ОС (по сопоставлению дат модификаций и пр.). Ну, т.е. это не фатально, но делает нам ненужную утечку.


Естественно. С точки зрения основной нескрытой файловой системы — это свободное место, потенциально доступное на запись. Что в нём физически записано, файловой системе вообще не важно, т.к. считается, что оно не используется. Есть, конечно, всякие recovery-files-тулзы, которые как раз сканируют его и ищут удалённые по ошибке файлы, но в нашем случае это не страшно, т.к. у нас всюду один рандом.


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


В SSD реальным содержимым секторов управляет не ОС, а внутренний микроконтроллер. В общем случае, реально там может быть записано одно, а ОС показываться другое. Микроконтроллер перекидывает данные между секторами, обнуляет для ускорения записи данных ячейки, помеченные как неиспользуемые и т.д. Всё очень сложно. Соответственно, в лаборатории можно обойти уровень контроллера и считать в лоб настоящее содержимое ячеек. Есть команды для управления всем этим делом напрямую (хинт: TRIM), но его не все ОС и, тем более, системы шифрования поддерживают.

Даже если с TRIM всё решается, всё равно остаётся следующая дилемма: пометите все сектора как используемые, чтобы микроконтроллер их не обновлял, — вызовите подозрение (зачем вам неиспользуемое место на диске?) и сильно ускорите износ носителя (SSD должен иметь диапазон свободных ячеек для выравнивания износа); а если пометите, как неиспользуемые — микроконтроллер просто тупо сотрёт ваши данные (он этим занимается в фоновом режиме работы носителя во время простоев), т.е. предложенная схема вообще работать не будет. Т.о., я пока не вижу, как сделать так, чтобы предлагаемая схема взлетела на флешках, SD-карточках и SSD-носителях, не уничтожая отрицаемость.

Это вольный пересказ основных проблем. За подробностями отсылаю вас к /comment39601, /comment39607 и др. Также гуглите TRIM site:pgpru.com


Теоретически — так, практически — юз TC из-под основной ОС осядет в логах ОС, где бы сам ТС ни находился, и на 100% вы от этих логов не отмоетесь. Останутся пути к исполнимым файлам, история и пр. и пр.


Это вызывает подозрения. Цель варианта — не показывать использование намеренно установленных программ. LUKS, dm и openssl есть в любом дистрибутиве Linux по умолчанию, поэтому их наличие ни о чём не говорит. Наличие же TC на чём-то говорит о том, что кто-то его намеренно установил. Раз намеренно, возникает вопрос "а зачем?". Вот мы и получили почву для подозрений.
— unknown (25/04/2013 10:13, исправлен 25/04/2013 10:14)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664
LUKS, dm и openssl есть в любом дистрибутиве Linux по умолчанию, поэтому их наличие ни о чём не говорит.

И даже в установочных, спасательных, гибридных и прочих готовых образах Live-CD/USB.


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

— Гость (25/04/2013 11:24)   <#>
юз TC из-под основной ОС осядет в логах ОС
если портабельная программа оставляет следы ее использования в системе, то она не портабельная или недопортабельная. портабельная программа не должна оставлять следов даже в реестре (если речь о Винде).
— Гость (25/04/2013 15:42)   <#>
Прочитал, что если зашифровать диск трукриптом, создать скрытый раздел, а потом быстрым форматированием отформатировать диск, то диск будет обычным, видимым системе как отформатированный на который можно осторожно записывать файлы, а скрытый раздел трукрипта при этом будет работать.
А если со скрытым разделом сделать аналогичную операцию, данные там как я понял пишутся с начала, а не с конца, поэтому могло бы получиться? Тогда получим скрытый раздел в скрытом, наличие которого нельзя будет доказать. Надо будет попробовать.
— Гость (25/04/2013 18:58)   <#>

Инструкции нет. Для начала надо сделать всё самому, протестировать, и только потом писать how to. Что касается Керхгоффса, какие-то косвенные признаки будут, вопрос лишь в степени их косвенности. Если схема станет популярной, наличие высокоэнтропийных данных в неиспользуемых местах файловой системы станет подозрительным моментом. Однако, можно сделать и более гибкую систему: взять реальную файловую систему с кучей удалённых файлов, которой раньше пользовались, найти там скриптом те неиспользуемые сектора, которые высокоэнтропийны, и использовать для записи только их. Теоретически можно придумать (и хотелось бы) автоматизированный тул, который, с одной стороны, позволяет работать с любой файловой системой, и, с другой стороны, поддерживает обновление файлов на нескрытой ФС. Тем не менее, всё равно будет можно создать анализатор файловой системы, который будет с какой-то вероятностью детектировать то, что "мусор" на свободном месте искуственно зарандомлен. Это, скорее, вопрос к тем, кто хорошо разбирается в системах восстановления удалённых файлов: можно ли после длительного использования такой файловой системы определить, было ли в неё стороннее вмешательство?

Отрицаемость — не чисто техническое понятие, поэтому с ней всегда были траблы. То, что легко отрицаемо сейчас, станет очень подозрительным, если будет распространено и появятся программы, анализирующие определённые свойства файловых систем. С другой стороны, повсеместное распространение каких-то программ или технологий может добавить отрицаемости туда, где её изначально не было. Аспект сугубо социальный и психологический. Можно написать сколь угодно правдоподобную легенду о том, от чего диск выглядит именно так и не иначе, но эта легенда может перестать работать, как только её под копирку будет заученно произносить каждый. В основном развитие отрицаемости в программных решениях шло по принципу «давайте сделаем так, чтобы противник математически не мог отличить две ситуации: когда скрывают, и когда так получилось случайно; тогда у суда не будет веских оснований». Но всем понятно, что эта отмазка перестаёт работать сразу же, как только все начинают какой-то методикой пользоваться только ради скрытия. Тем не менее, прогресс не стоит на месте. Современные методы лучше и надёжнее чем то, что использовалось когда-то ранее.

Вопрос отрицаемости всё же очень интересный. Я начал им интересоваться ещё много лет назад. Пытался придумывать какие-то решения самостоятельно, обсуждать с разными гуру, специалистами, читать литературу, даже обсуждать с фирмами, оказывающих профессиональные услуги в ИБ. Естественно, эти вопросы позже были подняты и на pgpru.com. По мере роста понимания стало ясно, что простых способов сделать отрицаемость нет, но фоново я продолжал об этом думать и обсуждать с другими. Первое, более-менее связное и чистое решение постепенно выкристаллизовалось в этом топике по результатам открытых и закрытых обсуждений. Оно тоже обсуждалось с неглупыми людьми, в том числе с разработчиками криптографических файловых систем. Несколько человек его настоятельно рекоменодвали не публиковать в открытом доступе или, по крайней мере, не описывать все детали, но, как видите, я рекомендацию нарушил. Во мне всё ещё живёт вера в то, что полностью закрытые решения не могут быть безопасными, а открытость и коммуникация с другими дадут больше, чем свой частный и приватный костыль.

С другой стороны, понятно, что публичное раскрытие всех деталей может сильно ударить по отрицаемости — так было бы приватное решение для себя, никто б ничего не мог заподозрить, а теперь оно описано публично. Форензики, которые будут его анализировать, находками уязвимостей делиться с открытым сообществом не будут, — надо это понимать. Наконец, автор решения теряет отрицаемость при использовании схемы для самого себя: раз он опубликовал способ скрытия, значит он сам этот способ и использует (или, по кр. мере, может использовать), к чему можно всегда проаппелировать, даже не вникая в степень отрицаемости и технические методы. В общем, бороться с бандитами, играя на их же поле по мирным правилам, трудно.


Должна или не должна — вопрос философский, на практике следы есть, и следы есть всегда. Они даже в любом Unix остаются, а про винду даже заикаться не буду. Именно поэтому всюду настоятельно рекомендуется использовать полнодисковое шифрование (и в винде в том числе), а не шифровать только те разделы, где хранятся приватные данные. Впрочем, вы можете придерживаться и альтернативного мнения, чтобы не было «слишком хорошо».


Да, кажется, что-то такое было упомянуто в одном из комментариев к этому топику. Про TC ничего комментировать не могу, т.к. сам им никогда не пользовался.
— Гость (25/04/2013 19:40)   <#>

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

Если разрешена запись на диск, нельзя быть уверенным, что что-то не оставляет следов. Они могут вылезти в самом неожиданном месте. Например, юзаешь TotalCommander, а он в своем ini-файле запоминает последние посещенные директории и открываемые файлы. Стоит пунтосвитчер — он пишет в свой журнал запуски программ и многое другое. А антивирус не только пишет, но ещё и отправляет домой.

Любой сторонний софт может зафиксировать следы действий, которые его косвенно касаются (а иногда, даже если вообще не касаются). Пример — программа, использующая dll для инжекта в процессы и реализации каких-нибудь сервисных функций (допустим, проксификатор). dll имеет свой отладочный лог, в который пишется, в какой процесс программа загружается. И, бац, в этом логе отмечаются все запускаемые программы. Или это может делать драйвер принтера примерно аналогичным способом (реально встречалось и такое). Поэтому то, что портабельный софт не оставляет следов использования — адский бред. Есть запись на диск — смело считаем, что любое действие оставляет следы.
— Гость (25/04/2013 22:55)   <#>
рекомендуется использовать полнодисковое шифрование (и в винде в том числе)
ну что здесь филосовского? рекомендация на то и рекомендация и носит общий характер, ибо тот кто дает совет не может прогнозировать, допустим, насколько хорошо или правильно создано портабельное приложение. отсюда и подобное предложение. лучше перебдеть, чем недобдеть.

а не шифровать только те разделы,
наверно есть еще и иные причины не оставлять в свободном доступе дисковые пространства на ПК.

если зашифровать диск трукриптом, создать скрытый раздел
может вы всетаки имели ввиду контейнер? или вы что путаете с созданием обманной ОС, которую кстати можно создать только на Виндах.

При умолчательных настройках оставляет,
что занчит "умолчательные настройки". портабельно приложение, если оно правильно создано, должно прописываться только в печонице своей директории и нигде больше, повторюсь что при условии его правильного создания.
TBB много где оставляет следы в системе? если честно, я не замечал, НО у некоторых, странным образом, они остаются..
— Гость (26/04/2013 00:30)   <#>

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


Много. Если запускаете из командной строки, то в истории комманд шелла. Если из файлового менеджера, то в его истории. Даже если историю стереть, данные на диске остаются, их можно восстановить или найти огрызки упоминаний про TBB, что будет подозрительно. Помимо этого, TBB пишет в /tmp. Если firefox сегфолтнется, может появиться сообщение в логах ядра. Попытка запрятать все следы — переливание из пустого в порожнее, поэтому нужно решать проблему кардинальным методом — полнодисковым шифрованием.
— Гость (26/04/2013 02:19)   <#>
"сдаемсу" © полнодисковое, так полнодисковое. тем более что оно так и есть ))
— SATtva (26/04/2013 09:02)   профиль/связь   <#>
комментариев: 11507   документов: 1035   редакций: 4022
Что, не логично, что если противник знает, что ему нужен ровно 1 пароль в дополнение к основному, то он будет пытать до конца, в то время, когда он не знает, сколько должно быть паролей, он где-то остановится?

К тому времени, как он решит остановиться, тушке пароленосителя будет уже совершенно всё равно.

5. Если не выдерживаешь, раскрываешь 1 наименее компрометирующий контейнер. Если пытают дальше и не выдерживаешь, выдаешь еще один. На n-м контейнере упираешься, что больше нет.
7. Профит тебе

Упираешься всеми оставшимися двумя пальцами? На месте этих конкурентов/власти/бандитов, я бы отрубил и их. Ну, для надёжности. Дело в том, что если Вы сдали оппоненту контейнер n, у него нет никаких оснований исключать наличие контейнера n+1, и раз уж дело зашло так далеко, нет смысла прекращать процесс извлечения. Странно, что не видите этот очевидный факт.
— unknown (26/04/2013 09:31)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664
TBB много где оставляет следы в системе? если честно, я не замечал, НО у некоторых, странным образом, они остаются..

Достаточно, к сожалению. Даже при беглой проверке это выявилось, как только у разрабов руки дошли:
Forensic Analysis of Tor on Linux.
На страницу: 1, 2, 3, 4, 5, ... , 7, 8, 9, 10, 11 След.
Ваша оценка документа [показать результаты]
-3-2-1 0+1+2+3