id: Гость   вход   регистрация
текущее время 13:32 28/03/2024
Владелец: SATtva (создано 19/07/2008 14:40), редакция от 19/07/2008 14:40 (автор: SATtva) Печать
Категории: софт, приватность, инфобезопасность, политика, защита дисков, truecrypt, уничтожение информации, следственные мероприятия, отрицаемое шифрование, спецслужбы
http://www.pgpru.com/Новости/2008/СкрытыеРазделыTrueCryptМогутБытьНедостаточноСкрытыми
создать
просмотр
редакции
ссылки

19.07 // Скрытые разделы TrueCrypt могут быть недостаточно скрытыми


Возможности скрытых разделов и отрицаемого шифрования TrueCrypt приобретают повышенное внимание. В свете участившихся случаев досмотра содержимого ноутбуков и носителей информации на пограничных пунктах США (и даже конфискации электронной аппаратуры) ряд правозащитных организаций выпустили рекомендации, в числе которых как одна из наиболее действенных мер выступает использование скрытых разделов TC. Группа исследователей из университета Вашингтона (включавшая и Брюса Шнайера) провела анализ этой функциональности (на примере TC 5.1) в реалистичной среде MS Windows.


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


Скрытые разделы TrueCrypt не защищены от жёстких условий полной модели угрозы. Так, если противник располагает несколькими образами диска, снятыми через небольшой интервал времени, и содержащими изменения шифртекста ближе к концу раздела (там, где располагается скрытый раздел), это наведёт на серьёзные подозрения. Также подозрения о наличии скрытого раздела могут возникнуть при изучении журнала ФС (если криптоконтейнер TC хранится на журналируемой ФС) или физических характеристик носителя; эти аспекты отражены в официальной документации, и пользователь должен быть осведомлён о мерах предосторожности. Однако, даже при допущении, что злоумышленник может снять образ диска лишь один раз (сценарий с конфискацией носителей), на компьютере пользователя может быть немало свидетельств использования скрытых разделов.


Первостепенный канал утечки — это функционирование самой ОС. Windows автоматически запоминает пути, имена и уйму других компрометирующих метаданных открываемых документов и сохраняет их в меню Пуск. В своей работе исследователи показывают, как можно практическим образом эксплуатировать полученные таким путём сведения и предъявить пользователю уголовное обвинение, если он положится на "отрицаемость" скрытых разделов.


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


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


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


Вторым предложением выступила модификация загрузчика и возможность создания полностью зашифрованной "скрытой ОС". Именно это решение было реализовано в TrueCrypt 6.0 после того, как исследователи передали свои результаты разработчикам программы. Правда некоторые возможности для раскрытия оставляет и этот вариант. Возможно, поэтому Брюс Шнайер сохраняет скептицизм в отношении данной программы.


Источник: Defeating Encrypted and Deniable File Systems: TrueCrypt v5.1a and the Case of the Tattling OS and Applications


 
— unknown (22/07/2008 09:42)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664
После прочтения работы появилось некоторое количество мыслей.

Авторы исследовали среду Windows, а так-ли хорошо обстоят дела в *nix-like и что-там можно сделать?

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

Однако данные могут утечь в своп. Но даже в некоторых инсталляторах в экспертном режиме предлагается шифровать своп временным случайным ключём. Данные могут утечь в /tmp. Аналогично, можно сделать, чтобы эта директория была на шифрованным случайным одноразовым ключем разделе, на котором каждый раз после перезагрузки будет создаваться файловая система заново. Кое что можно узнать из /var/spool – там иногда могут сохраняться копии недопечатанных документов – директории оттуда можно вынести символическими ссылками в /tmp. Правда должен срабатывать специальный скрипт, который бы это делал грамотно с использованием комманды mktemp и пересозданием ссылок заново.

Правда всё это конфликтует с технологией hibernate, но она не всем и нужна.

Всё это полезно даже просто для предотвращения утечки сведений о данных в шифрованных дисках, но недостаточно для отрицаемого шифрования. Сведения о подключаемых дисках могут оставаться в различных системных логах (логах работы lvm например, в сообщениях о сбоях проверок файловых систем и т.д. – при этом может быть записан ID диска или FS). Как это решать – непонятно.

Другой вопрос. Если завести скрытого пользователя и перенести его в скрытый шифрованный диск, то запись о непонятном пользователе останется на основной системе в /etc/passwd, /etc/shadow, /etc/group, возможно конфигах pam и др.

Можно конечно перенести пользователя в chroot, так чтобы в системе о нём никаких записей не было но тогда будет не запустить графическое окружение и требует копирования всех необходимых чатей системы для работы. Можно использовать виртуальные машины, но это громоздко и не всегда удобно.

Другой вариант: взять самого обычного пользователя и оставить его как есть, используя для обычной деятельности, а в скрытом разделе создать копию его каталога, но для скрытой деятельности. При открытии срытого раздела – монтировать "скрытого" пользователя поверх каталога основного. Тогда записей о лишних пользователях в /etc не будет.

Чтобы не оставлять следов в shell_history, программа отрицаемого шифрования должна быть постоянно запущена при каждом входе в систему на отдельной консоли (чтобы не знать в какие моменты и как часто ею пользовались) и иметь свой внутренний ограниченный shell, не сохраняющий набранных комманд на диск и имеющий ограниченный набор комманд – только связанных с шифрованием и монтированием.

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

Правда, даже если это всё реализовать и широко распространить с опциональной возможностью инсталляции в дистрибутивах, всё равно остаётся масса сомнений, нет ли других каналов утечки и насколько это может помешать работе обычных программ.
— Гость (22/07/2008 16:07)   <#>
Данные могут утечь в /tmp.

