id: Гость   вход   регистрация
текущее время 15:25 27/10/2020
Автор темы: Гость, тема открыта 22/05/2007 23:41 Печать
https://www.pgpru.com/Форум/ПрактическаяБезопасность/ОстаетсяЛиВОткрытомВидеИнформацияПослеTruecrip
создать
просмотр
ссылки

Остается ли в открытом виде информация после truecrip


Я так понимаю, когда монтируется том, инфа находится в открытом виде в оперативке и\или своп-файле и после размонтирования может и далее находится в таком виде? Есть ли возможность избежать этого?
Или возможно есть программы для очистки без возможности востановления информации в свопе и оперативке?


 
На страницу: 1, 2 След.
Комментарии
— Гость (24/05/2007 11:53)   <#>
Вроде в последних версиях DCPP в оперативной памяти информация находится в зашифрованом виде, т.е. даже при аварийном выключении питания информация в оперативной памяти находится в зашифрованом виде.
Если сделать диск с операционкой под DCPP и на этом диске сделать том TrueCript, в котором будет хранится важная информация, то по-моему будет не плохой вариант.
— serzh (24/05/2007 15:09)   профиль/связь   <#>
комментариев: 232   документов: 17   редакций: 99
Читал – читал и не смог удержаться. Начните писать TrueCrypt, а то кажется вы говорите о незнакомой мне программе =)
— unknown (24/05/2007 16:01)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664
Да, слегка отклонились от темы. Кто про Drive Crypt Pack с плюсом, кто про криостат с глубоким минусом. =)
— SATtva (24/05/2007 19:05)   профиль/связь   <#>
комментариев: 11552   документов: 1036   редакций: 4094
Вроде в последних версиях DCPP в оперативной памяти информация находится в зашифрованом виде, т.е. даже при аварийном выключении питания информация в оперативной памяти находится в зашифрованом виде.

Какая информация? Шифровальный ключ? У него только биты инвертируются, unknown об этом выше писал. А расшифрованные данные из криптоконтейнера такие программы в оперативке не хранят дольше, чем это делает сама ОС. Короче, после расшифровки (которая обычно выполняется быстро) судьба данных в ОЗУ ничем не отличается от ситуации с доступом к обычным незашифрованным данным на диске. IMHO, Вы переоцениваете степень риска.
— Гость (05/03/2012 11:02)   <#>
когда монтируется том, инфа находится в открытом виде в оперативке и\или своп-файле и после размонтирования может и далее находится в таком виде? Есть ли возможность избежать этого? Или возможно есть программы для очистки без возможности востановления информации в свопе и оперативке?

