id: Гость   вход   регистрация
текущее время 10:56 25/04/2024
Владелец: SATtva (создано 21/02/2008 22:12), редакция от 20/03/2008 14:37 (автор: SATtva) Печать
Категории: инфобезопасность, защита дисков, хард, атаки
https://www.pgpru.com/Новости/2008/ДисковоеШифровниеМожетБытьВзломанохолоднойПерезагрузкой
создать
просмотр
редакции
ссылки

21.02 // Дисковое шифровние может быть взломано "холодной" перезагрузкой


Команда учёных из Центра ИТ-политики Принстонского университета опубликовала работу, пересматривающую эффективность современных средств дискового шифрования перед лицом реалистичной угрозы.


Исследователи рассмотрели такие общераспространённые современные средства, как dm-crypt в Linux, BitLocker в Windows Vista, FileVault в MacOS X, а также TrueCrypt. Все эти системы, как и их аналоги, размещают полученный от пользователя шифровальный ключ в оперативной памяти компьютера и используют его в дальнейшем для динамического расшифрования и зашифрования данных с диска, к которым осуществляется доступ. Модель такой защиты исходит из того, что как только цепи компьютера и схемы оперативной памяти (ОЗУ) обесточиваются, компьютер "забывает" ключ, и восстановить его без участия пользователя уже невозможно. Однако, в своей работе учёные показали, что это не так.


Типичная современная микросхема DRAM сбрасывает транзисторы не моментально с потерей напряжения, а постепенно в течение нескольких секунд или минут. Этот промежуток времени создаёт для противника окно, в которое он способен провести атаку: обесточив (выключив) компьютер, он тут же запускает его вновь и загружает в собственную облегчённую ОС (например, с загрузочного CD или USB-диска), которая создаёт полный образ оперативной памяти. Взломщику лишь остаётся найти в полученном массиве шифровальный ключ и с его помощью расшифровать жёсткий диск жертвы.


Исследователи показали, что атака остаётся осуществимой даже при частичном сбросе битов ОЗУ. Охлаждение микросхем DRAM сжатым воздухом или более высокотехнологичными методами, включая жидкий азот, позволяет чипам "сохранять память" вплоть до нескольких часов. На своей странице учёные приводят полное описание атаки и даже демонстрируют видео.


К сожалению, эта проблема не имеет простого решения; такие устройства, как Trusted Platform Module (используемый BitLocker'ом), не усложняют атаку. Хотя специалистам давно известно, что замораживание чипов ОЗУ позволяет им сохранять состояние памяти и без напряжения, данное исследование показывает, что атака может быть проведена и не обладающим сверхвысокотехнологичным оборудованием оппонентом.


Добавлено:
Джон Каллас из PGP Corporation опубликовал программную схему защиты от данной атаки (она аналогична тому, что предложили сами исследователи из Принстона, только вместо XOR'а здесь используется шифрование в режиме EME с большим блоком, благодаря чему разрядка даже одной ячейки памяти после потери напряжения приводит к искажению всех критичных данных). Схема не запатентована.


Источник: http://www.freedom-to-tinker.com/?p=1257, http://citp.princeton.edu/memory/, http://www.mail-archive.com/cr.....wd.com/msg08939.html


 
На страницу: 1, 2, 3, 4, 5, 6, 7, 8 След.
Комментарии [скрыть комментарии/форму]
— Гость (26/03/2015 04:35)   <#>

У этого есть какие-то рациональные объяснения?
— Гость (26/03/2015 08:30)   <#>

Для показа скриншотов они написали код которым вынимали содержимое памяти, и показали, что артефакты не просто случайность, а закономерность. (всё записано с их слов, разумеется) Но для привлечения внимания всё равно потребуется сайт с картинками, иначе никак.
— Гость (26/03/2015 08:38)   <#>

Типичная современная микросхема DRAM сбрасывает транзисторы не моментально с потерей напряжения, а постепенно в течение нескольких секунд или минут.

В видеопамяти не jpeg хранят, потеря части битов не вносит фатальных искажений в содержимое.
— Гость (26/03/2015 10:08)   <#>

Да, смысл понятен, но всё равно, даже если судить по обсуждениям на YCombinator'е, то о том, что такое поведение ранее наблюдали, сообщили десятки человек. Почему никто из них не пожаловался? Хотя, впрочем, кому тут пожалуешься, спортлото NVidia?

Оупенсорсники могли хотя бы предложить инструменты для зачистки RAM и другой памяти, но даже их нет (уже обсуждалось на форуме). Что-то есть в Tails, но как это прикрутить в другой ОС — большой вопрос. А с VRAM, пишут, всё ещё хуже: не вся такая память ОСи непосредственно доступна, поэтому как её переписать полностью принудительно — непростой вопрос.

Сейчас мода на тонкие ноутбуки пошла, их уже не обесточишь, т.к. батарея не вынимается, она в корпусе; вся надежда остаётся только на программные методы, а их тоже нет. ☹ Что делать? ©
— SATtva (26/03/2015 13:04)   профиль/связь   <#>
комментариев: 11558   документов: 1036   редакций: 4118

Просто потому, что все сталкивались с подобным. Я постоянно наблюдаю такую ситуацию: после перезагрузки и нового запуска иксов в первый момент перед отрисовкой десктопа на полсекунды проявляется искажённое изображение десктопа, каким оно было до перезагрузки. Было очевидно, что это проявление остаточного заряда: если отключить систему на несколько минут, проблема не воспроизводилась.
— unknown (26/03/2015 13:45)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664

Тоже сталкивался. Но это м.б. и не связано с особенностями железа: одно время такие разбитые квадратиками и линиями снимки экрана выскакивали после включения из гибернейта-в-своп, который оставался длительное время на физически выключенном десктопе. Скорее всего, тогда в своп кэшировалась вся память на момент выключения, в т.ч. иксовая, затем этот видеомусор на мгновение выкидывался на экран при старте. Реализация гибернейта несколько раз менялась, с какого-то момента эффект пропал.
— Гость (26/03/2015 17:14)   <#>
В NetBSD на протяжении многих лет (может быть, и до сих пор есть) была чем-то похожая проблема вида «бьются консольные шрифты»: после запуска иксов если снова переключиться в терминал, на месте букв появлялся слабо различимый мусор. Его иногда можно было исправить удалением дисплея, пересозданием его и повторным запуском getty. Иногда проблема коррелировала с тем, дефолтные ли шрифты используются или нет, русифицированные или нет. Но если в текстовой консоли использовался framebuffer, то проблема не проявлялась никогда (правда, для этого приходилось перекомпиливать ядро с нужными опциями).
На страницу: 1, 2, 3, 4, 5, 6, 7, 8 След.
Ваша оценка документа [показать результаты]
-3-2-1 0+1+2+3