id: Гость   вход   регистрация
текущее время 00:13 08/02/2023
Автор темы: Гость, тема открыта 30/05/2007 14:42 Печать
https://www.pgpru.com/Форум/ПрактическаяБезопасность/ШифрованиеНеразмечЕнногоДисковогоПространства
создать
просмотр
ссылки

шифрование неразмеченного дискового пространства


Подскажите пожалуйста, какая программа может зашифровать, а потом расшифровать свободное ( неразмеченное ) дисковое пространство на винчестере?


 
На страницу: 1, 2, 3 След.
Комментарии
— SATtva (30/05/2007 20:57)   профиль/связь   <#>
комментариев: 11558   документов: 1036   редакций: 4116
Где-то (здесь?) у нас высказывалось предложение по выполнению такого трюка с помощью TrueCrypt. Деталей, к сожалению, не помню. Поищите сами или ждите, чтобы кто-нибудь напомнил, в какой теме это обсуждалось.
— ent (03/06/2007 02:17)   <#>
С помощью TrueCrypt 4.3 можно такое сделать, если есть отдельный (не системный) полностью пустой диск (без mbr, без разделов) – только что так отформатировал флэшку.

Еще можно сделать сделать скрытый контейнер на обычном fat32 разделе – те система будет видеть партицию как обычный раздел (там могут быть какие-то файлы и с ними можно работать как обычно), а при монтировании раздела в TrueCrypt будет открываться доступ к скрытому разделу. При этом явных следов скрытого контейнера в разделе не будет – обычный раздел с файлами и все.
Делается так:
1. создается на диске раздел нужного размера, не форматируется
2. в TrueCrypt создается обычный зашифрованый раздел с fat32
3. в обычном зашифрованом разделе создается скрытый раздел, на 20-30% меньшего объема, можно fat32, можно NTFS
4. теперь из под виндового менеджера дисков форматируем весь раздел в fat32 обязательно использую БЫСТРОЕ форматирование!
5. получаем раздел, который система видит как обычный раздел, на который можно записать в начало файлы (15-25%, чтобы с запасом).

ИМХО этот вариант имеет определенные плюсы, тк наличие в системе неразмеченного раздела или диска вызывет ненужные подозрения даже у простого человека.
— ent (03/06/2007 02:28)   <#>
PS этот метод придумал не я, оригинал смотреть здесь https://www.pgpru.com/Comment11193
— spinore (03/06/2007 10:36)   профиль/связь   <#>
комментариев: 1515   документов: 44   редакций: 5786
Я не знаю как там во всяких виндах (это другая такая ОС что ли?) но обычно программа
не может лезть в обход ОС по самой конструкции последней, по самой идеологии.
Чтобы ОС обратилась к какому-то месту на диске, это место на диске должно принадлежать
ОС, то есть должно быть помечечно как таковое с точки зрения самой ОС – обычно это
реализуется посредством прописывания заголовка в разделе диска где должна быть указана
как минимум геометрия раздела (а пожеланию можно ещё указать какой ОС принадлежит и какая
ФС там если имеется таковая). Основная проблема состоит в том, что эту информацию
о геометрии нельзя загрузить сразу в память ядра в BSD не записывая её предварительно на
диск в указанное место. Скорей всего, такое же положение дел и с линуксом и с "виндой"(?).
В данном случае проблема сводится не к принципиальной невозможности а ктому что пока
не реализовали этот функционал. С другой стороны, если оппонент не дурак, он всегда
может произвести экспертизу свободного дискового пространства и заявить что с такой-то
(довольно большой) вероятностью данное место на диске есть криптораздел или криптотом.
Если речь идёт о мизерных объёмах то можно списать на то что там был записан фильм,
но если никаких стандартных сигнатур диска не найдётся на разделе в 40 гигабайт, то
говорить уже будет не о чем. Умные люди потому изобрели стратегию трукрипт с "двойным дном",
но, как подсказывает мне интуиция, получи широкое распространение эта технология –
проблема останется той же – нет стегоОС, стегоОС in mind. А пока само наличие трукрипта
на диске может быть легко расценено как средство использования его двойного дна.
Я здесь не касаюсь правового поля (налчие шифрованной информации само по себе не является
обвинением, но может поспособствовать подозрениям суда). Итак, чтобы решать проблему
основательно нужно создавать стегоОС, которая будет комплексно стегонаграфической
во всех смыслах: распространена, её налчиие не вызывает подозрений, по умолчанию
логи, которые потенциально могли бы в некоторых случаях дискредитировать
анонимность не пишутся и т. п. А поскольку большинство не понимает зачем вообще
что-либо шифровать, то огромной птребности в стегоОС нет. Для тех же, кому она
нужна, единственный способ жить есть изобретать костыли под вид "шифровать свободное
место на диске" или что-то в этом роде.
— unknown (03/06/2007 16:24)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664

