id: Гость   вход   регистрация
текущее время 06:55 25/01/2021
Владелец: ntldr (создано 19/11/2007 23:21), редакция от 12/01/2008 09:02 (автор: ntldr) Печать
Категории: софт, инфобезопасность, защита дисков, truecrypt, исходные тексты, свободный софт
https://www.pgpru.com/Новости/2007/DiskCryptor-OpenSourceПрограммаДляШифрованияДисковыхРазделов
создать
просмотр
редакции
ссылки

19.11 // DiskCryptor - open source программа для шифрования дисковых разделов


DiskCryptor – единственное полностью открытое решение позволяющее шифровать все дисковые разделы включая системный. Программа является заменой проприетарных DriveCrypt Plus pack и PGP WDE. Для шифрования используется алгоритм AES256 в LRW режиме, и формат тома полностью совместим с TrueCrypt, благодаря чему вы можете открыть зашифрованый раздел на Linux с помощью TrueCrypt.

Установка


Программа работает на системах Windows 2000, XP, 2003 Server, XP x64, 2003 Server x64, Vista, Vista x64 (with driver signing disabled). Для установки программы скачайте нужную вам версию дистрибутива по ссылке http://freed0m.org/storage/dcrypt/ и запустите файл dcrypt.exe. Программа предложит установить драйвер и перезагрузиться. Вы можете произвольно менять имя драйвера, что может понадобиться для скрытия факта установки программы. После перезагрузки вы сможете начать работу с программой.

Удаление


Единственным устанавливаемым в систему элементом является драйвер, имя которому вы выбираете непосредственно во время установки. Полностью удалить его вы можете через пункт меню "File->Uninstall Driver", однако если ваш системный раздел зашифрован, то удаление драйвера будет недоступно. При установке новой версии старую удалять не обязательно, т.к. обновление драйвера произойдет автоматически.

Ограничения


Помните, что шифрование системного раздела невозможно при использовании динамических дисков. Также обязательное требование – использование для загрузки ОС только одного раздела. Конфигурации, когда ntldr и boot.ini находятся на одном разделе, а сама система на другом, не поддерживаются.


ВНИМАНИЕ: при шифровании/дешифровании диска нельзя перезагружать компьютер до завершения процесса. Диск должен быть либо полностью зашифрован, либо полностью расшифрован, иначе вы рискуете потерять данные. Рекомендую использовать UPS и делать бекапы перед шифрованием.

Особенности использования


Для удобства использования драйвер кеширует вводимые пароли в памяти ядра, и при монтировании тома выбирает подходящий пароль автоматически. Если подходящий пароль не обнаруживается, то программа выдаст окно ввода пароля. Пароли кешируются в неподкачиваемой памяти и не попадают в page-file. Вы можете очистишь кеш паролей через пункт меню "Tools->Clear Cached Passwords", либо полностью отключить кеширование в настройках программы. Внешние usb-диски, либо иные подключаемые тома, монтируются автоматически. exe файл нужен только для установки и управления программой, и, при постоянном использовании, можно обходиться без него. Зашифруйте все свои диски одним паролем, и тогда вам будет достаточно только лишь раз ввести пароль при загрузке.

Производительность


На Core Quad Q6600 скорость шифрования составляет 104мб/с на одно ядро. Максимальная скорость чтения данных с одиночного жёсткого диска – 80мб/с, следовательно на этом процессоре можно одновременно работать с 5ю жёсткими дисками без падения производительности. В том случае, если диски у вас не всегда используются с полной нагрузкой, можно без падения производительности работать с большим числом дисков и на более слабой системе. Реализация криптоалгоритмов для x86 версии написана на ассемблере и максимально оптимизирована под процессоры Intel Core, но довольно быстро работает и на любых других процессорах. Использованы практически все возможности оптимизации, в частности для алгоритма AES код генерируется динамически, с оптимизацией под конкретный ключ.

Безопасность