Возникает точно такой же вопрос, но в применении к LUKS. Беспокойства добавляет то, что вдруг не только ключ шифрования, но и сама пассфраза хранится в оперативной памяти (есть ли гарантии, что этого не происходит?) — тут ведь даже хрупкий формат хранения ключа не поможет. В случае нескольких LUKS-разделов, где каждый со своей солью, но с одинаковыми пассфразами, такая ситуация вообще критична: несмотря на разные ключи шифрования из оперативной памяти можно извлечь пассфразу и расшифровать другой раздел. В DiskCryptor пароли (не ключи шифрования, а сами пароли!) тоже хранятся в оперативной памяти. Способов же извлечения оперативной памяти последнее время вообще развелась масса: начиная от документированных возможностей firewire или предварительно установленной лишней PCI-платы и кончая методами live forensics — даже морозить ничего не надо (впрочем, ролики с заморозкой и cold boot легко гугляться даже на ютубе). И на вопрос как очистить оперативную память в Linux/UNIX никто не знает ответа :(

Короче, после расшифровки (которая обычно выполняется быстро) судьба данных в ОЗУ ничем не отличается от ситуации с доступом к обычным незашифрованным данным на диске.

Вот как это понимать? Пусть есть раздел с данными, шифрованными LUKS. Данными попользовались, cryptsetup luksCLose сделали. Допустим, ключ шифрования-таки удалился из оперативки, а пассфразы там отродясь не было, но что произошло с самими данными? Они так и продолжают висеть в оперативной памяти? Программы, их использоввашие, равно как и все процессы пользователя, имевшего к ним доступ, будем для определённости считать завершёнными/убитыми. Проблема уже упоминалась, но никакого ответа не последовало.

В довершение всему можно заметить ещё одну крайне странную особенность. После того, как раздел с данными отмонтирован, luksClose сделан, а все лишние процессы убиты, при повторном подключении соответствующего раздела (до перезагрузки, но по прошестии значительного времени — часов, а то и дней) время поиска файлов на разделе (по сравнению с первым разом) сокращается ощутимым образом — ищутся почти моментально! За счёт чего?! Это — абстрактный дисковый кэш, или всё дерево файлов от find так и лежит часами в оперативке после отмонтирования раздела до тех пор, пока случайно не окажется затёртым очередной жирной (требовательной к памяти) программой? Как объяснить это поведение? Даже luksClose ни спасает от очистки данных? Всякие штуки типа locate, если что, отключены. После каждого подмонтирования LUKS-контейнера надо выключать компьютер на некоторое время, вытаскивать батарею для обесточивания оперативной памяти, а потом грузиться снова? Я правильно понимаю?
— Гость (05/03/2012 11:41)   <#>
Кстати, вопрос уже поднимался в /comment49120.
— unknown (05/03/2012 11:52)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664
В рассылке dm-crypt этот вопрос обсуждался. Убеждали, что luksClose достаточно по крайней мере для ключа. Про данные в памяти не помню.
при повторном подключении соответствующего раздела (до перезагрузки, но по прошестии значительного времени — часов, а то и дней) время поиска файлов на разделе (по сравнению с первым разом) сокращается ощутимым образом — ищутся почти моментально!

Подтверждаю, тоже сталкивался с таким эффектом. И вероятно вы правы в своём объяснении.
После каждого подмонтирования LUKS-контейнера надо выключать компьютер на некоторое время, вытаскивать батарею для обесточивания оперативной памяти, а потом грузиться снова? Я правильно понимаю?

Батарею? Ноут что-ли? Почему она не обесточивается просто при выключении? Ну как максимум достаточно считать, что до выключения данные из закрытых контейнеров могут быть подвержены утечке через память.
— Гость (05/03/2012 13:06)   <#>

Да.


Я не уверен, что shutdown ноубука подразумевает обесточивание планок оперативной памяти — это вопрос к электронщикам. Раз физически напряжение в ноутбуке имеется, трудно что-то гарантировать, не зная как оно работает.
— Гость (14/03/2012 04:50)   <#>
Подтверждаю, тоже сталкивался с таким эффектом. И вероятно вы правы в своём объяснении.

Если проверять скорость чтения в лоб с шифрованных разделов на внешних USB (вытыкать и снова втыкать), то эффекта не наблюдается. Но, может, это только для USB так.

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

Подобный эффект наблюдается просто при запуске find без всяких отмонтирований/перемонтирований LUKS (и даже без шифрования, наверное): повторный запуск любой команды find, даже если диск на сотню гигабайт, отрабатывает моментально, хотя первый запуск требует минуты.
— Гость (05/03/2014 13:00)   <#>
Убеждали, что luksClose достаточно по крайней мере для ключа. Про данные в памяти не помню.

Говорят, что в винде при выделении памяти юзерским процессам она предварительно зануляется (иначе всё совсем было бы плохо). В Linux, должно быть, это работает так же, т.е. если кто и имеет доступ к старым данным в оперативке, то только root.

Но, скорей всего, данные действительно фоново зануляются ядром для всех.
На страницу: 1, 2 След.
Ваша оценка документа [показать результаты]
-3-2-1 0+1+2+3