id: Гость   вход   регистрация
текущее время 07:09 20/08/2019
Автор темы: Kent, тема открыта 05/05/2004 21:51 Печать
создать
просмотр
ссылки

TrueCrypt


Наткнулся на новую программу для создания виртуальных зашифрованных дисков и шифрования разделов, TrueCrypt.


Официальный сайт программы:


http://truecrypt.sourceforge.net/
http://sourceforge.net/projects/truecrypt


Краткое описание и скачать (525 кб):
www.truecrypt.tk/


Подробности:
http://groups.google.com/group.....-8&output=gplain


Программа широко обсуждается в новостной группе alt.security.scramdisk


Сам пока не пробовал.


 
На страницу: 1, ... , 3, 4, 5, 6, 7, ... , 35 След.
Комментарии
— SATtva (04/11/2005 13:20)   профиль/связь   <#>
комментариев: 11543   документов: 1036   редакций: 4090
PGP9 – позволяет делать это без потери информации?

Только PGP Desktop 9 Professional, конкретно его функция WDE. Важно только, чтобы процесс зашифрования диска не прервался по какой-то причине — запаситесь шорошим ИБП. ;)

и я в инете яитал что новые PGP (в смысле 8 версии) имеют уже в себе лазейки для большого брата

Это недостоверная информация. Стабильность этих слухов меня поражает. Загляните в FAQ, Общие вопросы, там ситуация описана в общих чертах. А в форуме если постараетесь, сможете найти развёрнутый комментарий.
— Гость (05/11/2005 09:44)   <#>
OK! Спасибо попробую. ;-)
— SATtva (05/11/2005 12:22)   профиль/связь   <#>
комментариев: 11543   документов: 1036   редакций: 4090
Начинаем работу над переводом документации. Всем, кто готов присоединиться:
http://www.pgpru.com/forum/viewtopic.php?p=7009#7009
— Гость (14/11/2005 00:37)   <#>
Ситуация. Пользователь запускает TrueCrypt самым обычным образом (окном), подносит ему свой никому кроме него не известный файл (допустим tc.wav), кликает кнопку Mount, вводит пароль и монтирует свой контейнер. Дальше он работает с виртуальным диском некоторое время, прячет в него свои разные суперсекреты и уходит на перекур, естесственно предварительно размонтировав контейнеркаким-либо способом (Force или не Force, не важно). В итоге – виртуальный диск отключён, в трее болтается в режиме ожидания иконка TrueCrypt.

Уважаемые знатоки, внимание, вопрос. Сколько времени понадобится хитрому шпиёну, чтобы он, обнаружив в системе запущенный процесс TrueCrypt.exe, смог найти и всё остальное – потенциальный контейнер (tc.wav) и пароль к нему?
— SATtva (14/11/2005 09:35)   профиль/связь   <#>
комментариев: 11543   документов: 1036   редакций: 4090
Исходя из того, как поставлен вопрос, ответить на него весьма затруднительно, слишком много остаётся неизвестных. Например, какова ценность хранящейся в контейнере информации и, следовательно, какой может быть степень заинтересованности потенциального взломщика? Насколько сложный (стойкий) пароль использует владелец контейнера для его защиты? Сколько и каких файлов хранится в системе и насколько файл-контейнер "растворяется" в их числе?

Попробую просто дать несколько рекомендаций.

Во-первых, расширение .wav — не лучший способ скрыть контейнер (и вообще, и особенно если он достаточно большой): сколько многомегабайтных .wav-файлов хранится в вашей системе? Кроме того, каждый .wav-файл имеет строго определённую структуру, в частности, первые четыре байта — это всегда RIFF (от Raw Intercharge File Format). Если "хитрый шпиён" просканирует диск на предмет подобных аномалий в форматах и расширениях, он уже сможет предположить, что такой странный файл — криптоконтейнер (хотя он не сможет это доказать, но абсолютно случайные данные, заполняющие файл TC — это повод для подозрений и для дальнейшей работы), или хотя бы сильно сузит область поисков. Лучше не давайте расширение файлу-контейнеру вообще.

Держите опцию Never Save History включенной. В этом случае файл-контейнер не будет попадать в список последних открытых документов Windows, а сам TC не позволит операционной системе изменять метку времени последнего доступа к файлу.