В программе используется AES256 с 128 битным блоком в режиме LRW 128. Режим LRW 128 создан специально для шифрования дисков, и защищает от ряда специфичных для этого применения атак. Ключ шифрования формируется случайным образом и хранится в зашифрованном виде в первом секторе тома. Первый сектор зашифрован аналогично всему диску, но его ключ формируется из введенного пароля с помощью sha1-hmac по стандарту pkcs5. Использование salt исключает атаки по rainbow tables, а 1000 итераций хеширования замедляют перебор паролей, добавляя стойкости даже относительно коротким паролям. Ключевым компонентом, определяющим реальную безопасность этой системы, является генератор случайных чисел (PRNG) с помощью которого генерируются ключи. В моей реализации используется PRNG на sha1-хешах с несколькими источниками энтропии. Он построен на основе модифицированного PRNG из TrueCrypt. Модификация сделана для повышения стойкости к атакам на предсказание внутреннего состояния PRNG. В качестве быстрых источников энтропии используется ряд функций ядра, счётчик тактов процессора и системное время. PRNG обновляет своё состояние с помощью этих функций при каждом использовании, а так же в момент ряда системных событий (таких как подключение тома, открытие/закрытие файлов, и. т.д.). В качестве медленного источника энтропии однократно используется PRNG Windows (CryptoAPI), движения мыши в окне программы (постоянно) и системная информация (добавляется периодически). Этого вполне достаточно для исключения возможности предсказания генерируемых ключей, однако в следующих версиях список источников энтропии будет пополнен, для большей гарантии стойкости. Наверняка у вас возникнет вопрос: "Не содержит ли программа бекдор, встроеный автором". Я отвечу – не содержит. Но вы можете мне не верить, и сами проверить и скомпилировать исходники. Я очень рекомендую вам это сделать, после чего отписаться о результатах проверки в гостевой книге и в соответствующих обсуждениях на форумах, ибо, чем больше людей это сделает, тем больше будет доверие к программе.

Риски использования и возможные каналы утечек данных


Я неоднократно слышал о случаях когда спецслужбы ломали различные криптодиски за несколько минут. Обычно такие слухи либо называют выдумкой, либо начинают рассуждать о бекдорах для спецслужб якобы встроеных в шифровальный софт. Бекдоры в проприетарном софте вполне возможны, но зачастую вскрыть зашифрованые данные можно и без них! Виной всему являются утечки конфиденциальных данных в ряд незашифрованых системных файлов. Наиболее опасными файлами в Windows являются реестр, файлы подкачки, crash dump и файл гибернации (hiberfil.sys). В файл подкачки пишеться большая часть памяти пользовательских приложений, в том числе и обрабатываемые ими конфиденциальные данные. DiskCryptor препятствует попаданию ключей и паролей в файл подкачки благоданя хранению их в неподкачиваемой памяти. К тому же пароли и ключи не храняться дольше, чем это нужно для их обработки, после чего занимаемая ими область памяти зануляется. Подобная защита есть во всех адекватных Open-Source криптографических продуктах, но ее не всегда достаточно для сведения риска утечек к нулю. Наиболее опасными являются утечки в hiberfil.sys и в crash дампы, так как при этом на диск сохраняется все содержимое памяти, включая неподкачиваемые области. Положение сильно осложняется тем, что механизм записи дампов и hiberfil.sys полностью недокументирован, и поэтому большинство существующих средств шифрования дисков не могут зашифровать эти файлы и они пишуться в открытом виде на в сектора диска! Последствия этого катострофичны, так как сохранение дампа памяти в открытом виде однозначно приводит к вскрытию всей зашифрованой информации в течении нескольких минут. В общем товарищи из Microsoft подложили нам такую свинью, что и никаких бекдоров в криптософте не надо. Наверняка этой особенностью Windows умеют пользоваться спецслужбы, откуда и пошли соответствующиеся слухи. Наиболее простым решением является отключение дампов и гибернации, о чем кстати сказано в документации к TrueCrypt. Проблема только в том, что большинство пользователей документацию не читают, и получают не безопасность, а только иллюзию таковой. В DiskCryptor начиная с версии 0.2.5 введены меры препятствующие утечкам ключевых данных. Если ваш системный раздел зашифрован, то DiskCryptor будет шифровать дампы и hiberfil.sys. Если не зашифрован, то при наличии подключеных криптодисков вход в гибернацию и запись дампов при крахе системы будут блокироваться, а если подключеных криптодисков нет, то перед входом в гибернацию или записью дампа будет автоматически очищаться кеш паролей в памяти. Таким образом программа препятствует попаданию ключевых данных на диск в открытом виде. Но учтите, что всегда остается вероятность утечки данных по вине стороннего приложения. Например если у вас стоит софт перехватывающий ввод с клавиатуры (это могут быть различные переводчики, программы автоматический смены раскладки клавиатуры, кейлоггеры), либо вы передаете пароли через буффер обмена, то пароли могут быть сохранены в не контролируемом DiskCryptor участке памяти, и попасть во всевозможные места утечки данных, вплоть до сохранения пароля в клавиатурный лог. Чтобы защититься от утечек вызываемых сторонним софтом, вам будет досаточно зашифровать все разделы на которые может идти сохранение подобной информации. Если вы их зашифровали одинаковым паролем, то можете вводить его единократно до загрузки системы. В этом случае пароль защищен от перехвата кейлоггерами и прочим подобным софтом. DiskCryptor дает вам максимально полную автоматическую защиту от основных каналов утечек ключевых данных, однако его использование не отменяет необходимости думать головой.

