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
комментариев: 371 документов: 19 редакций: 20
Для блокировки машины можно использовать более простой и надежный метод. Нужно полностью перехватить управление у ОС, чтобы исполнялся только наш код, и зашифровать всё содержимое памяти пользовательским паролем. Теперь машину невозможно разблокировать без ввода пароля, и снятие дампа памяти ничего не даст.
Глубокоуважаемый тролль, если вы не осознаете бредовости этой идеи, то придется вам объяснить. Для начала хочу сказать, что я не теоретик – я практик. Я занимаюсь конкретными работающими реализациями, и очень отрицательно отношусь к всякого рода извращениям.
Поэтому я всё же буду настаивать на невозможности практической реализации этой концепции. Это идея того же рода, что и хранить ключ в регистрах процессора. Можно сделать концептуальный код, но его нельзя будет использовать в реальной среде. Ну а так, как разговор шел не об извращениях, а о практических методах защиты, то я сразу указал на бредовость таких идей.
В реальной среде кэшированием данных управляет ОС. Обязательно будут конфликты с драйверами видеокарты, которые устанавливают свои настройки кэширования на некоторые области памяти. Лечится это только переводом в VGA режим, со всеми вытекающими.
Предварительно загрузить в кэш наиболее часто используемый код можно только тогда, когда это ваш, полностью известный код, и он очень редко меняется во время работы системы. Но тут вас ожидает жестокий облом – исполняемый код в памяти меняется каждый раз, когда вы запускаете новую программу, и иногда и чаще, так как многие программы подгружают динамические библиотеки. Ну и совсем уж невозможно заранее загрузить в кэш обрабатываемые данные, потому что они больше его размера. Короче говоря, такой подход мертв, и его использование порождает на порядок больше проблем, чем решает.
Если вы имеете на этот счет другое мнение, то вам никто не запрещает реализовать это в своём софте, удачи!
комментариев: 371 документов: 19 редакций: 20
Берем дизассемблер, открываем в нём ядро 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 не будет сам управлять кэшированием и сбрасывать кэш в память. Поэтому такая защита быстро станет иллюзией защиты даже в приближенных к идеальным условиях.
Всё, можете закапывать. Для сомневающихся могу предоставить листинги из дизассемблера.
Ещё хотелось бы услышать Ваш комментарий по поводу систем с несколькими процессорами.
Однако вполне вероятна ситуация, когда человек ради безопасности будет готов отказаться от программ, использующих подобные защитым. (А может таковых в природе не окакжется, как случилось с комбинацией битов при переходе на длинные имена файлов в Windows.)
комментариев: 371 документов: 19 редакций: 20
Больших отличий от систем с одним процессором тут нет, просто усложняется реализация, т.к. нужно обеспечить синхронность кэшей не всех процессорах, и увеличивается риск утечки, т.к. инструкция wbinvd выполненная на одном процессоре будет сбрасывать разделяемые кэши.
Еще в XMM и FPU регистрах, при условии, что софт не будет их использовать. К сожалению, реальный софт их использует.
Подозреваю, что не только с защитами от копирования. Этот вопрос надо изучать. Как минимум, придется решить проблему с сохранением процессорного контекста в памяти при переключении потоков, либо по запросу приложения. Моя интуиция говорит, что такие решения принесут только кучу проблем и породят дополнительные уязвимости, т.к. их безопасность сильно зависит от неконтролируемого мной кода.
комментариев: 371 документов: 19 редакций: 20
Страшно – если не испорчен, а прочитан. И запрашивать пароль по несколько раз в секунду – не лучшая идея. К тому же элементарно может возникнуть ситуация, что чтобы запросить пароль, нам нужно прочитать с диска соответствующий код (выкинутые в своп библиотеки), а чтобы их прочитать – нам уже нужен пароль.
Только в том случае, если этот процессор имеет независимый кэш, будет полностью выключатся из системы, и используется только нашим кодом. Но мы не можем контролировать исполнение SMM кода, а значит не можем дать гарантию, что он не будет сбрасывать кэш. Поэтому пользователи ноутбуков могут получить неприятный сюрприз.
Вывод: использование выделенного процессора для хранения ключей работоспособно далеко не на любом железе, и безопасность зависит от неконтролируемого нами кода BIOS.
Методов работающих не всегда и имеющих не очевидное поведение следует всеми силами избегать в юзабельном софте.
комментариев: 5 документов: 0 редакций: 0
Не планируете реализовать данный функционал на базе своей программы, или отдельным приложением?
Думаю что пользователям данная функция придется по вкусу.
комментариев: 371 документов: 19 редакций: 20
Я уже ковырял эту концепцию на предмет подводных камней. Реализация будет достаточно сложной, с некоторыми ограничениями, но ничего невозможного в ней нет. Выпускать буду отдельным приложением. Насчет сроков пока ничего сказать не могу.
А какие будут ограничения?
комментариев: 371 документов: 19 редакций: 20
Допускаю также, что будут конфликты с драйверами различных железок, и не все из них можно будет устранить.
комментариев: 9796 документов: 488 редакций: 5664
"A blog about the development of a general-purpose solution for mitigating cold-boot attacks on Full-Disk-Encryption solutions."