id: Гость   вход   регистрация
текущее время 00:22 18/11/2017
Автор темы: Вий, тема открыта 25/09/2011 06:56 Печать
Категории: инфобезопасность, защита дисков
https://www.pgpru.com/Форум/ПрактическаяБезопасность/БезопасностьСпящегоРежимаКомпьютера
создать
просмотр
ссылки

Безопасность спящего режима компьютера


При отправке компьютера в спящий режим сеанс сохраняется на жестком диске. При включении компьютера, после загрузки базовых компонентов системы, достаточно лишь ввести пароль пользователя, после чего на мониторе появляется (достаточно быстро) рабочий стол с открытыми теми программами, которые были в работе на момент завершения работы компьютера. Однако заставляет задуматься следующий факт, учитывая, что в системе используется шифрование учетной записи, хотя и стандартным способом системы, который предлагается при создании учетной записи (система Ubuntu 10/04).
А именно: учитывая очень быстрое открытие программ можно предположить, что при включении машины данные либо расшифровываются БЕЗ РУЧНОГО ввода пароля, а ввод пароля лишь разблокирует доступ к монитору, либо сохраняются в контейнер спящего режима без зашифровки. Выходит, что к пользователським данным можно получить доступ либо взяв их с винчестера, если они сохраняются в нешифрованном виде, либо включив компьютер постараться обойти блокировку монитора. Есть ли в моих рассуждениях доля истины?



 
На страницу: 1, 2 След.
Комментарии
— sentaus (25/09/2011 10:40, исправлен 25/09/2011 10:40)   профиль/связь   <#>
комментариев: 1058   документов: 16   редакций: 32

Да, всё так и есть. Если данные и зашифрованы, то ключ всё равно лежит где-то рядом на диске. Так что можно даже этот ключ найти и расшифровать снимок памяти.

— Вий (25/09/2011 15:44)   профиль/связь   <#>
комментариев: 510   документов: 110   редакций: 75
Но это как я понимаю для спящего режима. А для полного выключения, ключ то же лежит где-то рядом? Должно быть хеш-значение от пароля и только.
— SATtva (25/09/2011 16:01, исправлен 25/09/2011 16:02)   профиль/связь   <#>
комментариев: 11514   документов: 1035   редакций: 4046

Есть три режима прерывания работы: suspend, hibernate и power off. В первом текущее состояние сохраняется в ОЗУ под напряжением, все прочие компоненты обесточиваются; мастер-ключ тоже лежит в ОЗУ, как и при нормальной работе. Во втором (о котором идёт речь в данной теме) — всё содержимое ОЗУ выгружается на диск, система обесточивается целиком; мастер-ключ также оказывается на жёстком диске. В третьем — система обесточивается, волатильная память сбрасывается; ключ исчезает (через несколько секунд).

— unknown (25/09/2011 17:00, исправлен 25/09/2011 18:18)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664

Для режима Hibernate-to-swap в Debian предусмотрена настройка безопасного шифрования.


Для этого должно быть применено полное шифрование системы с использованием LVM. При этом физический том должен быть полностью зашифрован, а логический том со свопом для Hibernate должен лежать внутри этого физического тома — в этом случае больше не потребуется вообще никаких дополнительных настроек.


Можно и не использовать LVM (или использовать, но без шифрования физического тома; корневой раздел разумеется должен быть зашифрован в любом случае).


Рассмотрим такой пример для работы с LVM с нешифрованным физическим томом, с применением шифрования только логических томов (этот вариант можно адаптировать и для шифрованных разделов без LVM).


Впишем в /etc/crypttab строку вида:



Тогда decrypt_derived будет создавать ключ, вычисляемый из ключа, которым шифровали основной корневой логический том. Только если он правильно расшифруетя после введения пароля на стадии загрузки через initrd, только тогда правильно расшифруется и своп и стартует пробуждение от hibernate. Размер swap-тома рекомендуется иметь в два раза больше размера оперативной памяти.


В /etc/fstab нужно прописать новый своп и /tmp теперь иметь только в памяти (а не на диске с /dev/urandom ключом):



Теперь можно отключить работающий своп:



Если он был ещё и шифрованным на /dev/urandom, то закрыть и удалить его LUKS-слот:



Можно на всякий случай несколько раз пройтись по его начальным блокам (если он был зашифрован).



Или по всему свопу (без опции count) — если до этого он никак шифрован не был.


Теперь надо правильно отформатировать и открыть LUKS-устройство для свопа (прямо в работающей системе при открытом корневом разделе):



Размер ключа в режиме XTS всегда должен быть в два раза выше, чем в обычных режимах.


Можно посмотреть, что получилось (если интересно):



Если разобрались, в том, что видите и уверены, что всё правильно, то можно поднимать своп:



Осталось только обновить стартовый рамдиск:



Можно написать скрипт, который будет это всё проделывать сам или менять по желанию установки с шифрованного Hibernate обратно на шифрование по /dev/urandom.


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


Чтобы hibernate прожил дольше дисковых сохранений, лучше закрывать максимум ненужных программ, оставляя только необходимые. Если какое-то устройство (например USB) подключено, то в таком состоянии его лучше и оставлять при hibernate. А ещё лучше отключить до hibernate, если оно не будет нужно.


Наконец, можно иногда запускать скрипт, который бы освобождал и переформатировал hibernate-swap перед сохранением (правда это может занять много времени, но если оно есть, то почему бы так и не сделать?), чтобы в нём накапливалось меньше мусора — с каждым сохранением вероятность получить ошибку в работе программ выше. Хотя она довольно низкая и десятки гибернаций средняя система выдержать сможет.


При уходе в гибернацию на диск cryptsetup-LUKS поддерживает и корректную гибернацию всех открытых томов-контейнеров: те из них, которые были открыты, также корректно и будут выглядеть открытыми после запуска (и естественно закрытыми при уходе в hibernate).


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


Теоретические уязвимости связаны с тем, что плохо обоснована стойкость к криптоанализу режимов шифрования, которые получают на вход шифрования в виде открытого текста свой собственный ключ (что и происходит при hibernate). Так, даже специально выдвинутый на стандарт дискового шифрования режим LRW (разработанный такими известными авторами, как Лисянская, Райвист и Вагнер), оказался нестойким к атакам, действующим с условием этого обстоятельства.


Пока рекомендуется использовать AES-XTS.

— Гость (26/09/2011 16:51)   <#>
Размер ключа в режиме XTS всегда должен быть в два раза выше, чем в обычных режимах.
А можно об этом несколько поподробней? И насколько опасно невыполнение этого требования с точки зрения практического криптоанализа? Допустим, AES-XTS 128 или AES-XTS 256?

в этом случае больше не потребуется вообще никаких дополнительных настроек.
... и после этого идёт несколько экранов команд :) Или это всё равно относится к случаю "не потребуется вообще никаких дополнительных настроек"?
— Гость (26/09/2011 17:13)   <#>
Ещё немного связанных фактов.

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

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

Блокировщики экрана вообще чудны. Не далее как вчера наблюдал следующую картину: в Ubuntu'е настроена блокировка экрана по истечении некоторого срока неактивности. Работает эта фича более-менее приемлемо. Допустим, что одновременно залогинены n пользователей через gdm. Пока под одним пользователем работаешь, время для блокировки экрана под другим пользователем может подойти, и если в этот момент в него переключиться, экран будет там залочен. Однако, был пронаблюдён временной люфт между переключением в такого пользователя и блокировкой его экрана. Я даже успел открыть одно окно, и только потом экран заблокировался. Создалось впечатление, что блокировку можно как-то "приостановить" или "оттянуть по времени", получив в своё распоряжение полноценную систему. В общем, мутные они, эти блокировщики экранов...
— unknown (27/09/2011 15:54, исправлен 27/09/2011 18:00)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664

AES-XTC стандартизировался IEEE отделением SISWG и НИСТом. Для них был нужен свободный формат. Авторы этого режима сделали кальку с XEX-режима, созданного Филипом Рогвеем, опасаясь возможно, что XEX будет патентован. Так чтобы избежать возможного патентного преследования и построить свой режим на основе проверенного и имеющего хорошие доказательства стойкости. Но сами авторы, предположительно, не обладали такой квалификацией, как Рогвей и не смогли представить развёрнутых доказательств, смогли только переиначить режим, добавить некоторые возможности в плане производительности, распараллеливания, работы с разными размерами блоков и др.


При этом как-то делалось всё не очень аккуратно, хотя долго и мучительно. Вплоть до того, что они взяли за основу сокращённую версию публикации Рогвея (которую он в свою очередь похоже тоже наспех готовил к конференции) вместо полной работы, не заметили в ней опечаток и вообще не так якобы поняли.


В итоге они решили, что режим должен использовать два независимых ключа (один собственно для шифрования, другой для твик-вектора). Процедуру получения этих ключей из одного они не определили (усомнились в своих способностях сделать это аккуратно?) и предложили просто брать ключ в два раза больше и делить его надвое, чтобы подавать на два входа режима. Вопрос об одноключевом XTS не проработан до сих пор.


Другие исследователи утверждают, что разделение ключа не нужно. И даже в оригинальной работе Рогвея такой вариант возможно нужен не для дискового шифрования, а для других протоколов. Якобы XTS был бы доказуемо стоек и с одним ключом.


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