Компиляция


Для компиляции программы вам понадобится WDK (Windows Driver Kit), VisualStudio 2008 и FASM. Компиляция производится из IDE VisualStudio. Компиляция загрузчика производится отдельно, с помощью FASM.

Отзывы


Отзывы о работе программы оставляйте в гвестбуке. Только пожалуйста помните, что это еще beta версия, а значит мне важны любые ваши отзывы и багрепорты. На всякий случай очень рекомендую делать бекап данных перед шифрованием. Потерь данных при использовании программы пока не выявлено, однако бета тестерам стоит перестраховаться. Автор не несет никакой отвественности за использование или неиспользование вами этой программы. Программа распостраняется как есть, по лицензии GPL v2, без предоставления каких-либо гарантий. Желающие посодейтсвовать развитию проекта могут помочь в написании подробной многоязыковой документации, рисовании иконок для программы, а также пожеланиями по поводу следующих версий.


Источник: http://freed0m.org/?index=dcrypt


 
На страницу: 1, 2, 3, 4, 5, 6, 7, 8 След.
Комментарии [скрыть комментарии/форму]
— unknown (08/02/2008 13:55)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664
fileпро XTS

LRW уязвим к шифрованию ключа самим ключём (шифрование своп-файла) и не может быть использован для шифрования всей системы
— ntldr (08/02/2008 14:32)   профиль/связь   <#>
комментариев: 371   документов: 19   редакций: 20
Планируется ли совместимость DiskCryptor с новым форматом ТС5 (SHA-512, XTS, кстати, не могли бы вы объяснить, в чем ее преимущество по сравнению с LRW)?

LRW содержит ряд незначительных уязвимостей. Поддержка XTS запланирована на версию 0.4, там будет возможность выбора алгоритмов и режимов шифрования. Я считаю LRW более изученым режимом чем XTS, и поэтому дам пользователям возможность выбырать.

Не позаимствовали ли они в новой пятой версии код из DiskCryptor?

Нет, скорее они позаимствовали ряд идей из PGP WDE. Правда о качестве их реализации не буду говорить, чтобы не вызвать очередные плевки в свою сторону.


Возможно ли, теоретически, создание имеющей юридическую силу лицензии запрещающую использовать код в TC но в остальном схожую с GPL?

Не стоит заниматься юридическими заморочками, лучше взять и написать свой аналог работающий быстрее, устроеный проще и распостранять его под GPL.


а в России надо получать на программы для шифрования лицензию у фсб... риторический вопрос – надо ли это ntldr'у?

Насколько я понимаю, получать лицензию у ФСБ надо для законной продажи программы. Я продавать программу не собираюсь.

LRW уязвим к шифрованию ключа самим ключём (шифрование своп-файла) и не может быть использован для шифрования всей системы

Ключи никогда не сбрасываются в своп файл. Это один из важнейших аспектов защиты от утечек ключевых данных. Возможно эта уязвимость может проявиться при использовании режима hibernate, когда в файл сбрасывается все содержимое памяти, но учтите что ключ в ней храниться не в первоначальном виде, а как 32кб таблица для быстрого умножения и 4кб таблица для инкремента, поэтому я считаю что в данном случае эта уязвимость не имеет значения.
Еще возможны гипотетические ситуации со сбросом secondary key в hiberfile в момент смены пароля на раздел. Для защиты от этого в следующей версии будет введено разделение открытого secondary key на две псевдослучайные части. Я хочу оставить возможность безопасного использования режима LRW, так как это весьма быстрый и провереный временем режим.
— Paran0ik (08/02/2008 15:10)   профиль/связь   <#>
комментариев: 88   документов: 13   редакций: 3
Насколько я понимаю, получать лицензию у ФСБ надо для законной продажи программы. Я продавать программу не собираюсь.

