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
Сам пока не пробовал.
комментариев: 11558 документов: 1036 редакций: 4118
Только PGP Desktop 9 Professional, конкретно его функция WDE. Важно только, чтобы процесс зашифрования диска не прервался по какой-то причине — запаситесь шорошим ИБП. ;)
Это недостоверная информация. Стабильность этих слухов меня поражает. Загляните в FAQ, Общие вопросы, там ситуация описана в общих чертах. А в форуме если постараетесь, сможете найти развёрнутый комментарий.
комментариев: 11558 документов: 1036 редакций: 4118
http://www.pgpru.com/forum/viewtopic.php?p=7009#7009
Уважаемые знатоки, внимание, вопрос. Сколько времени понадобится хитрому шпиёну, чтобы он, обнаружив в системе запущенный процесс TrueCrypt.exe, смог найти и всё остальное – потенциальный контейнер (tc.wav) и пароль к нему?
комментариев: 11558 документов: 1036 редакций: 4118
Попробую просто дать несколько рекомендаций.
Во-первых, расширение .wav — не лучший способ скрыть контейнер (и вообще, и особенно если он достаточно большой): сколько многомегабайтных .wav-файлов хранится в вашей системе? Кроме того, каждый .wav-файл имеет строго определённую структуру, в частности, первые четыре байта — это всегда RIFF (от Raw Intercharge File Format). Если "хитрый шпиён" просканирует диск на предмет подобных аномалий в форматах и расширениях, он уже сможет предположить, что такой странный файл — криптоконтейнер (хотя он не сможет это доказать, но абсолютно случайные данные, заполняющие файл TC — это повод для подозрений и для дальнейшей работы), или хотя бы сильно сузит область поисков. Лучше не давайте расширение файлу-контейнеру вообще.
Держите опцию Never Save History включенной. В этом случае файл-контейнер не будет попадать в список последних открытых документов Windows, а сам TC не позволит операционной системе изменять метку времени последнего доступа к файлу.
Выбирайте для контейнера не только стойкий пароль, но и используйте ключевые файлы (для TC от 4.0 и выше). Пароль можно перехватить, установив в ваше отсутствие аппаратный или программный кейлоггер. Если же кроме пароля для защиты контейнера использовать и ключевые файлы (например, пара каких-то файлов, хранящихся на диске + ещё один файл на CD или флэшке, которую всегда держите при себе), то без их наличия, но даже имея пароль, открыть контейнер будет невозможно. При этом выявить ключевые файлы, в отличие от файла-контейнера, невозможно, посколько в их качестве могут выступать файлы абсолютно любых структуры и форматов (лучше от 20 Кб до 1 Мб).
Если ситуация предполагает не только скрытные попытки взлома, но и принуждение к выдаче пароля и ключевых файлов, подумайте также об использовании скрытого раздела в контейнере TC для хранения особо ценных данных. Однако, имейте в виду, что если Ваша ситуация допускает доступ к компьютеру посторонних (скажем, в офисе), злоумышленник сможет выявить наличие в контейнере скрытого раздела, получив несколько копий файла с изменениями в скрытом разделе (также ему понадобится доступ к внешнему разделу, т.е. пароль и все ключевые файлы).
В конечном счёте, просто оцените свои угрозы и риски.
Уже все про это знают :), с помощью [b]Process Explorer[/] by Mark Russinovich, на раскрытие этой информации уйдёт секунда :) :(
комментариев: 11558 документов: 1036 редакций: 4118
Какой "этой"?
Пароль и путь к крипто-контейнеру 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
комментариев: 11558 документов: 1036 редакций: 4118
То, что программа не высвобождает память процесса от пароля после отключения контейнера есть плохо. Что касается путей к файлу, то документация честно предупреждает, что пути сохраняются в истории до закрытия ТС. Насчёт пароля тоже нужно предупреждение добавить.
Впрочем, учитывая модель угрозы, я не считаю это риском для безопасности.
Естесственно, можно без всего этого обойтись и сосредоточиться на главном, но это не то, что не комильфо, это вообще ни в какие ворота не лезет. Зачем мне программа с прекрасным набором алгоритмов, которая не только не защищает мой пароль при вводе, но и хранит его в памяти или на диске?
Тем более, что TC сознательно успокаивает своего пользователя, создав режим без кеша для драйвера. То есть, сам разработчик признаёт это важным и делает такую фичу в своём продукте, ошибочно оставив при этом альтернативный вариант.
Это дыра чистой воды и определённый риск для безопасности в обычных (не идеальных) условиях, в которых мы и проживаем...
Удачи!
комментариев: 11558 документов: 1036 редакций: 4118
Любое средство OTFE держит в ОЗУ пароль или мастер-ключ к зашифрованным данным. Это необходимое условие для "прозрачного" шифрования данных.
Вы можете предложить реальный сценарий атаки, который возможен только с применением Process Explorer'а и невозможен в его отсутствие и с учётом существенного условия, что мастер-ключ всегда хранится в памяти программы? И всё-таки ответьте на вопрос, возможно ли установить Process Explorer не под администратором системы?
Дыра — это необходимость хранить шифровальные ключи на диске или в памяти общего доступа вместо выделенного и защищённого от взлома криптопроцессора, лежащего на базовом уровне системы (концепция TCB). Вот это и есть неидеальные условия нашего мира.
Ну, что Вы такое говорите, пароль OTFE точно не держит, это неприемлемо. К примеру, вот короткий алгоритм на интересующую нас тему от BC:
Как видно, то, что болтается в low-level memory по-большому счёту ценности не представляет...
Могу. Проблема в том, что пользователь убеждён, что размонтировав контейнер, пароль живёт только в его голове. При этом по умолчанию процесс продолжает жить с открытым паролем внутри. Атаковать можно как физически, заменив пользователя атакующим (насильно или нет), так и удалённо, забросив ему червя, который снимет нужный string и отправит куда надо, да мало ли как. Не нужны инструмены, не нужно время. Всё элементарно. Распространённая программа с хорошей репутацией. Это похоже на клавиатурного шпиона, только лучше, не нужна предварительная подготовка. 5 секунд и готово.
"Process Explorer does not require administrative privileges", но даже, если было бы по-другому, 90% домашних машин на пиратских виндах управляются "домашними администраторами"...
комментариев: 11558 документов: 1036 редакций: 4118
Внимание, вопрос: какая разница между паролем, его хэшем и мастер-ключом, если все три суть одно и то же?
Впрочем, раз ТС не блокирует память своих процессов на чтение процессов даже со столь низкими привилегиями (если Process Explorer не требует привилегий администратора), это действительно повод указать на сие неблаговидное поведение программы разработчикам.
Спасибо за информацию и конструктивную дискуссию. Пойду писать письмо. :)
Я думаю это маркетологический бред. Для установки наверное не требует. Или для чтение памяти процессов того же пользователя. windows же как-то это дело ограничивает. И тут truecrypt целиком пологается на систему безопасности ядра.
комментариев: 11558 документов: 1036 редакций: 4118