id: Гость   вход   регистрация
текущее время 18:00 29/03/2024
Владелец: SATtva (создано 21/02/2008 22:12), редакция от 20/03/2008 14:37 (автор: SATtva) Печать
Категории: инфобезопасность, защита дисков, хард, атаки
http://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 След.
Комментарии [скрыть комментарии/форму]
— Гость (20/01/2009 04:25)   <#>
с дикими тормозами
Если удастся перед "замораживанием" загрузить в кэш наиболее часто используемые участки памяти, или если в системе больше одного процессора, то и производительность сильно не пострадает:
Back to more "traditional" performance aspects. What can be done to minimize the impact of freezing the CPU cache? Loading the most frequently used memory areas into the cache (before freezing it) is a great start. Among the highest potential candidates are: the system call entry point, the timer interrupt routine and its "helper" functions and the encryption/decryption functions executed by the kernel thread. Current L2 caches are usually large enough to hold all this code, but one also needs to consider the cache's associativity in order to not shoot one into the foot. Another good idea is to schedule all other processes onto any of the other available CPUs (which don't use the frozen cache): this allows for them to be executed at "normal" speed. There's another why this is important, but we'll get to this some other time.
— ntldr (20/01/2009 05:47)   профиль/связь   <#>
комментариев: 371   документов: 19   редакций: 20
Автор методики предлагает использовать её только для временной блокировки машины

Для блокировки машины можно использовать более простой и надежный метод. Нужно полностью перехватить управление у ОС, чтобы исполнялся только наш код, и зашифровать всё содержимое памяти пользовательским паролем. Теперь машину невозможно разблокировать без ввода пароля, и снятие дампа памяти ничего не даст.

последнюю строчку предыдущего послания надо расцитировать

Глубокоуважаемый тролль, если вы не осознаете бредовости этой идеи, то придется вам объяснить. Для начала хочу сказать, что я не теоретик – я практик. Я занимаюсь конкретными работающими реализациями, и очень отрицательно отношусь к всякого рода извращениям.
Поэтому я всё же буду настаивать на невозможности практической реализации этой концепции. Это идея того же рода, что и хранить ключ в регистрах процессора. Можно сделать концептуальный код, но его нельзя будет использовать в реальной среде. Ну а так, как разговор шел не об извращениях, а о практических методах защиты, то я сразу указал на бредовость таких идей.
В реальной среде кэшированием данных управляет ОС. Обязательно будут конфликты с драйверами видеокарты, которые устанавливают свои настройки кэширования на некоторые области памяти. Лечится это только переводом в VGA режим, со всеми вытекающими.
Предварительно загрузить в кэш наиболее часто используемый код можно только тогда, когда это ваш, полностью известный код, и он очень редко меняется во время работы системы. Но тут вас ожидает жестокий облом – исполняемый код в памяти меняется каждый раз, когда вы запускаете новую программу, и иногда и чаще, так как многие программы подгружают динамические библиотеки. Ну и совсем уж невозможно заранее загрузить в кэш обрабатываемые данные, потому что они больше его размера. Короче говоря, такой подход мертв, и его использование порождает на порядок больше проблем, чем решает.
Если вы имеете на этот счет другое мнение, то вам никто не запрещает реализовать это в своём софте, удачи!
— ntldr (20/01/2009 06:51)   профиль/связь   <#>
комментариев: 371   документов: 19   редакций: 20
Для интереса решил оценить потенциальные риски утечки ключей при использовании этого метода в Windows. Начнем с того, что первая встретившаяся инструкция wbinvd сбросит содержимое кэша в память, после чего наша безопасность превращается в иллюзию безопасности.
Берем дизассемблер, открываем в нём ядро Windows XP SP3 (ntkrpamp.exe), и ищем wbinvd. Искомая инструкция обнаруживается в функциях KeInvalidateAllCaches, KeInvalidateAllCachesTarget, KiLoadPAT и KiLoadMTRR. Функция KeInvalidateAllCaches вызывается из часто используемой железными драйверами функции MmMapIoSpace. Сброс кэша произойдет при попытке отображения памяти с атрибутом MmWriteCombined (такие атрибуты ставятся на видеопамять, какое совпадение!). KiLoadMTRR вызывается при переконфигурации процессора, например после выхода из ждущего режима.
Для полноты картины засунем в дизассемблер драйвер видеокарт Nvidia (nv4_mini.sys). В нём присутствует три инструкции wbinvd в разных местах, и два вызова MmMapIoSpace с типом кэширования MmWriteCombined. Можно поковырять еще парочку популярных драйверов, но мне стало влом, и без того понятно, что ключи в кэше долго не протянут.

