id: Гость   вход   регистрация
текущее время 23:31 28/03/2024
Автор темы: Гость, тема открыта 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 След.
Комментарии
— Гость (31/05/2013 04:26)   <#>
...Почитал, читал и раньше. И до сих пор не понимаю. Растолкуйте дураку... Ни в случае TC, ни в случае DM файлов нет. ...

С таким людьми нет смысла разговаривать. Чудику дают ссылку на статью про то как реализовано и работает обсуждаемое, а в ответ от него лишь "растолкуйте".
Да и трукрипт этот чудик похоже никогда в живую не видел, с контейнерами не работал, раз не кидается такими заявлениями про файлы.
Забивает только тему объемными постами с пустопорожним бредом. Видать на обычных форумах его очень быстро банят, вот он сюда и прибился.
— Гость (31/05/2013 04:51)   <#>
У TC сайт непонятный, щёлкаешь на документацию, а там три-четыре абзаца, растолковывающие идею тем, кто про дисковое шифрование слышит первый раз в жизни, никакой внятной конкретики. Щёлкнул слева на hidden volumes — там то же самое. Проглядел текст, не вижу. Шерстить заново весь сайт? Есть полные спеки с объяснением того, как работает TC для недаунов?

Да и трукрипт этот чудик похоже никогда в живую не видел

И рад тому. Здесь TC используют чудики иного толка, у всех остальных LUKS.

Забивает только тему объемными постами с пустопорожним бредом. Видать на обычных форумах его очень быстро банят, вот он сюда и прибился.

Пока что тут твои ветки закрывали и сносили, а не мои объёмные посты. В курнный мозг объёмный пост не влазит, из-за этого начинаются проблемы с осмыслением?
— Гость (31/05/2013 09:44)   <#>
А какая нужда (ну кроме как для создания криптоконтейнера;) вайпить рандомом когда можно нулями?
— unknown (31/05/2013 10:42)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664
Остаточная намагниченность.
— Гость (31/05/2013 10:53)   <#>
Здесь TC используют чудики иного толка, у всех остальных LUKS.
в Линуксах ТС так же работает, правда с меньшим функционалом.
— gyhsal (31/05/2013 13:04)   <#>
Так же надо постараться, чтобы работа с файлами/добавление файлов в файловой системе не потревожило того свободного места.
Проглядел текст, не вижу. Шерстить заново весь сайт? Есть полные спеки с объяснением того, как работает TC для недаунов?

Ещё раз, для понимания вопроса защиты скрытых дисков достаточно посмотреть раздел "Protection of Hidden Volumes Against Damage" в документации TrueCrypt.
Мнящие себя "недаунами", но при этом неспособные отыскать этот раздел в документации самостоятельно, могут проследовать по прямому линку.
— Гость (31/05/2013 13:51)   <#>
Насчет ТС Я писал: там написано, что он просто запрещает писать файловой системе внешнего контейнера файлы в скрытую область (чтобы он знал где эта скрытая область, надо ввести два пароля: от внешнего и от срытого контейнера)
Поэтому интересно, можно ли реализовать аналогичный функционал средствами линукса
— Гость (31/05/2013 18:13)   <#>
могут проследовать по прямому линку.

По которому инструкция для чайников с окошечками и кнопками, объясняющая, куда тыкать. Неужели TC до такой степени кулхацкерский? Даже DC намного лучше задокументирован, хотя он менее популярен. Почитаем. Когда видишь инструкцию с окошками, и пару абзацев между ними, надежда найти там важную техническую деталь стремится к нулю. Те, для кого такие инструкции пишут, вникать в технические детали всё равно не будут.
— Гость (31/05/2013 18:16)   <#>
Поэтому интересно, можно ли реализовать аналогичный функционал средствами линукса

Можно об этом подумать, но TC'e заведомо проще: им не надо собирать функционал из штатных возможностей каждого дистрибутива Linux, а достаточно всего лишь внести его в собственную программу. Обратная сторона их подхода — возникновение вопроса, зачем эта программа установлена. Не за тем ли самым, чтобы скрывать?
— Гость (01/06/2013 02:14)   <#>

Ну что ж, следуем:

As soon as a write operation to the hidden volume area is denied/prevented (to protect the hidden volume), the entire host volume (both the outer and the hidden volume) becomes write-protected until dismounted (the TrueCrypt driver reports the 'invalid parameter' error to the system upon each attempt to write data to the volume). This preserves plausible deniability (otherwise certain kinds of inconsistency within the file system could indicate that this volume has used hidden volume protection).

Правда, в этой цитате всё равно нифига не понятно, за счёт чего отрицаемость во внешнем контейнере возникает. Даже если система знает, куда не надо писать, и начнёт это претворять в жизнь, это отразится на структуре файловой системы внешнего контейнера, то есть, вынеждна полететь лесом либо отрицаемость скрытого контейнера, либо его защита от повреждений. Это то, что любой здравомыслящий подумает, почитав цитируемую документацию. Вопрос, однако ж, интересен, да и Гость (31/05/2013 13:51) настаивает, поэтому делаем официальный запрос неземному искуственному интеллекту и получаем ответ:

В TC скрытый раздел размещен в свободном пространстве открытого, причём ОС не знает, где находится скрытый раздел, но при попытке туда записать запись будет заблокирована. Авторы рекомендуют форматировать внешний раздел в FAT и заполнять его файлами не более, чем на 10% объема, после чего его никогда не трогать: раз отформатировал, записал файлы в подставной раздел и больше не трогаешь. Такой подход еще давно критиковался, поскольку вырисовывается очень характерный паттерн использования. Cтрого формально доказать наличие скрытого тома, получается, нельзя, но достоверно предположить — можно, поэтому целесообразно считать такую защиту лишь уловкой против слабого противника, который попросту не знает, что такое может быть.

TC дружит с любыми ФС, которые поддерживает Windows и которые удастся к ней прикрутить, но из коробки он умеет форматировать только в FAT и NTFS. Номинально можно использовать NTFS во внешнем томе, но NTFS устроена сложнее FAT'а. Она может попытаться записать в скрытую область, после чего возникнет ошибка записи, и сектора пометятся как сбойные, что сразу спалит наличие скрытого тома. Однако, FAT при соблюдении ряда условий позволяет записать немного файлов так, чтобы они не попали в скрытую область, но сам ряд этих условий — уже паливо, поэтому такая защита — по большому счету, фикция.

Казалось бы, что если хорошо знать сложую ФС (такую, как NTFS), то можно сформулировать рекомендации, как и что записывать так, чтобы в скрытый том ничего не попало, но тут возникает масса сложностей, и много места для ошибки, поэтому может выйти всё ещё хуже, чем было в FAT. Никто на 100% не знает, как устроена NTFS. Не даром до сих пор линуксовый NTFS-драйвер иногда ломает том при записи. Вся документация по NTFS получена реверс-инжинирингом, и, как показывает практика, её достаточно для надежного чтения, но не для надежной записи. Описание структуры NTFS есть, но нет полного понимания тонкостей, в результате чего нельзя гарантировать надежную запись на любой NTFS-том, находящийся в любом состоянии. Например, usn journal (системный журнал операций) до сих пор документирован не полностью, как и логика восстановления при сбоях. Иными словами говоря, наличия знаний структур NTFS мало — надо понимать, как они взаимодействуют во всех возможных ситуациях, как обеспечить атомарность, откат операций, обработку ошибок и т.д., а знания самих структур достаточно лишь для чтения данных. Как только начинается запись, там уже такие дебри... Подводя итог, можно сказать, что никаких чудес в TC нет, там всё предельно тупо.