я честно во все это не въезжал, но как я понял – разницы нет продавать программу или благотворительностью заниматься, на деятельность, связанную со средствами шифрования должна получаться лицензия...
— ntldr (08/02/2008 15:26)   профиль/связь   <#>
комментариев: 371   документов: 19   редакций: 20
Выдержка из закона https://www.pgpru.com/bibliote.....nsing-crypto-957.txt :
1. Настоящее Положение определяет порядок лицензирования
деятельности по распространению шифровальных (криптографических) средств,
осуществляемой юридическими лицами и индивидуальными предпринимателями.

Я не являюсь юридическим лицом или индивидуальным предпринимателем. Про физические лица в законе ничего не сказано.

Если я не прав, то пожалуйста разьясните мне правовой статус открытых криптографических средств.
— ntldr (09/02/2008 19:13)   профиль/связь   <#>
комментариев: 371   документов: 19   редакций: 20
Хочу добавить в DiskCryptor 0.3 возможность встраивания части пароля в тело загрузчика устанавливаемого на внешний носитель. Это фича предназначена в качестве временной замены ключевых файлов.
Суть идеи такова: пароль которым шифруется раздел может состоять из двух частей, встраиваемой и вводимой. Простейший способ образования одного пароля из двух – это их конкатенация, но максимальная длина пароля допустимая tc форматом равна 64 символам, что будет маловато. Если пользователь встраивает 32х символьный пароль, то он не может вводить пароль длинее 32х символов, а это может стать неудобным ограничением. Этого недостатка лишено обьединение двух 64х символьных паролей в один путем сложения по модулю 2^8, но в этом случае возникнут проблемы в монтировании шифрованого раздела в TrueCrypt, так как пароль в итоге будет содержать непечатные символы и пользователю потребуется делать вычисления для его получения.
Поэтому я хочу спросить: как лучше сделать эту фичу? Может быть кто-нибудь предложит другой вариант?
— SATtva (09/02/2008 19:55)   профиль/связь   <#>
комментариев: 11552   документов: 1036   редакций: 4094
Если одна из половин — истинно случайная последовательной [a-zA-Z0-9], то должно хватить и 64 символов. Можно просто взять пользовательский пароль и дополнить его такой последовательностью до 64 символов (по желанию пользователя показать ему это дополнение, чтобы он мог его записать для использования в ТС). Можно предоставить пользователю выбор: использовать только его пароль, поделённый пополам, или дополнить его случайными знаками.
— ent1 (09/02/2008 19:55)   <#>
Можно встечный вопрос, а почему нужна временная мера замены ключевых файлов? Какие подводные камни будут если на том же внешнем ностителе (например на загрузочном сд) разместить ключевой файл? И путь к файлу указать или или жестко в настройках загрузчика, или выбирать вручную при каждой загрузке (это даже более интересно, на сд можно записать очень много файлов, и использовать комбинацию их 5-6 файлов).
Так можно обеспечить обратную совместимость.

Можно порпобовать после загрузки загрузчика :) предложить вставить второй носитель с ключевым материалом.

ntldr
Удачи Вам, во всех DiskCryptor_ских начинаниях! :)
— ntldr (09/02/2008 22:23)   профиль/связь   <#>
комментариев: 371   документов: 19   редакций: 20

Нужно написать драйвера для чтения файловых систем FAT12/FAT16/FAT32/NTFS и ISO 9660. Это меня не пугает, но я хочу выпустить версию 0.3 как можно быстрее, а пользователи требуют возможность хранить часть ключа на внешнем носителе.
В случае же с CD я слабо представляю процесс его создания. Если я буду создавать загрузочный ISO, то в программе должен быть редактор позволяющий встраивать в него файлы. Можно конечно создавать CD в сторонней програме вроде Nero, но тогда DiskCryptor не будет самодостаточным. Может быть у вас возникнут идеи получше насчет создания CD?

Как альтернативу могу предложить возможность встраивать маленький ключевой файл прямо в тело загрузчика, но это опять оттянет дату релиза версии 0.3. Как вариант можно сделать в версии 0.3 возможность встраивания пароля без возможности его ввода. Это реализуется наиболее просто и не вызовет никаких проблем. Сейчас я склоняюсь к этому варианту.
— ent1 (10/02/2008 01:42)   <#>
ntldr
Про подводные камни понял.

