Остается ли в открытом виде информация после truecrip
Я так понимаю, когда монтируется том, инфа находится в открытом виде в оперативке и\или своп-файле и после размонтирования может и далее находится в таком виде? Есть ли возможность избежать этого?
Или возможно есть программы для очистки без возможности востановления информации в свопе и оперативке?
Ссылки
[link1] https://www.pgpru.com/chernowiki/rukovodstva/bezopasnostj/zaschitadiskov/truecrypt/tctemp
[link2] http://www.macfergus.com/pub/forget.html
[link3] https://www.pgpru.com/novosti/2008/javnyeparolivoperativnojjpamjatipovsemestny
[link4] https://www.pgpru.com/comment47107
[link5] https://www.pgpru.com/comment49152
[link6] https://www.pgpru.com/comment46379
[link7] https://www.pgpru.com/comment46386
[link8] https://www.pgpru.com/comment46749
[link9] https://www.pgpru.com/comment46755
[link10] https://www.pgpru.com/comment49181
[link11] https://www.pgpru.com/comment49120
В оперативке оказываются только те данные, к которым происходит обращение в крипторазделе. Выгрузка в своп производится по общим правилам. Лучше, по-моему, не искать способы безопасной очистки свопа, а просто его шифровать[link1].
Вспомнилось с какого-то треда на этом сайте:
"а особенно сильный оппонент, когда приходит, быстро выдёргивает оперативку и в азот её...
Потом в лаборатории типа прочитают..." :-)))
И не в азот, а в криостат с азотом. Хотя азот тоже много где используется. В отключении сигнализаций и детекторов вторжения например.
С точки зрения современной практической криптографии, оперативная память обычных компьютеров считается нестираемой или частично стираемой. В старых персоналках из-за этого даже были проблемы с загрузкой – данные иногда частично оставались в памяти после выключения.
Для того чтобы безопасно хранить в ней ключи (не в открытом виде) используются специальные протоколы[link2]
Я так поннимаю TCTEMP не шифрует оперативку, а только создает криптоконтейнер для различных временных файлов?
Есть ли какие-либо программы именно для шифрования оперативки? При большом объеме оперативной памяти потребность в свопе практичесски отпадает.
Да — сейф, в который Вы суёте весь компьютер. Вы как себе представляете шифрование оперативки? Где тогда компьютер будет размещать обрабатываемые данные (открытый текст и шифртекст)? В другой оперативке? Получаем бесконечную рекурсию.
В классической машине Тьюринга (на концепции которой построены все современные ПК) открытый текст всегда должен где-то храниться, в постоянной ли памяти (на диске) или во временной (ОЗУ, кэши). Возможно, есть какие-то другие модели вычислительных машин, где такой проблемы не существует, но только мне о них неизвестно.
В классической машине Тьюринга достаточно в каждый момент иметь открытыми две ячейки :)
В случае реального компьютера подобные подходы используются в некоторых антихакерских защитах.
Несложно написать, к примеру, текстовый редактор, в котором в расшифрованном виде в памяти храниться только та текстовая информация, что присутствует на экране.
Примерно такого эффекто можно добиться оставив очень мало оперативной памяти, а выделяемую процессором виртуальную память на диске шифровать.
Вопрос тут в том, что произойдёт быстрее – уничтожение ключа шифрования или помещение оперативной памяти в криостат. (итнересно, есть ли память, разрушающаяся от холода?:)
На RAM-диске!
Именно этот подход используется в работе, приведённой выше.
Остаётся только вопрос, а как хранить в памяти сам ключ шифрования – там и на это дан ответ. Для этого используются протоколы, позволяющие или хранить ключ распределённо (такой подход используется для хранения мастер-ключа в LUKS – Linux Unified Key Setup) или разделив его на две части и периодически инвертируя биты между ними (такой подход – "key scrubbing" используется уже непосредственно при хранении ключа в памяти в loop-aes)
Главное ослабить эффект запоминания битов, поэтому достаточно делать key scrubbing – регулярно инвертировать биты ключа. Всё-таки этот эффект достаточно слаб, поэтому можно ожидать только восстановления данных, которые долгое время находились в неизменном виде в одном и том же физическом участке.
Наименее подвержены этому эффекту микросхемы памяти, которые уже очень долго использовались. А тем кому реально угрожают криостатом лучше построить завод по производству микросхем со сниженным эффектом запоминания.
Улыбнуло :)
Интересно, носколько подвержена эффекту памяти (каламбурчик) память внутри проца – кеш L1 и L2?
Или например такой вариант: допустим в памяти долгое время хранилась какая-то инфа, потом весь объем был заполнен случайными данными (один или несколько раз) на 1-2-5 мин, и уже потом эта память помещена к риостат. Можно ли будет восстановить те данные, которые были в памяти продолжительное время? Хватит ли такой процедуры, чтобы гарантировать очистку памяти?
Это я к чему, для снижение "реальной угрозы криостатом" :) можно изолировать комп, ups в сейфе. При любом проникновении в помещение (ибо к ТАКИМ компам подходить простым смертным нефиг :)), работа
приложений сворачивается, комп перезагружается, и запускается memtest (с CD) с паттерном random. Сейф за 5 мин не откроют, ups будет питать в случае отключения питания, так что память успеет несколько раз переписаться.
Вообще тема интересная – Шифрование оперативной памяти!
Абсолютно надёжной защитой от любых существующих и вымышленных лабораторий будет установка термитов на винчестеры и оперативную память, которые в экстренном случае сожгут до тла и расплавят всё что надо.
Что такое термиты?
http://anonym.to/?http://en.wikipedia.org/wiki/Thermite
http://anonym.to/?http://pirotehnix.org.ua/termit.html
Кстати, у приведённого выше метода есть ещё достоинства – выпытывать пароль не будут (уже неплохо, не правда ли), хардварного подборщика паролей, распределённых сетей и (чем чёрт не шутит) квантового компьютера можно не бояться. Немаловажна также дешевизна и крайняя сердитость (граничащая с брутальностью). Конечно, понадобится решить инженерную задачку, связанную с химией и электроникой, но зато какой бенефит.
Будут выпытывать: где хранишь резервные копии! Всё равно не верим, что их нет!
Ещё раз: реально вроде бы только извлечение данных, которые подолгу висят в одном и том же месте памяти (ключ шифрования в открытом виде). А если их периодически менять, то это маловероятно.
А резервные копии сгорят когда откроют сейф с ними, не отключив одну из секреток.
А может вы их на удалённом серваке храните?
Хранили, но поскольку код подтверждения из камеры СИЗО отправить было нельзя, они тоже сгорели. Думаю, надо свёртывать оффтоп, и вернуться к обсуждению технических изысков.
Вроде в последних версиях DCPP в оперативной памяти информация находится в зашифрованом виде, т.е. даже при аварийном выключении питания информация в оперативной памяти находится в зашифрованом виде.
Если сделать диск с операционкой под DCPP и на этом диске сделать том TrueCript, в котором будет хранится важная информация, то по-моему будет не плохой вариант.
Читал – читал и не смог удержаться. Начните писать TrueCrypt, а то кажется вы говорите о незнакомой мне программе =)
Да, слегка отклонились от темы. Кто про Drive Crypt Pack с плюсом, кто про криостат с глубоким минусом. =)
Какая информация? Шифровальный ключ? У него только биты инвертируются, unknown об этом выше писал. А расшифрованные данные из криптоконтейнера такие программы в оперативке не хранят дольше, чем это делает сама ОС. Короче, после расшифровки (которая обычно выполняется быстро) судьба данных в ОЗУ ничем не отличается от ситуации с доступом к обычным незашифрованным данным на диске. IMHO, Вы переоцениваете степень риска.
Возникает точно такой же вопрос, но в применении к LUKS. Беспокойства добавляет то, что вдруг не только ключ шифрования, но и сама пассфраза[link3] хранится в оперативной памяти (есть ли гарантии, что этого не происходит?) — тут ведь даже хрупкий[link4] формат хранения ключа не поможет. В случае нескольких LUKS-разделов, где каждый со своей солью, но с одинаковыми пассфразами, такая ситуация вообще критична: несмотря на разные ключи шифрования из оперативной памяти можно извлечь пассфразу и расшифровать другой раздел. В DiskCryptor пароли (не ключи шифрования, а сами пароли!) тоже хранятся[link5] в оперативной памяти. Способов же извлечения оперативной памяти последнее время вообще развелась масса: начиная от документированных возможностей[link6] firewire или предварительно установленной лишней PCI-платы[link7] и кончая методами live forensics[link8] — даже морозить ничего не надо (впрочем, ролики с заморозкой и cold boot легко гугляться даже на ютубе). И на вопрос как очистить оперативную память в Linux/UNIX никто не знает[link9] ответа :(
Вот как это понимать? Пусть есть раздел с данными, шифрованными LUKS. Данными попользовались, cryptsetup luksCLose сделали. Допустим, ключ шифрования-таки удалился из оперативки, а пассфразы там отродясь не было, но что произошло с самими данными? Они так и продолжают висеть в оперативной памяти? Программы, их использоввашие, равно как и все процессы пользователя, имевшего к ним доступ, будем для определённости считать завершёнными/убитыми. Проблема уже упоминалась[link10], но никакого ответа не последовало.
В довершение всему можно заметить ещё одну крайне странную особенность. После того, как раздел с данными отмонтирован, luksClose сделан, а все лишние процессы убиты, при повторном подключении соответствующего раздела (до перезагрузки, но по прошестии значительного времени — часов, а то и дней) время поиска файлов на разделе (по сравнению с первым разом) сокращается ощутимым образом — ищутся почти моментально! За счёт чего?! Это — абстрактный дисковый кэш, или всё дерево файлов от find так и лежит часами в оперативке после отмонтирования раздела до тех пор, пока случайно не окажется затёртым очередной жирной (требовательной к памяти) программой? Как объяснить это поведение? Даже luksClose ни спасает от очистки данных? Всякие штуки типа locate, если что, отключены. После каждого подмонтирования LUKS-контейнера надо выключать компьютер на некоторое время, вытаскивать батарею для обесточивания оперативной памяти, а потом грузиться снова? Я правильно понимаю?
Кстати, вопрос уже поднимался в /comment49120[link11].
В рассылке dm-crypt этот вопрос обсуждался. Убеждали, что luksClose достаточно по крайней мере для ключа. Про данные в памяти не помню.
Подтверждаю, тоже сталкивался с таким эффектом. И вероятно вы правы в своём объяснении.
Батарею? Ноут что-ли? Почему она не обесточивается просто при выключении? Ну как максимум достаточно считать, что до выключения данные из закрытых контейнеров могут быть подвержены утечке через память.
Да.
Я не уверен, что shutdown ноубука подразумевает обесточивание планок оперативной памяти — это вопрос к электронщикам. Раз физически напряжение в ноутбуке имеется, трудно что-то гарантировать, не зная как оно работает.
Если проверять скорость чтения в лоб с шифрованных разделов на внешних USB (вытыкать и снова втыкать), то эффекта не наблюдается. Но, может, это только для USB так.
Другая возможная гипотеза: есть дисковый кэш, содержимое секторов последнего доступа кэшируется (как есть, шифрованное). Если какие-то сектора уже в памяти, то они будут расшифрованы быстрее, чем те, что на диске. В случае файловых систем, при применении к ним find'а, ключевое — список файлов в каталогах. Он с успехом может влезть в первые сектора, или куда там.
Подобный эффект наблюдается просто при запуске find без всяких отмонтирований/перемонтирований LUKS (и даже без шифрования, наверное): повторный запуск любой команды find, даже если диск на сотню гигабайт, отрабатывает моментально, хотя первый запуск требует минуты.
Говорят, что в винде при выделении памяти юзерским процессам она предварительно зануляется (иначе всё совсем было бы плохо). В Linux, должно быть, это работает так же, т.е. если кто и имеет доступ к старым данным в оперативке, то только root.
Но, скорей всего, данные действительно фоново зануляются[link11] ядром для всех.