Считайте мнение истиной в последней инстанции. Если хочется сделать что-то лучшее, чем TC, на основе DM, то скопировать идею с TC не получится — просто потому, что никакой особой идеи в TC нет. Смайлики в конце добавьте по вкусу.
— Гость (01/06/2013 02:37)   <#>
Ничего не мешает создать криптоконтейнер в трукрипте, заполнить его файлами, потом дефрагментировать с перемещением всех файлов в начало "диска". А в свободном пространстве тома/раздела разместить уже свой скрытый том. Прием проверенный и старый, как копролиты мамонта.
— Гость (01/06/2013 02:59)   <#>
Гость (01/06/2013 02:37) вы уверены что в результате не выйдет хуже? С ходу возникают следующие вопросы:
Зачем делалась дефрагментация с перемещением всех файлов в начало (стандартная виндовая утилита так не делает) и почему после дефрагментации не было записи?
После дефрагметрации фрагменты файлов остаются на старых местах, почему вместо них там случайный мусор? Напомню, состояние диска когда все файлы находятся строго в начале не могло быть получено само собой. Что вы будете делать если внезапно в середине тома окажется неперемещаемый объект (в ntfs такие объекты есть)?
Извратиться по всякому можно, но это будет лишь размен одного трюка на другой. ИМХО отрицаемость это фикция и излишнее усложнение не несущее особой пользы.
— Гость (01/06/2013 03:20)   <#>
отрицаемость это фикция и излишнее усложнение не несущее особой пользы.

Я бы не был столь категоричен, но разумное зерно в этом есть. Отрицаемость, даже при её идеальной реализации, требует аккуратной легенды, продуманных пропорций между объёмом обманки и в всего контейнера, соответствие содержимого обманки легенде и так далее.

Чисто технически всё решается и без сверхусложнённых трюков. TC растворяет скрытый контейнер в открытом, пользуясь тем, что шифрованные данные неотличимы от случайных. В методе же DM скрытый контейнер растворяется в случайных данных неиспользуемого места диска. Суть (методика) в обоих методах одна и та же.

Что касается модели отрицаемости TC, там, по всей видимости, была идея создать юридически приемлемую неоднозначность. Грубо говоря, авторам не столько важно, какие TC вызывает подозрения, сколько то, что отрицаемость TC будет достаточной для непредвзятого суда, опирающегося на юридические формальности и требующего серьёзные обоснования каждого подозрения. Может, в РФ эта модель совсем неприменима, но ведь и TC — продукт не очечественный.
— Гость (01/06/2013 15:31)   <#>
Со времен msdos'а люди привыкли пользоваться пакетами утилит. Однозначно понимая, что в системе либо ничего нет, либо всегда можно найти более удачные аналогии замены "стандартной хрени". В windows'ах стандартная утилита для дефргаментации – это старый добрый Diskeeper. У которого полно недостатков и в реальности им крайне мало кто вообще пользуется.
Любая нормальная утилита для дефрагментации стремится не только собрать несколько кусков файлов в один, но и убрать на диске пустое пространство между файлами. Тогда новые файлы, добавляемые на этот раздел, не будут дробиться на множество фрагментов. Из-за того, что файловая система распихивает данные по пустующим секторам.
Любая дефрагментация тома в fat сводится к тому, чтобы сдвинуть данные всех файлов во младшие сектора.
Да и за двадцать лет использования дисков на fat'ах уже не одну сотню раз убеждался, что на свеже отформатированном томе файлы попадают именно в начало, в первые сектора. Потому, если до этого данные на диске подлежали уничтожению, то во всех его секторах, кроме занятых файлами, и будет случайный мусор. Такое же наблюдается и в контейнерах созданных TrueCrypt'ом.

Этот самый Гость (01/06/2013 02:59) типичный образчик тупого, неквалифицированного, но жутко самовлюбленного человека. Таких лучше сразу посылать на три буквы. Это паразиты, ничего нового в общество не привносящие, поскольку им лениво изучать что-либо самостоятельно. Познают мир через вбросы провокационных и априори ложных заявлений. Такие находят себя в том, чтобы в комиссарах ходить, да заград отрядами командовать. Свое желание жить не думая где-то в глубине души приравнивают к "наеб@ть систему".
— Гость (01/06/2013 17:20)   <#>
Гость (01/06/2013 15:31) Да ты просто тупой мудак по жизни. Стандартная утилита дефрагментации это ms defrag, балда. А стандартная файловая система – ntfs, про которую я тебе и втыкал, тупая скотина. Но чукча не читатель, чукча писатель, поэтому отвечаю тебе на твоем языке.
На страницу: 1, 2, 3, 4, 5, ... , 7, 8, 9, 10, 11 След.
Ваша оценка документа [показать результаты]
-3-2-1 0+1+2+3