Есть масса претензий к XTS, даже и по плохо обоснованной стойкости, хотя Рогвей fileвписал этот режим себе в curriculum vitae, как производный от своего собственного – вроде как признал своим достижением идею, положенную в стандарт.


Эпические дебаты есть в:


NIST, “Public Comments on the XTS-AES Mode.”
Moses Liskov and Kazuhiko Minematsu, “Comments on XTS-AES.”
Matthew V. Ball, Sun Microsystems, Chair of IEEE Security in Storage Working Group (P1619), “Public Comments on the XTS-AES Mode.”
Willett, Michael, Seagate Technology, “Comments provided to NIST in response to: Request for Public Comment on XTS/AES.”


...и др. публикации


В програмных реализациях жёстко задано разделение ключа на две части, каждая из которых используется для разного AES-шифрования. Так что получается, что AES-XTS-256 эквивалентен по стойкости AES-128, а AES-XTS-512 – AES-256.


Была дискуссия и в рассылке Debian. Пока, в отличие от Рэдхата например, поддержку AES-XTS не стали включать по умолчанию. Не столько из-за непоняток со стандартом, скорее из-за проблем с реализацией (и тут у режима проблемы).


В текущем стареньком ядре Debian-squeeze (2.6-32) есть только XTS-plain. И только в следующей версии ядра есть поддержка XTS-64. По стойкости эти режимы не отличаются, но первым из них нельзя зашифровать раздел больше 2 Tb. Надо будет позднее переходить на второй, но тут сюрприз – они между собой не совместимы по расчёту векторов и есть щанс не открыть контейнер. Ещё одна неприятность: при выборе другого шифра (не AES) – в режиме XTS всё внешне работает, но ядро пишет, что не может вычислить тестовые векторы. Так что лучше использовать только AES-XTS-plain. И только для свопа.


Если настраивается шифрование для свопа, все эти непонятки с XTS не существенны и его выбор оптимален. Но для шифрования долговременно хранимых данных лучше на ближайшие годы воздержаться от использования XTS в Linux. По крайней мере следует узнать, будет ли ваш дистрибутив рекомендовать его как стабильный.


Для щифрования разделов с данными пока есть смысл оставаться на режиме CBC-ESSIV. Он хотя и не создавался известными криптографами, но исторически подтвердил свою стойкость и возможность защититы от атак, действовавших против простого CBC (watermarking-атаки). CBC-ESSIV создан по принципу неэкономного, но надёжного решения (использования хэшей совместно с блочным шифром), не содержит фич XTS, с которыми не придётся скорее всего столкнуться обычным пользователям (шифрование блоков нестандартного размера в нём невозможно). Но он стабилен, прост, проверенно работает на выбор со всеми шифрами, не требует двойного ключа.
Разработчики Debian рекомендуют пока его и не торопяться внедрять XTS в дефолтные настройки.


Настройки системы, которые даны выше, достаточно проделать один раз. Затем нужно из консоли только запускать hibernate-disk (или аналогичную команду) или готовую кнопку в KDE (или в чём-там) нажимать. Всё будет уходить в hibernate на шифрованном своп разделе.


Скриптами можно только повторять это всё, когда периодически нужно прочистить этот своп, чтобы в нём слишком много чувтвительной информации от предыдущих сеансов не оставалось и не накапливалось ошибок.


Насчёт “больше не понадобиться никаких настроек” верно подметили корявость описания. Это два разных варианта.


Если вам нравится именно вариант “шифрованный физический том для всей системы, а на нём логический том со свопом”, то тогда да, “больше не понадобиться никаких настроек”, в смысле, что эти рекомендации можно дальше вообще не читать. Это уже самый простой рабочий вариант защищённого свопа для hibernate (и даже рекомендуемый разработчиками Debian, его можно и поставить из инсталлера по умолчанию), но там свои минусы. Не всегда удобно пользоваться таким LVM-ом. И то что своп внутри него всегда лежит открытый и накапливает данные – не очень хорошо. Нет гибкости в выборе Perfect Forward Security – возможности быстрой смены ключей на случай возможной будущей компрометации для свопа. И другие разделы все будут внутри открытые. Всё на одном пароле. Нет, можно дважды зашифровать: внутри физического тома ещё и логические – это хорошо рекомендовать красноглазым параноикам. Но придётся минимум дважды вводить пароль при загрузке, имея шанс, что система это когда-нибудь не поймёт после апдейта, запутается в стартовых скриптах и доступ будет потерян. Естественно не навсегда: можно будет примонтировать шифрованные LVM послойно и вручную всё открыть.


Рекомендации рассчитаны на тех, кто понимает, хотя бы как точно работает шифрованная система в “изкоробочной” настройке и все преимущества/недостатки разных конфигураций LVM и шифрования, прежде чем лезть туда напильником.

