Остается ли в открытом виде информация после truecrip
Я так понимаю, когда монтируется том, инфа находится в открытом виде в оперативке и\или своп-файле и после размонтирования может и далее находится в таком виде? Есть ли возможность избежать этого?
Или возможно есть программы для очистки без возможности востановления информации в свопе и оперативке?
Если сделать диск с операционкой под DCPP и на этом диске сделать том TrueCript, в котором будет хранится важная информация, то по-моему будет не плохой вариант.
комментариев: 232 документов: 17 редакций: 99
комментариев: 9796 документов: 488 редакций: 5664
комментариев: 11558 документов: 1036 редакций: 4118
Какая информация? Шифровальный ключ? У него только биты инвертируются, unknown об этом выше писал. А расшифрованные данные из криптоконтейнера такие программы в оперативке не хранят дольше, чем это делает сама ОС. Короче, после расшифровки (которая обычно выполняется быстро) судьба данных в ОЗУ ничем не отличается от ситуации с доступом к обычным незашифрованным данным на диске. IMHO, Вы переоцениваете степень риска.
Возникает точно такой же вопрос, но в применении к LUKS. Беспокойства добавляет то, что вдруг не только ключ шифрования, но и сама пассфраза хранится в оперативной памяти (есть ли гарантии, что этого не происходит?) — тут ведь даже хрупкий формат хранения ключа не поможет. В случае нескольких LUKS-разделов, где каждый со своей солью, но с одинаковыми пассфразами, такая ситуация вообще критична: несмотря на разные ключи шифрования из оперативной памяти можно извлечь пассфразу и расшифровать другой раздел. В DiskCryptor пароли (не ключи шифрования, а сами пароли!) тоже хранятся в оперативной памяти. Способов же извлечения оперативной памяти последнее время вообще развелась масса: начиная от документированных возможностей firewire или предварительно установленной лишней PCI-платы и кончая методами live forensics — даже морозить ничего не надо (впрочем, ролики с заморозкой и cold boot легко гугляться даже на ютубе). И на вопрос как очистить оперативную память в Linux/UNIX никто не знает ответа :(
Вот как это понимать? Пусть есть раздел с данными, шифрованными LUKS. Данными попользовались, cryptsetup luksCLose сделали. Допустим, ключ шифрования-таки удалился из оперативки, а пассфразы там отродясь не было, но что произошло с самими данными? Они так и продолжают висеть в оперативной памяти? Программы, их использоввашие, равно как и все процессы пользователя, имевшего к ним доступ, будем для определённости считать завершёнными/убитыми. Проблема уже упоминалась, но никакого ответа не последовало.
В довершение всему можно заметить ещё одну крайне странную особенность. После того, как раздел с данными отмонтирован, luksClose сделан, а все лишние процессы убиты, при повторном подключении соответствующего раздела (до перезагрузки, но по прошестии значительного времени — часов, а то и дней) время поиска файлов на разделе (по сравнению с первым разом) сокращается ощутимым образом — ищутся почти моментально! За счёт чего?! Это — абстрактный дисковый кэш, или всё дерево файлов от find так и лежит часами в оперативке после отмонтирования раздела до тех пор, пока случайно не окажется затёртым очередной жирной (требовательной к памяти) программой? Как объяснить это поведение? Даже luksClose ни спасает от очистки данных? Всякие штуки типа locate, если что, отключены. После каждого подмонтирования LUKS-контейнера надо выключать компьютер на некоторое время, вытаскивать батарею для обесточивания оперативной памяти, а потом грузиться снова? Я правильно понимаю?
комментариев: 9796 документов: 488 редакций: 5664
Подтверждаю, тоже сталкивался с таким эффектом. И вероятно вы правы в своём объяснении.
Батарею? Ноут что-ли? Почему она не обесточивается просто при выключении? Ну как максимум достаточно считать, что до выключения данные из закрытых контейнеров могут быть подвержены утечке через память.
Да.
Я не уверен, что shutdown ноубука подразумевает обесточивание планок оперативной памяти — это вопрос к электронщикам. Раз физически напряжение в ноутбуке имеется, трудно что-то гарантировать, не зная как оно работает.
Если проверять скорость чтения в лоб с шифрованных разделов на внешних USB (вытыкать и снова втыкать), то эффекта не наблюдается. Но, может, это только для USB так.
Другая возможная гипотеза: есть дисковый кэш, содержимое секторов последнего доступа кэшируется (как есть, шифрованное). Если какие-то сектора уже в памяти, то они будут расшифрованы быстрее, чем те, что на диске. В случае файловых систем, при применении к ним find'а, ключевое — список файлов в каталогах. Он с успехом может влезть в первые сектора, или куда там.
Подобный эффект наблюдается просто при запуске find без всяких отмонтирований/перемонтирований LUKS (и даже без шифрования, наверное): повторный запуск любой команды find, даже если диск на сотню гигабайт, отрабатывает моментально, хотя первый запуск требует минуты.
Говорят, что в винде при выделении памяти юзерским процессам она предварительно зануляется (иначе всё совсем было бы плохо). В Linux, должно быть, это работает так же, т.е. если кто и имеет доступ к старым данным в оперативке, то только root.
Но, скорей всего, данные действительно фоново зануляются ядром для всех.