Если /tmp в оперативной памяти физически, а своп шифруется...

Кое что можно узнать из /var/spool

Шифровать /var и спрашивать пароль при загрузке. Отрицаемость нулевая. Скрытый /var? Тогда уж проще скрытую ос в виртуальной машине.

Сведения о подключаемых дисках могут оставаться в различных системных логах (логах работы lvm например, в сообщениях о сбоях проверок файловых систем и т.д. – при этом может быть записан ID диска или FS). Как это решать – непонятно.


Что ессно вызовет массу вопросов дотошных проверяющих. Зачем это вы отключили?!

Можно использовать виртуальные машины, но это громоздко и не всегда удобно.

Но это самый простой выход, который куда проще, чем следить за тысячами возможных утечек. Не верите? Я когда-то реализовывал большинство из вами описанного, но наткнулся на такую мазу: когда-то в глубокой древности, когда ещё люди были непуганными а софт – нелицензионным, /мну имел неосторожность сохранить в конфиге ядра строчку свидетельствующую о наличии на машине специального софта. И вот, через несколько лет, я случайно наткнулся на тот факт, что ядро при компиляции сохраняет в себе весь конфиг как есть, вместе с комментариями, вклюая ту самую компрометирующую строчку :) Ессно этот конфиг извлекается обратно простейшей командой натравленной на бинарь ядра. И подобных скрытых угроз очень много.

Чтобы не оставлять следов в shell_history, программа отрицаемого шифрования должна быть постоянно запущена при каждом входе в систему на отдельной консоли (чтобы не знать в какие моменты и как часто ею пользовались) и иметь свой внутренний ограниченный shell, не сохраняющий набранных комманд на диск и имеющий ограниченный набор комманд – только связанных с шифрованием и монтированием.


Остальное не осилил (не понял). /tmp в оперативе физически.

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

unknown решил запостить ""[:]||Z|||[:]"обзор ранее уже миллион раз обсуждавшегося на форуме. И скрытый пользователь не панацея, как в последней цитате, ибо легко обмануть машину но не человека: как вы симитируете деятельность в скрытом каталоге, неотличимую от реаьной? А если вам оппонент пошлёт письмо, а потом задержит вас с диском и попросит его показать на нём (а оно на шифроразделе)? Какая здесь будет отрицаемость? Или со скрытого раздела всегда ходить в сеть только через тор? А не сильно ли это демаскирующий фактор? И т.д. и т.п. В теме "конкретный пример" в конце шло обсуждение виртуальных машин, и говорилось что злоумышленная программа всегда сможет отличить виртуальную машину от реальной. Да и просто, чтоб запрятатьвиртуальную машину, надо уже иметь скрытый раздел... Получается, для B надо сделать сначала A, а для A надо снаала сделать B. Круг замкнулся. Можете поискать в форуме по слову "стегоОС", где были произнесены слова о том, что проблема не столько в компьютерах, а куда шире. Для отрицаемости, даже при условии существования стегоОС, вам понадобится чтобы она была предельно распространена, иначе сам факт наличия её у вас вызовет подозрения. И вообще, всё связанное с "социальной" стеганографией (когда требуется на математическое доказательство отсутствия скрытой информации, а доказательство на человеческом уровне правдоподобности) – слишком сложная тема, из области идеального и недостижимого. Лично мне кажется, проблему следует решать по другому: не хранить ту информацию, которую нельзя раскрыть. Это не всем подойдёт, но многим. Действительно, зачем вам хранить... ту же самую переписку за несколько лет? Достаточно хранить её за последние несколько дней. Тогда оппоненту будет невыгодно ломать все кордоны, чтобы получить доступ к информации, ибо её там совсем немного. Опять приходим к выводу о том что ИБ – это прежде всего экономика.
— SATtva (22/07/2008 16:30)   профиль/связь   <#>
комментариев: 11558   документов: 1036   редакций: 4118
Лично мне кажется, проблему следует решать по другому: не хранить ту информацию, которую нельзя раскрыть. Это не всем подойдёт, но многим. Действительно, зачем вам хранить... ту же самую переписку за несколько лет? Достаточно хранить её за последние несколько дней.

Тот же Шнайер последние годы твердит ровно о том же. Шифрование — полезное средство, но даже оно не решает всех реальных проблем (а изредка их только усугубляет).
— unknown (22/07/2008 18:01)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664
Отрицаемость неотрицаемого шифрования неотрицаема!
— unknown (23/07/2008 08:42)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664
Точнее отрицаемость отрицаемого шифрования отрицаема и неотрицаемость отрицаемого шифрования неотрицаема :)
— Гость (02/08/2008 00:48)   <#>
Скрытый /var? Тогда уж проще скрытую ос в виртуальной машине.

Ещё можно вот так попытаться извернуться ради псевдостеганографии: не запускать сервисы при старте системы типа syslogd вообще, а после благополучного старта и подмонтировки всех крипторазделов, запускать нужные системные сервисы юзая конфиги, лежащие на крипторазделе же, и и заставляя данные сервисы писать опять же на криптораздел. Позволяет ли это функционал – ещё не копал, но идея заманчивая. В этом случае для внешних людей диск будет выглядеть так, как будто эти сервисвы специальным образом настроены, что либо не просто пишут опасные логи, либо вообще ничего не пишут :) Аналогичную схему можно и применить для шифрования свопа, и для монтировки разделов (только ручками, после старта, и так, чтобы логов не создавать). Правда, сильный оппонент всё равно после исследования поймёт, что своп реально шифровался каждый раз... но и из этого есть выход: докупить оперативы и вырубить своп вообще, что элегантно решает проблему :))
Ваша оценка документа [показать результаты]
-3-2-1 0+1+2+3