— Гость (24/12/2012 19:49)   <#>
А куда записывается информация для пробуждения от хибернации, и какое устройство потом её читает? Если на жёсткий диск, то как адресуется это место. Железо ведь не работает с файловой системой, поэтому адресация видимо по номеру блока. Тогда пробуждение аналогично загрузке lilo – с нужного блока. Или используется установленный загрузчик типа grub и далее следует стандартный процесс загрузки с добавкой, которая восстанавливает сессию? У меня компьютер почему-то не переходит в спящий режим. Гаснет экран, но питание не отключается, на мышь и клавиатуру реакция отсутствует. Может быть из-за того что весь диск с системой зашифрован, а загрузчик с ядром на внешнем носителе.
— unknown (24/12/2012 20:25, исправлен 24/12/2012 20:33)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664

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


А для диска, да, вся система должна быть шифрована, также как и своп (информация записывается туда). Своп м.б. на отдельном разделе или томе или на логическом томе внутри физического. При этом возможна настройка двойного шифрования без потери стабильности и производительности.


Ещё хитрость — если гибернейтиться не нужно, а нужно выключиться, то перед выключением можно мгновенно стереть ключ из слотов шифрованного свопа (не тратя время на отсоединение свопа) и он продожит работать на старом ключе, который останется только в памяти до окончания работы. Таким образом в свопе не будут накапливаться критичные данные, его можно использовать только периодически.


На нешифрованном /boot разделе (при желании на съёмном носителе) лежит, помимо прочего, initrd, в котором всё может быть настроено "из коробки", но можно самому поковыряться. Сейчас не помню, там UID тома только для корня, а информация о свопе читается уже с него, или uid свопа тоже фигурирует.


М.б. дело и не в ваших настройках. Гибернейт может не работать с некоторым железом (в смысле, если оно новое по отношению к ядру системы), причём с похожими на ваши симптомы.

— Гость (24/12/2012 21:51)   <#>
Гибернейт может не работать с некоторым железом

Это легко проверить: достаточно посмотреть, работает ли ОС с хибернейтом в принципе, безо всякого шифрования.
— Гость (26/12/2012 00:52)   <#>
гибернейт в память

По традиции он называется суспендом, он ничуть не более опасен, чем просто включённый компьютер. Хибернейт же может быть реально опасен, т.к. при неправильной его организации ключ шифрования может осесть в свопе или ещё где-то.
— Гость (26/12/2012 10:11)   <#>
На нешифрованном /boot разделе (при желании на съёмном носителе) лежит, помимо прочего, initrd

Понятно, нужен был внешний носитель с загрузочной информацией. После этого возник вопрос – не могла ли эта неудачная потытка хибернейта оставить следы на дисках. В системном блоке было два полностью зашифрованных диска, один чистый (без файловой системы), один внешний зашифрованный. Т.е. незашифрованные файловые системы отсутствуют. Не мог ли хибернейт наследить?

Вообще, склоняюсь к мысли что этот hibernate ненужная и опасная свистелка даже для ноутбуков, где нужно экономить питание. Достаточно суспенда, когда активна только память имеющая малое энергопотребление. Для обычных ПК в хибернейте вообще смысла нет. Да и своп в настоящее время практически не нужен. У меня он подключен как обычный файл внутри зашифрованной ОС, и почти никогда не используется.
— Гость (26/12/2012 10:14)   <#>
Опечатка: s/ОС/ФС/
— unknown (26/12/2012 11:12, исправлен 26/12/2012 11:17)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664
Т.е. незашифрованные файловые системы отсутствуют. Не мог ли хибернейт наследить?

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



Только для гибернейта он и нужен. Случаи экзотических вычислений с гигабайтами памяти не рассматриваем.



Вы просто не умеете правильно его готовить
Видимо, пока не напишу статью, как его правильно настраивать, то для большинства он таким и останется :)


Вот если открыто и настроено на работу куча программ, прерывать их можно, а выключать нежелательно.
На отвлечение на телефонный звонок или уход пообедать будете скринсейвером пользоваться? Или суспендом? Лень и беспечность ведь победят параноидальность в один неподходящий момент, лучше иметь на такой случай компромиссное по безопасности решение в запасе. Причём загружаться можно будет на выбор — с отключенным свопом или нет. А подключать моментом, только если надо сгибернейтиться. Всё автоматизировать и повесить на хоткеи.

— Гость (26/12/2012 13:37)   <#>
А какой программой можно шифровать своп в Винде? платную знаю, а вот opensource нет.
На страницу: 1, 2 След.
Ваша оценка документа [показать результаты]
-3-2-1 0+1+2+3