А если еще чуток поразмыслить, то можно прийти к выводу, что даже собственноручно написанная ОС не сможет гарантировать невозможность сброса кэша в память. В x86 совместимых процессорах существует режим SMM (system management mode), который используется BIOS для выполнения разных служебных функций параллельно с ОС. Этот режим имеет максимальный приоритет, не контролируется ОС, и активно используется в ноутбуках для управления питанием и задействования специальных клавиш. Никто не может гарантировать, что обработчик прерывания SMI не будет сам управлять кэшированием и сбрасывать кэш в память. Поэтому такая защита быстро станет иллюзией защиты даже в приближенных к идеальным условиях.
Всё, можете закапывать. Для сомневающихся могу предоставить листинги из дизассемблера.
— Гость (20/01/2009 09:59)   <#>
Можно сделать концептуальный код, но его нельзя будет использовать в реальной среде.
Cогласитесь, что всё таки есть разница между между понятиями "практическое" и "принципиальное". Вы утверждали, что это решение, цитирую:"принципиально невозможное". Вероятно это просто была ваша оговорка, или мы с вами просто по разному понимаем слово "принципиально". Вы практик, это замечательно, спасибо вам за программу, но кому-то ведь ещё бывают интересны и принципиальные вопросы, и этот интерес автоматически не делает человека троллем.

Ещё хотелось бы услышать Ваш комментарий по поводу систем с несколькими процессорами.
— Гость (20/01/2009 10:19)   <#>
идея того же рода, что и хранить ключ в регистрах процессора
Насколько я понял (из ваших же слов на вашем старом форуме), можно хранить ключ в отладочных регистрах процессора, но при этом возможен конфликт с некоторыми возможными системами защиты от копирования.
Однако вполне вероятна ситуация, когда человек ради безопасности будет готов отказаться от программ, использующих подобные защитым. (А может таковых в природе не окакжется, как случилось с комбинацией битов при переходе на длинные имена файлов в Windows.)
— ntldr (20/01/2009 11:48, исправлен 20/01/2009 11:52)   профиль/связь   <#>
комментариев: 371   документов: 19   редакций: 20
Ещё хотелось бы услышать Ваш комментарий по поводу систем с несколькими процессорами.

Больших отличий от систем с одним процессором тут нет, просто усложняется реализация, т.к. нужно обеспечить синхронность кэшей не всех процессорах, и увеличивается риск утечки, т.к. инструкция wbinvd выполненная на одном процессоре будет сбрасывать разделяемые кэши.

Насколько я понял (из ваших же слов на вашем старом форуме), можно хранить ключ в отладочных регистрах процессора

Еще в XMM и FPU регистрах, при условии, что софт не будет их использовать. К сожалению, реальный софт их использует.

но при этом возможен конфликт с некоторыми возможными системами защиты от копирования.

