Моя система зашифрована с помощью Full Disk Encryption, т.е. все, кроме /boot, зашифровано с помощью dmcrypt/luks. Меня беспокоитАтаки с холодной загрузкой, где исследователипродемонстрировано, этот контент может быть извлечен дляоколо 5 минут.
Можете ли вы предоставить инструкции по следующим вопросам:
- как запустить kexec в новом ядре на самых последних этапах процесса выключения/перезагрузки (чтобы обеспечить чистое размонтирование, предотвратить повреждение файловой системы, гарантировать перезапись старого ядра)
- как создать это ядро, которое стирает всю оперативную память
т.е. Можете ли вы объяснить, как сделать то же самое в Ubuntu?
Как обнаружить выключение? Как запустить очистку RAM? Оперативная память должна быть очищена, когда пользователь нажимает «выключение» или если он запускает «скрипт паники».
Спасибо за ваши старания!
Предыдущие работы:
- Введение в Tails RAM Wipe
- Еще немного информации о реализации Tails RAM Wipe
- Введение в Liberte Linux RAM Wipe
- Дополнительные сведения о реализации Liberte Linux RAM Wipe
- memtest не удаляет все
- Проверьте, работает ли очистка RAM
- Обсуждение списка рассылки Tails
- Еще одно обсуждение в почтовой рассылке Tails
- Отчет об ошибке ядра
Если вы хотите, чтобы эта функция стала реальностью, проголосуйте на Ubuntu Brainstorm!
решение1
Если вы не используете старую оперативную память типа DDR2, 512 МБ или 1024 МБ, то вам не стоит беспокоиться о CBA.
Взгляните на оригинальное исследованиездесь(PDF-файл).
Если вы внимательно прочтете, то обнаружите, что только DDR2 и более старые подвержены этой атаке. DDR3 теряет напряжение слишком быстро, чтобы позволить корпусу компьютера разобрать и заморозить процедуру. Так что просто выдерните вилку из розетки, прежде чем открывать дверь.
Также,Эта бумагаподтверждает, что DDR3 не подвержен CBA. Если вы действительно хотите обезопасить себя, потому что у вас есть оперативная память DDR2, то включите в BIOS:
- Автозапуск после потери питания
- Проверка оперативной памяти во время загрузки
и сделайте то же самое, что и с DDR3, но после того, как вытащите вилку, вставьте ее обратно. Ваш компьютер запустится сам и сотрет оперативную память, проверив ее. Если он не очистит достаточно эффективно, процесс загрузки снова загрузит систему в оперативную память. Это будет слишком быстро, чтобы позволить CBA.
ИзсвязьВы указали в комментариях:
Поэтому, в заключение, атака с холодной загрузкой не должна рассматриваться как основной метод получения памяти подозрительной компьютерной системы. Вместо этого, другие методы, включая как программное, так и аппаратное получение (например, FireWire), должны быть испробованы до проведения атаки с холодной загрузкой против указанной системы. Однако, если возникает ситуация, когда вышеупомянутые методы либо недоступны (например, отсутствие подключения FireWire или консоли входа в систему или удаленное получение памяти невозможно) или неэффективны, тогда атака с холодной загрузкой может быть применена, предполагая, что следователь понимает, как и где может возникнуть проблема и пойти не так.
Как показало это исследование, атака с холодной загрузкой не может быть признана особенно криминалистически обоснованной или надежной, поскольку в большинстве проведенных здесь экспериментов резидентные ключи шифрования памяти не могли быть последовательно найдены или извлечены, хотя они должны были быть. То же самое можно сказать и о различных строках и поиске ключевых слов, которые должны были выдать гораздо больше строк и ключевых слов, чем было найдено для большинства экспериментов. Более того, как было показано, сам факт мгновенной заморозки памяти компьютера не гарантирует успешного получения этой памяти. Другие факторы и переменные, которые уже были рассмотрены, полностью изучили эти проблемы и их основные причины. Таким образом, по мнению авторов этого исследования, атака с холодной загрузкой может быть полезна в некоторых случаях для получения памяти подозреваемой системы, но этот метод не следует считать панацеей, а вместо этого его следует использовать в качестве крайней меры, когда все другие пути исчерпаны.
Наконец, даже успешное получение, которое подверглось незначительной или нулевой деградации, скорее всего, не будет выступать в суде в качестве весомого доказательства, по крайней мере, до тех пор, пока не будет проведена судебная практика и не будет доказано, что целостность полученной памяти не повреждена с использованием надежной и понятной методологии. Продолжается поиск более правильного и надежного способа получения памяти компьютера подозреваемого...
Также, если вы проверите результаты эксперимента, вы поймете, что они успешно извлекли ключи AES только в системах 2 и 6, и это были атаки с горячей загрузкой, если вы посмотрите на характеристики системы 2 - 1024 МБ ОЗУ 533 МГц - это старая штука. Другая система - система 6 с 256 ОЗУ / 128 ОЗУ - я думаю, это само собой разумеется.
Вот почему их вывод был таким:
Продолжаются поиски более правильного и надежного способа получения памяти компьютера подозреваемого...
На самом деле я считаю, что если у вас есть очень очень очень важные данные, вам следует не только использовать Full Drive Encryption, но и хранить их в отдельном зашифрованном файле. Зашифрованном каскадными алгоритмами и другим паролем, чем тот, который использовался при шифровании диска. Вам нужен безопасный способ выключения ПК? Вот он:
- Храните безопасные данные в зашифрованном файле с каскадным алгоритмом True Crypt
- Использовать змея
- Создайте скрипт для обработки выключения:
Для Windows:
truecrypt.exe /wipecache
shutdown -s -f -t 1
Для Linux:
truecrypt /wipecache
shutdown -h now
Очистка кэша гарантирует, что после выключения в оперативной памяти не останется уязвимых данных. Если кто-то выполнит атаку Cold Boot, то в лучшем случае получит доступ к вашей системе. У него не будет данных, хранящихся в отдельно зашифрованном файле.
решение2
Питер А. Х. Петерсон из Калифорнийского университета в Лос-Анджелесе написал концептуальную технологию и разработал теорию для безопасной работы вашей системы с зашифрованной оперативной памятью. Решение:явноразработано для предотвращения атак с холодной загрузкой. Название его статьи — Cryptkeeper. Я не знаю, делает ли он программное обеспечение доступным для загрузки или можно ли лицензировать его в UCLA. Однако, по-видимому, возможно, по крайней мере в принципе, разработать криптосистему для RAM, которая будет безопасна, даже если все содержимое RAM будет раскрыто.
Измеренное влияние этого решения на производительность составляет от 9% накладных расходов до замедления в раз9, в зависимости от того, насколько «патологическим» является сценарий. Цифра в 9% упоминается как применимая к просмотру веб-страниц с помощью Firefox, но они не указали, какой вариант использования замедлит производительность в 9 раз.
Решение Петерсона не "стирает" ОЗУ, как вы предлагаете. Вместо этого оно использует "безопасный механизм сокрытия ключей", чтобы предотвратить раскрытие ключа дешифрования просто в силу получения содержимого ОЗУ. Я не уверен в деталях реализации, но предполагаю, что это объясняется в статье.
Статья была опубликована в 2010 году.
Его можно купить на сайте IEEE ieeexplore. Его также можно бесплатно загрузить напрямую в формате PDF с чьего-то сайта; он есть в результатах поиска Google по запросу "cryptkeeper RAM"... но я не уверен, как долго этот результат там останется.
Я хотел сделать это комментарием, а не ответом, потому что это решение не «стирает» ОЗУ, как вы просили. Однако я считаю, что если исследование Петерсона технически верно, это будет иметь тот же практический эффект — или, возможно, даже «лучший» эффект — чем очистка ОЗУ. Причина в том, что опытный физический злоумышленник, вероятно, мог бы прервать попытку вашей системной программы стереть ОЗУ, если бы он ожидал, что такая операция произойдет — например, вытащив батарею из устройства или удерживая кнопку питания до того, как операция сможет завершиться. Решение Петерсона более безопасно, потому что оно не основано на необходимом временном окне, в течение которого компьютеру разрешено продолжать выполнять инструкции для завершения очистки. Вместо этого памятьпостояннозащищенным, даже если сам процессор будет мгновенно уничтожен каким-то невероятным достижением техники еще до того, как вы успеете отреагировать на атаку.
Под «невероятным достижением технологий» я подразумеваю что-то вроде Stuxnet.
решение3
Я бы предположил,memtest86было бы неплохо для очистки оперативной памяти. Я всегда хотел попробовать ниже, но не пробовал. Если попробую, обновлю.
Прочитать kexecстраницу руководства. И не пытайтесь использовать kexec.iso, вам нужно распаковать iso и получить загрузочный бинарный файл. На сайте memtest86 выше вы можете просто скачать бинарный файл.
Вам необходимо использовать kexecкоманду для загрузки того, с чего вы загружаетесь в первую очередь.
Поэтому я думаю, что вы можете сделать следующее:
kexec -l {path-to-memtest86-bootable-binary} --append=console=ttyS0,115200n8
и когда вы будете готовы нажать на курок:
kexec -e
Я думаю (но могу ошибаться), что --append=console=ttyS0,115200n8memtest86 работает через последовательный порт. Так что если у вас есть такой, вы можете проверить его работоспособность, даже если он не отображается на видеовыходе, что вполне возможно, поскольку memtest86 не выполняет инициализацию видео. Уничтожение всех запущенных экземпляров X, вероятно, является хорошей идеей.
Пакет Debian kexec-tools(также доступен в Ubuntu) подключает это к скриптам выключения, так что если вы отредактируете, /etc/default/kexecто сможете указать процессу выключения вызываться kexecкак финальное действие вместо перезагрузки. То есть, если вас интересует чистое выключение.
В чрезвычайной ситуации sync; kexec -eподойдет вариант a.
Однако, возможно, что некоторые чипсеты, после инициализации, вызывают блокировки, если обращаются к определенным областям памяти. Я не знаю, как это будет работать на практике.
Хорошим компромиссом, если kexecне работает, будет установить memtest86 в ваш загрузчик, сделать его элементом загрузки по умолчанию и задать задержку в 1 секунду до автоматического выбора (или вообще не задерживать и полагаться на нажатие клавиши для вызова memu). Это может довольно быстро перевести вас в memtest86 из состояния «свежей загрузки», но не мгновенно.
Обратите внимание, что это не учитывает видеопамять. Решение для этого -настройте видеопамять как блочное устройствои вывод /dev/randomна блочное устройство в течение нескольких итераций.
решение4
Проблема в том, что ваш компьютер работает, а экран заблокирован. В этот момент ключ AES хранится в оперативной памяти, а пользователь находится вдали от компьютера. Злоумышленник может открыть корпус компьютера и извлечь модули оперативной памяти, оставив их включенными и поместив их в отдельное устройство, которое считывает их содержимое. Нет необходимости выключать систему или замораживать модули перед извлечением. Оперативная память не является надежным хранилищем ключа AES, но кэш процессора является надежным, как и решение под названием TRESOR. К сожалению, для этого требуется старое ядро Linux и продвинутые знания по исправлению и компиляции ядра.