Контрмеры к cold boot attack
2011-05-30 09:32 pm![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
waqurВсе системы шифрования данных, которые выполняются в оперативной памяти компьютера, принципиально уязвимы к cold boot attack - это когда криптоключи в оперативной памяти остаются после останова ОС, и их оттуда можно вычитать сразу после перезагрузки или после непродолжительного холодного простоя.
А если брызнуть на планку DRAM из баллончика с жидким азотом, то это даёт достаточно времени, чтобы не спеша переставить её в другой компьютер и снять дамп.
Существуют практические реализации этой атаки:
http://www.mydigitallife.info/bitlocker-filevault-dm-crypt-and-truecrypt-encryption-key-crack-via-dram-cold-boot-attack-with-program-source-code-download/
Как с этим бороться?
TPM тут не поможет - это не криптоакселлератор, да и весь шифротраффик через шину LPC прогнать всё равно никак не получится - в буквальном смысле, "кишка тонка".
Идея отключить синхронизацию (подмножества) L1/L2/L3 кэша на оперативную память достаточно хороша, её даже применяет BIOS при загрузке -- для декомпрессии образа BIOS из флеш-памяти вполне годится L3-кэш процессора, ведь его сейчас всегда больше 1Мбайта -- таким образом, BIOS при полном отсутствии планок ОЗУ на борту может легко распаковаться из EEPROM в L3-кэш процессора и запуститься оттуда, чтобы издать свои трели в PC спикер, а то и обматерить удивлённого юзера через подключённый монитор.
Но, к сожалению, идея непереносима -- все эти фокусы с кэш-памятью, MTRR и так далее очень чипсетозависимы и ведомы одному только BIOS'у.
У немцев из University of Erlangen-Nuremberg есть идея получше: они сделали реализацию AES, которая хранит своё состояние целиком в регистрах процессора (РОНы и SSE считаюся занятыми, но ведь есть отладочные DRx!). Конечно, это ещё не полноценный трукрипт, но достаточно убедительное доказательство концепции.
http://www1.informatik.uni-erlangen.de/tresor/
А если брызнуть на планку DRAM из баллончика с жидким азотом, то это даёт достаточно времени, чтобы не спеша переставить её в другой компьютер и снять дамп.
Существуют практические реализации этой атаки:
http://www.mydigitallife.info/bitlocker-filevault-dm-crypt-and-truecrypt-encryption-key-crack-via-dram-cold-boot-attack-with-program-source-code-download/
Как с этим бороться?
TPM тут не поможет - это не криптоакселлератор, да и весь шифротраффик через шину LPC прогнать всё равно никак не получится - в буквальном смысле, "кишка тонка".
Идея отключить синхронизацию (подмножества) L1/L2/L3 кэша на оперативную память достаточно хороша, её даже применяет BIOS при загрузке -- для декомпрессии образа BIOS из флеш-памяти вполне годится L3-кэш процессора, ведь его сейчас всегда больше 1Мбайта -- таким образом, BIOS при полном отсутствии планок ОЗУ на борту может легко распаковаться из EEPROM в L3-кэш процессора и запуститься оттуда, чтобы издать свои трели в PC спикер, а то и обматерить удивлённого юзера через подключённый монитор.
Но, к сожалению, идея непереносима -- все эти фокусы с кэш-памятью, MTRR и так далее очень чипсетозависимы и ведомы одному только BIOS'у.
У немцев из University of Erlangen-Nuremberg есть идея получше: они сделали реализацию AES, которая хранит своё состояние целиком в регистрах процессора (РОНы и SSE считаюся занятыми, но ведь есть отладочные DRx!). Конечно, это ещё не полноценный трукрипт, но достаточно убедительное доказательство концепции.
http://www1.informatik.uni-erlangen.de/tresor/
![[identity profile]](https://www.dreamwidth.org/img/silk/identity/openid.png){kind=small}
no subject
Date: 2011-05-31 03:42 am (UTC)Я в смысле, про фриизнг плашек никогда не слыхал. Вот же жесть. Я когда эти строчки читал, сразу представил Шона О'Коннери, склонившегося над ноутбуком злодея с балончиком жидкого азота в руке.
no subject
Date: 2011-05-31 08:35 am (UTC)а если при шатдауне ОС очистить RAM, залить ее каким-то мусором?
no subject
Date: 2011-05-31 08:41 am (UTC)no subject
Date: 2011-05-31 08:44 am (UTC)тогда при выдергивании вилки из розетки тебе сильно вряд ли повезет.
no subject
Date: 2011-05-31 08:59 am (UTC)http://en.wikipedia.org/wiki/Block_cipher_modes_of_operation#Counter_.28CTR.29
Ключ key вычитывается с диска при монтировании тома, он хранится в нескольких экземплярах в зашифрованном виде, а для расшифровки используется хэш от пароля. (Двухуровневая система нужна, чтобы юзер мог быстро сменить пароль.)
Так вот, где трукрипту хранить ключ key, кроме как в ОЗУ и притом постоянно ?
Программа принимает меры, чтобы ключ не попал в paged pool, но реально - это всё, что можно сделать сейчас.
А вот на линуксе теперь ключ key можно будет хранить в отладочных регистрах DRx. Аппликухи читать их не могут, ядро их не использует (как в винде), конечно надо сделать патч, чтобы они не сохранялись в основную память при переключениях контекста.
no subject
Date: 2011-05-31 09:11 am (UTC)ну это пиздец какой кривой хак, не говоря уже о том, что не только x86 архитектурой единой.
а вообще опасность угрозы преувеличена -- злоумышленника нельзя физически подпускать к железу.
no subject
Date: 2011-05-31 09:20 am (UTC)Хак как раз достаточно хороший, заставит задуматься чипмейкеров о выделенных крипторегистрах, доступных только ядру. Как в своё время инициалива GPGPU дала пинок под зад технологиям NVidia CUDA и AMD Stream.
На самом деле, в x86-процессоре полным-полно разной памяти (кэши разных уровней, скрытая память для SMM-режима, память для обновлений микрокода), только к ней шиш доберёшься программным способом. Добавление ещё пары-тройки килобайт для криптоцелей + нормальный арбитраж этих ресурсов из ядра - не повредит.
no subject
Date: 2011-05-31 09:23 am (UTC)