Идею внешнего загрузчика приветствую двумя руками, чтобы в выключеном состоянии (и убраном сд) не было никаких опознавательных признаков чем защищен диск! Как после обработки диска софт-шредером.

Как альтернативу могу предложить возможность встраивать маленький ключевой файл прямо в тело загрузчика, но это опять оттянет дату релиза версии 0.3.

Точно, это выход! Ведь от кейфайлов нужны только первый 1Кб данных.
К томуже, если планируется встраивать часть пароля в тело загрузчика, то все равно прийдется как-то формировать загрузочный iso на этапе шифрования, вот вместо части пароля и записать 1Кб от ключевого файла указанного при зашифровке! Плюс решения, что оно будет оставаться совместимо с tc.

В случае же с CD я слабо представляю процесс его создания.

Думаю сейчас у всех есть пишущие приводы и проги для записи, это ни в коем случае не будет минусом (во всяком случае для меня)!
Можно записывать диск в две сессии – сначала записать загрузчик из iso (сделанного один раз), а затем дописать ключевые файлы второй сессией. Но решение с двумя дисками более гибкое.
Но это на будущее, решение с зашитыми 1кб кейфайла мне очень понравилось.

Как вариант можно сделать в версии 0.3 возможность встраивания пароля без возможности его ввода.

Интересное решение! Можно даже придумать ситуации когда это будет очень кстати, поддерживаю идею! Иногда лучше не знать свой пароль даже самому!
— Гость (10/02/2008 02:16)   <#>
Идею внешнего загрузчика приветствую двумя руками, чтобы в выключеном состоянии (и убраном сд) не было никаких опознавательных признаков чем защищен диск! Как после обработки диска софт-шредером

Уже сейчас можно загружать с CD/флешки, например BartPE, и из него помощью bootfix переписывать загрузочный блок на харде, потом загружать шифрованную ОС и из неё переписывать загрузочный блок обратно к исходному виду.
— ntldr (10/02/2008 02:21)   профиль/связь   <#>
комментариев: 371   документов: 19   редакций: 20
Уже сейчас можно загружать с CD/флешки, например BartPE, и из него помощью bootfix переписывать загрузочный блок на харде, потом загружать шифрованную ОС и из неё переписывать загрузочный блок обратно к исходному виду.

Это уже из области извращений.

В общем в версии 0.3 будет возможность встраивать пароль целиком. В следующих версиях я сделаю полноценную поддержку кейфайлов.
— ent1 (10/02/2008 02:48)   <#>
Уже сейчас можно загружать с CD/флешки, например BartPE, и из него помощью bootfix переписывать загрузочный блок на харде, потом загружать шифрованную ОС и из неё переписывать загрузочный блок обратно к исходному виду.

Это из серии админских решений (digger электронщику – и нет проблем)! ;) Но не каждый будет заниматься таким головняком.
— Гость (10/02/2008 05:19)   <#>
файл bootmbr.bin однозначно опознается каспером как вирус.
— ntldr (10/02/2008 05:41)   профиль/связь   <#>
комментариев: 371   документов: 19   редакций: 20
Эти пи...асы добавили код загрузчика в базу как boot rootkit. Советую удалить антивирус касперского и больше никогда не устанавливать эту гадость, поскольку вирусы ловить он не умеет, зато пополняет свои базы сигнатурами нормальных программ.
— Проходил_Мимо (10/02/2008 11:34)   <#>
> Цитирую часть пришедшего мне письма
Вот теперь приношу свои извинения за резкое высказывание в ваш адрес.
Просто ранее вы не цитировали этого письма и не говорили, что вам предъявили прямые претензии на счет использования GPL вместо их лицензии. Соответственно, выглядело оно как не слишком обоснованная обида на удаленную тему на их форуме и требование сменить название.

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

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

В любом случае, удачи вам с программой. Лично мне она бесполезна, по причине жесткой привязке к Windows, но вообще, начинание хорошее. А если будет порт на юниксы, обязательно взгляну на нее поближе.
На страницу: 1, 2, 3, 4, 5, 6, 7, 8 След.
Ваша оценка документа [показать результаты]
-3-2-1 0+1+2+3