Подозреваю, что не только с защитами от копирования. Этот вопрос надо изучать. Как минимум, придется решить проблему с сохранением процессорного контекста в памяти при переключении потоков, либо по запросу приложения. Моя интуиция говорит, что такие решения принесут только кучу проблем и породят дополнительные уязвимости, т.к. их безопасность сильно зависит от неконтролируемого мной кода.
— Гость (20/01/2009 12:18)   <#>
А что страшного произойдёт, если будет испорчен ключ, хранящийся в регисте? Если сравнивать хэши, это можно тут-же обнаружить, и запросить у пользователя пароль заново.
— Гость (20/01/2009 12:36)   <#>
Больших отличий от систем с одним процессором тут нет
Я имел ввиду это:
Another good idea is to schedule all other processes onto any of the other available CPUs (which don't use the frozen cache): this allows for them to be executed at "normal" speed.
Как вы считаете, возможно ли практически приемлемым способом "заморозить" кэш на одном процессоре, а другие использовать в обычном режиме. Так сказать, чтобы и производительность соблюсти, и безопасность приобрести. А на одном многоядерном?
— ntldr (20/01/2009 16:20)   профиль/связь   <#>
комментариев: 371   документов: 19   редакций: 20
А что страшного произойдёт, если будет испорчен ключ, хранящийся в регисте? Если сравнивать хэши, это можно тут-же обнаружить, и запросить у пользователя пароль заново.

Страшно – если не испорчен, а прочитан. И запрашивать пароль по несколько раз в секунду – не лучшая идея. К тому же элементарно может возникнуть ситуация, что чтобы запросить пароль, нам нужно прочитать с диска соответствующий код (выкинутые в своп библиотеки), а чтобы их прочитать – нам уже нужен пароль.

Как вы считаете, возможно ли практически приемлемым способом "заморозить" кэш на одном процессоре, а другие использовать в обычном режиме. Так сказать, чтобы и производительность соблюсти, и безопасность приобрести. А на одном многоядерном?

Только в том случае, если этот процессор имеет независимый кэш, будет полностью выключатся из системы, и используется только нашим кодом. Но мы не можем контролировать исполнение SMM кода, а значит не можем дать гарантию, что он не будет сбрасывать кэш. Поэтому пользователи ноутбуков могут получить неприятный сюрприз.
Вывод: использование выделенного процессора для хранения ключей работоспособно далеко не на любом железе, и безопасность зависит от неконтролируемого нами кода BIOS.
Методов работающих не всегда и имеющих не очевидное поведение следует всеми силами избегать в юзабельном софте.
— grm (20/01/2009 19:59)   профиль/связь   <#>
комментариев: 5   документов: 0   редакций: 0
Для блокировки машины можно использовать более простой и надежный метод. Нужно полностью перехватить управление у ОС, чтобы исполнялся только наш код, и зашифровать всё содержимое памяти пользовательским паролем. Теперь машину невозможно разблокировать без ввода пароля, и снятие дампа памяти ничего не даст.


Не планируете реализовать данный функционал на базе своей программы, или отдельным приложением?
Думаю что пользователям данная функция придется по вкусу.
— ntldr (20/01/2009 21:13)   профиль/связь   <#>
комментариев: 371   документов: 19   редакций: 20
Не планируете реализовать данный функционал на базе своей программы, или отдельным приложением?

Я уже ковырял эту концепцию на предмет подводных камней. Реализация будет достаточно сложной, с некоторыми ограничениями, но ничего невозможного в ней нет. Выпускать буду отдельным приложением. Насчет сроков пока ничего сказать не могу.
— Гость (21/01/2009 02:04)   <#>
Реализация будет с некоторыми ограничениями

А какие будут ограничения?
— ntldr (21/01/2009 03:18)   профиль/связь   <#>
комментариев: 371   документов: 19   редакций: 20
Чтобы разблокировать систему, нужно ввести пароль с клавиатуры. В отсутствии функций ОС будет доступна только работа напрямую с железом, так что владельцам USB, Bluetooth, и других клавиатур требующих vendor-specific драйверов не повезло.
Допускаю также, что будут конфликты с драйверами различных железок, и не все из них можно будет устранить.
— Гость (21/01/2009 08:37)   <#>
А если использовать какую-нибудь миниатюрную версию linux/dos/... c нужыми драйверами?
— unknown (22/01/2009 11:00)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664
http://frozencache.blogspot.com/

"A blog about the development of a general-purpose solution for mitigating cold-boot attacks on Full-Disk-Encryption solutions."
На страницу: 1, 2, 3, 4, 5, 6, 7, 8 След.
Ваша оценка документа [показать результаты]
-3-2-1 0+1+2+3