Чтобы ОС обратилась к какому-то месту на диске, это место на диске должно принадлежать
ОС, то есть должно быть помечечно как таковое с точки зрения самой ОС – обычно это
реализуется посредством прописывания заголовка в разделе диска где должна быть указана


Разве нельзя обращаться к блочному стройству, как к raw-data с параметром offset?
— spinore (03/06/2007 19:14)   профиль/связь   <#>
комментариев: 1515   документов: 44   редакций: 5786


Когда то с гуру обсуждал этот вопрос и сошлись на том что нельзя. Задача состояла в использовании ФС на свободном месте на диске. Её там можно каким-то раком нарезать и использовать? Не трогая disklabel, имеется в виду.
— unknown (03/06/2007 21:32)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664
ЭЭЭ? Да это стандартная возможность losetup. Там только криво реализовано, больше 4 гигов оффсет не делает.
— ent (04/06/2007 00:25)   <#>
spinore
Не понял о какой геометрии идет речь. Из ОС можно обратиться к любому произвольному сектору диска (физическому сектору), и не имеет значения размечен диск на разделы или нет, отформатированы разделы или нет. Не вижу в этом ничего особенного.

Её там можно каким-то раком нарезать и использовать? Не трогая disklabel, имеется в виду.

Здесь https://www.pgpru.com/Comment11193 по сути получается обратный порядок действия – сначала создаем криптоконтейнер на разделе с некоторым смещением от начала, а потом прописываем разделу заголовок так, чтобы он был виден как отформатированный в fat32.
И почему бы этому не быть? Или я не улових ход мысли?
— spinore (04/06/2007 04:37)   профиль/связь   <#>
комментариев: 1515   документов: 44   редакций: 5786
ent, вохможно вы правы. Я в этом не специалист и мне пока надо обсудить этот
топик с тем кто утверждал обратное – не более того.
— Гость (01/06/2010 07:05)   <#>
(налчие шифрованной информации само по себе не является обвинением, но может поспособствовать подозрениям суда). Итак, чтобы решать проблему основательно нужно создавать стегоОС, которая будет комплексно стегонаграфической во всех смыслах: распространена, её налчиие не вызывает подозрений
Поглядел "сабж" в user-friendly-дистрах Linux. В Ubuntu умолчальный инсталляционный диск не позволяет включить шифрование диска, и даже не упоминает про такую возможность. Чтобы включить шифрование во время инсталла, нужно воспользоваться диском для "альтернативно одарённых" (alternate install CD), про существование которого знают только те, кто итак уже в теме. Т.о., типичному пользователю даже такой альтернативы не предложат (да и многие ли вчерашние пользователи win знают, что можно шифровать диск целиком, а не пофайлово?). В Linux MINT всё ещё лучше: шифрование при инсталляции включить вообще нельзя. На форумах предлагают установить убунту с альтернативного CD, а потом отMINTить её. Ужас. А так, если подумать, сколько пользователей Ubuntu по всему миру... Если б было шифрование дефолтом, меньше бы выделялись те, кто "мануально шифрует". На десктопе нет критичности с скорости работы с диском как на файлопомойке – почему бы не включить шифрование диска паролем администратора по дефолту? Если от фичи нет вреда, а лишь польза... Заговор? Или недальновидность девов? В качестве аргументации пишут "среднему пользователю это не нужно, потому и нет такой фичи" – действительно, зачем среднему пользователю защищаться и замок на двери вешать :-( Сайты с авторизацией без https, видимо, аргументируются аналогично.
— unknown (01/06/2010 09:45, исправлен 01/06/2010 09:49)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664

[Ubuntoсрач] А что еще можно ожидать от Шатлворта, который единолично занят утверждением перестановок кнопок в Убунтогноме на левую сторону, переманиванием пользователей с MacOS и прочими "вау!-фичами"?


А шифрование и безопасность: сделаешь хорошо — рядовые пользователи не заметят, сделаешь плохо — эксперты по безопасности расковыряют, это пройдёт горячей новостью, смысл которой рядовые пользователи хотя и не поймут, но негативное мнение сформируют. Неблагодарная будет работа.


Интересно, там хотя бы gpg-подписи пакетов при инсталле проверяются или "среднему пользователю это не нужно"?
[/Ubuntoсрач]

— Гость (01/06/2010 11:32)   <#>
На десктопе нет критичности с скорости работы с диском как на файлопомойке – почему бы не включить шифрование диска паролем администратора по дефолту?

Может быть потому, что разработчики не хотят удовлетворять потребности меньшинства ценой значительного ухудшения для большинства? Даже на очень мощном десктопе бенчмарки видят разницу между незашифрованными и зашифрованными дисками, а на каких-нибудь нетбуках эта разница может достигать 4-5 раз. Для большинства, которому не нужно шифрование, это принесет кучу геморроя с потерями данных после забывания пароля, это вызовет несовместимость с другими линуксами и виндой, это вызовет катастрофическое замедление работы на нетбуках и резкое уменьшение времени автономной работы ноутбуков, это вызовет проблемы при смене пароля (я сменил пароль, старый забыл, потом достал с полки диск который юзал год назад и обнаружил сюрприз...). Причин достаточно или продолжать?
Если разработчики будут включать полное дисковое шифрование по-умолчанию, то пользователи их без соли съедят, и будут правы.
— unknown (01/06/2010 11:54, исправлен 01/06/2010 12:21)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664
Даже на очень мощном десктопе бенчмарки видят разницу между незашифрованными и зашифрованными дисками, а на каких-нибудь нетбуках эта разница может достигать 4-5 раз.

это вызовет катастрофическое замедление работы на нетбуках и резкое уменьшение времени автономной работы ноутбуков

На многоядерниках — десятые доли процента нагрузки на одно ядро процессора (и это даже без аппаратной поддержки AES в новых процах), скорость работы с диском соответственно тоже практически не меняется. Судя по экспериментам с полным шифрованием ещё на старых 300 MHz компах (где-то 20% проца) не может быть в 4-5 раз.


несовместимость с другими линуксами и виндой

CryptoAPI находятся в дефолтном ядре Linux. Уже давно. Набор утилит для работы с ними также. С версиями cryptsetup-LUKS/CryptoAPI теоретически могут быть проблемы совместимости, если кто-то вручную залезет в самые продвинутые опции и выберет самый последний недефолтный режим шифрования.


Чтение разделов Lin из Win? Можно завести отдельный раздел для перекидывания данных, а вообще такая совместимость нужна?


И вообще о какой совместимости речь? Зачем другим Linuxам физически подцепляться к винчестеру? Если надо восстановить шифрованные данные, то можно взять LiveCD с последними версиями CryptoAPI и утилит. Расшаривают и передают файлы на другие системы по сетевым протоколам, на которые дисковое шифрование никак не влияет. Флэшки и съёмные накопители — хотите шифруйте, хотите нет.


Про проблемы с обращением с шифрованием вообще и пофигизмом пользователей понятно, поэтому:


Если разработчики будут включать полное дисковое шифрование по-умолчанию

Только предложение выбора такого шифрования при инсталляции, как в других дистрибутивах, не более.

— sentaus (01/06/2010 12:57)   профиль/связь   <#>
комментариев: 1060   документов: 16   редакций: 32
Интересно, там хотя бы gpg-подписи пакетов при инсталле проверяются или "среднему пользователю это не нужно"?


Точно срач :)

тут же совсем недавно была тема с гневным сообщением от пользователя, у которого проверка подписи провалилась
— unknown (01/06/2010 13:11)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664
Вообще да, apt у них общий :) Им бы пришлось специально выпиливать эту возможность. Про подписи конечно совсем не в тему.
На страницу: 1, 2, 3 След.
Ваша оценка документа [показать результаты]
-3-2-1 0+1+2+3