Выбирайте для контейнера не только стойкий пароль, но и используйте ключевые файлы (для TC от 4.0 и выше). Пароль можно перехватить, установив в ваше отсутствие аппаратный или программный кейлоггер. Если же кроме пароля для защиты контейнера использовать и ключевые файлы (например, пара каких-то файлов, хранящихся на диске + ещё один файл на CD или флэшке, которую всегда держите при себе), то без их наличия, но даже имея пароль, открыть контейнер будет невозможно. При этом выявить ключевые файлы, в отличие от файла-контейнера, невозможно, посколько в их качестве могут выступать файлы абсолютно любых структуры и форматов (лучше от 20 Кб до 1 Мб).

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

В конечном счёте, просто оцените свои угрозы и риски.
— Гость (14/11/2005 14:33)   <#>
Вопрошающий, SATtva,
Уже все про это знают :), с помощью [b]Process Explorer[/] by Mark Russinovich, на раскрытие этой информации уйдёт секунда :) :(
— SATtva (14/11/2005 14:40)   профиль/связь   <#>
комментариев: 11543   документов: 1036   редакций: 4090
на раскрытие этой информации уйдёт секунда

Какой "этой"?
— Гость (14/11/2005 15:35)   <#>
Я написал об этом впервые на руборде, пишу и здесь, чтобы запустить волну, потому как оффорум TC не работает, надеюсь, это будет кому-то полезно знать.

Пароль и путь к крипто-контейнеру TC можно открытым текстом прочитать в in-memory storage файла TrueCrypt.exe после того, как контейнер был демонтирован. При этом не имеет знчачение, какой алгоритм, какой контейнер (hidden или не hidden), опция затирать кеш тоже на результат не влияет... Но два важных условия – keyfile не должен использоваться, только пароль, а сам процесс TrueCrypt.exe после монтирования-демонтирования контейнера должен продолжать работать (так по дефолту).

Делаю так:

– запускаю Process Explorer, нахожу процесс TrueCrypt.exe;
– правым кликом на процессе выбираю его Properties и открываю окно;
– выбираю вкладку Strings, отмечаю радиобатон Memory(!!!) и жму Find;
– ввожу текст пароля и вуаля – нахожу в этом in-memory storage свой пароль и дорогу к файлу;

Ниже скрин свойств контейнера и скрин с обнаруженными бяками.




Справедливости ради стоит отметить, что в случае с ключевым файлом, я не смог найти пароль, но дорога к файлу видна, что тоже не есть хорошо, учитывая заявленную Plausible Deniability.

Отмечено на xp sp2 и win2000sp4 postfix.

С уважением,
Zeroglif
— SATtva (14/11/2005 16:18)   профиль/связь   <#>
комментариев: 11543   документов: 1036   редакций: 4090
Zeroglif, Вы не сможете в принципе обеспечить Plausible Deniability (и механизмы ТС не помогут), если оппонент обладает свободным доступом к компьютеру с работающим ТС, может читать память процессов и т.д. Кстати, какой уровень допуска требуется для установки Process Explorer'а?

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

Впрочем, учитывая модель угрозы, я не считаю это риском для безопасности.
— Гость (14/11/2005 18:52)   <#>
SATtva, позволю себе с Вами не согласиться. Само собой, для идеальных условий не страшно ничего, не страшен код, заброшенный внутрь контейнера, не страшен клавиатурный перехват, удалённый монитор и т.д. и т.п. Но мы же трудимся аки пчёлы не в таких условиях, а в сложнопредсказуемых. Потому-то разработчики крипто-софта и стараются по мере сил закрывать некоторые распространённые тропинки к взлому защиты на уровне собственно самого софта. Это относится и к банальным звёздочкам вместо пароля (куда ж без них) и клавиатурным драйверам, как у BestCrypt, и к хоткеям для Force Dismount, и к очистке памяти...

Естесственно, можно без всего этого обойтись и сосредоточиться на главном, но это не то, что не комильфо, это вообще ни в какие ворота не лезет. Зачем мне программа с прекрасным набором алгоритмов, которая не только не защищает мой пароль при вводе, но и хранит его в памяти или на диске?

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

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

Удачи!
— SATtva (14/11/2005 19:11)   профиль/связь   <#>
комментариев: 11543   документов: 1036   редакций: 4090
Зачем мне программа с прекрасным набором алгоритмов, которая не только не защищает мой пароль при вводе, но и хранит его в памяти или на диске?

Любое средство OTFE держит в ОЗУ пароль или мастер-ключ к зашифрованным данным. Это необходимое условие для "прозрачного" шифрования данных.

Вы можете предложить реальный сценарий атаки, который возможен только с применением Process Explorer'а и невозможен в его отсутствие и с учётом существенного условия, что мастер-ключ всегда хранится в памяти программы? И всё-таки ответьте на вопрос, возможно ли установить Process Explorer не под администратором системы?

Это дыра чистой воды и определённый риск для безопасности в обычных (не идеальных) условиях, в которых мы и проживаем

Дыра — это необходимость хранить шифровальные ключи на диске или в памяти общего доступа вместо выделенного и защищённого от взлома криптопроцессора, лежащего на базовом уровне системы (концепция TCB). Вот это и есть неидеальные условия нашего мира.
— Гость (14/11/2005 20:41)   <#>
Любое средство OTFE держит в ОЗУ пароль или мастер-ключ к зашифрованным данным. Это необходимое условие для "прозрачного" шифрования данных

Ну, что Вы такое говорите, пароль OTFE точно не держит, это неприемлемо. К примеру, вот короткий алгоритм на интересующую нас тему от BC:
After you entered password, BC calculates hash from it, and destroy password from its buffers (software does not need to remember it anymore). Then BC reads encrypted key from container file (doesn't matter whether the container is remote or not) and decrypt the key using the hash value. After decrypting BC verifies that the key is suitable for the container, and destroy hash from its buffers (now BC does not need in it). The key is placed to low-level memory of BC driver *locally* on your computer, and uses it for further encrypt/decrypt operations on the local computer.

Как видно, то, что болтается в low-level memory по-большому счёту ценности не представляет...
можете предложить реальный сценарий атаки

Могу. Проблема в том, что пользователь убеждён, что размонтировав контейнер, пароль живёт только в его голове. При этом по умолчанию процесс продолжает жить с открытым паролем внутри. Атаковать можно как физически, заменив пользователя атакующим (насильно или нет), так и удалённо, забросив ему червя, который снимет нужный string и отправит куда надо, да мало ли как. Не нужны инструмены, не нужно время. Всё элементарно. Распространённая программа с хорошей репутацией. Это похоже на клавиатурного шпиона, только лучше, не нужна предварительная подготовка. 5 секунд и готово.
И всё-таки ответьте на вопрос, возможно ли установить Process Explorer не под администратором системы?

"Process Explorer does not require administrative privileges", но даже, если было бы по-другому, 90% домашних машин на пиратских виндах управляются "домашними администраторами"...
— SATtva (14/11/2005 21:49)   профиль/связь   <#>
комментариев: 11543   документов: 1036   редакций: 4090
Ну, что Вы такое говорите, пароль OTFE точно не держит, это неприемлемо. К примеру, вот короткий алгоритм на интересующую нас тему от BC:

Внимание, вопрос: какая разница между паролем, его хэшем и мастер-ключом, если все три суть одно и то же?

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

Спасибо за информацию и конструктивную дискуссию. Пойду писать письмо. :)
— Гость (14/11/2005 22:39)   <#>
Anonymous:

"Process Explorer does not require administrative privileges"

Я думаю это маркетологический бред. Для установки наверное не требует. Или для чтение памяти процессов того же пользователя. windows же как-то это дело ограничивает. И тут truecrypt целиком пологается на систему безопасности ядра.
— SATtva (15/11/2005 04:56)   профиль/связь   <#>
комментариев: 11543   документов: 1036   редакций: 4090
Вот и у меня такие же сомнения. Кто-нибудь может воспроизвести ситуацию, описанную Zeroglifом, но под пользователем с урезанными правами? Я сам в настоящий момент проверить этого, к сожалению, не могу.
На страницу: 1, ... , 3, 4, 5, 6, 7, ... , 35 След.
Ваша оценка документа [показать результаты]
-3-2-1 0+1+2+3