Новая программа «Элкомсофта» ворует ключи программ BitLocker, PGP и TrueCrypt из оперативки

В этом есть какая-то новость?

Анализ файла гибернации (исследуемый компьютер выключен). Защищённые тома должны быть подключены перед выключением компьютера.

Т.е. в Windows он не шифруется? Причём не абы как, а так, как положено шифровать именно своп для гибернации?

Зашифрованные тома в момент снятия слепка должны быть подключены

может я чего то не понимаю, но зачем такие сложности, если есть доступ к компу в котором тома подключены? копируем содержимое томов и идем анализировать. по пункту 3 такая же байда.

Анализ файла гибернации

если не изменяет память, то когда выводишь комп из гипернации, например TrueCrypt, запрашивает пароль при полнодисковом шифровании.

может я чего то не понимаю, но зачем такие сложности, если есть доступ к компу в котором тома подключены? копируем содержимое томов и идем анализировать.

В каких-то ситуациях для целей судебно-экспертного анализа это может не подойти.

Я вот тоже не понимаю смысла в данной программе..
Проще сделать свой LiveUSB (на Linux ессн), настроить Tor+i2p, зашифровать полностью, и там хранить контейнеры. и все. в случае чего – выдергиваем флешку и вопросы отпадают.

Это действительно плохая новость, т.к. появление общедоступного софта превращает атаки на память из редкой экзотики в повседневную практику. Обучить пользоваться этим софтом можно любого мусора, а значит пора придумывать контрмеры.

DiskCryptor пока не поддерживается этой прогой от елкомсофта, но это дело времени. Концептуальной программной защиты я не вижу, поэтому задумываюсь об мерах "security through obscurity". Идея такова: сделать закрытую и защищенную от анализа версию DiskCryptor которая использует обфускацию участков памяти хранящих ключи и пароли, обфускацию ioctl интерфейсов драйвера и обфускацию загрузчика. Кроме того, каждый билд скачиваемый пользователем должен обладать уникальной схемой обфускации (схемы обфускации генерируются автоматически), а набор мер по обфускации должен меняться с каждым релизом. Всё это делает автоматическое излечение ключей практически невозможным, каждый билд должен будет индивидуально ковырять опытный реверсер.
Как вам такая мысль?

А что плохого то? Включенный компьютер не является зашифрованным.
В Linux в саму утилиту вставлена штатная опция показать все ключи шифрования из памяти, жалко что ли?

Для обфускации существует конечно White-Box Cryptography, но оно вроде как успешно ломается.

DiskCryptor пока не поддерживается этой прогой от елкомсофта, но это дело времени. Концептуальной программной защиты я не вижу, поэтому задумываюсь об мерах "security through obscurity".

Я думаю, рано или поздно задолбаетесь. :) Не стоит ввязываться в битву брони и снаряда.

Если

Не стоит ввязываться

, то никакой битвы и не будет.

Лучше больше полагаться на превентивные меры защиты: не держать смонтированными контейнеры в то время, когда доступ к ПК может получить форензик злоумышленник, не использовать ноутбуки с поддержкой firewire и прочих вредных портов и т.д.

не держать смонтированными контейнеры

так вот это самое очевидное. ключевой вопрос – каким образом и почему злоумышленник получает доступ к компу? можно оставить ключи в замке зажигания машины и спрашивать кто виноват что тачку угнали.

dmsetup table --showkeys показывает в Linux таблицу ключей всех открытых зашифрованных разделов. И это полезная опция для пользователя. Если злоумышленник может этой опцией воспользоваться, то пользователь уже проиграл где-то до этого. Вытащить ключи можно и ручным разбором дампов памяти.

Считывание ключей из памяти штатной утилитой позволяет организовывать в Linux иерархическое шифрование, в т.ч. и безопасный гибернейт с шифрованием. Так, у пользователя корень может быть на одном физическом разделе (томе), /home на другом, а своп на третьем. Что-то он хочет иметь на обычном винчестере, что-то на SSD, что-то на рейде, какую-то мелочь на съёмном (например для переноса информации между компьютерами). Всё это может быть прописано в /etc/crypttab как производные от соответствующих ключей. Чаще всего от корневого ключа, так чтобы при входе в систему пользователю достаточно было один раз ввести пароль и всё это иерархически расшифровалось.

при входе в систему пользователю достаточно было один раз ввести пароль и

и сразу рут? Зачем иеарархическое расшифрование? С тем же успехом можно все разделы посадить на один шифровальный ключ. Наоборот, каждый modus operandi требует своей информации, и нужно подключать/отключать нужные разделы на лету по мере надобности. Монтировать по умолчанию всё — плохой метод.

при входе в систему пользователю достаточно было один раз ввести пароль и

и сразу рут?

Пароль вводится в рамдиске. Загрузка расшифрованной системы и всех демонов с корневого раздела во всех системах продолжается от рута, затем некоторые из них сбрасывают свои привилегии по мере надобности.

Если пользователь знает пароль от корневого криптораздела, то он сразу рут по-любому — он может корень вручную расшифровать и протроянить или прописать временного второго рута или пересобрать рамдиск, чтобы после расшифровки сразу получать рута.

С тем же успехом можно все разделы посадить на один шифровальный ключ.

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

нужно подключать/отключать нужные разделы на лету по мере надобности

Если сочетать оба подхода при наличии меанизма того, как это можно просто делать, то это только повысит безопасность системы.

И не нужно недооценивать победу лени и беспечности над паранойей, даже если пользователю грозит смертельная опасность. Лучше не напрягать эти качества и дать гармонично существовать на оптимально отлаженной системе.