Pull to refresh

Comments 23

Чем плохо использовать только BitLocker?
Лично для меня это означало бы необходимость апгрейда с Windows 7 Professional до Ultimate. Поэтому я его не рассматривал, и особо ничего рассказать про него не могу. Может, кто другой напишет.
Можно и его. Я пользовался некоторое время.
При шифровании диска с ОС — нам будут доступны варианты или использовать ТРМ или пароль. Дли всех остальных дисков можно использовать также и сертификат.
Минусом будет то что, битлокеру придется зашифровать все данные уже имеющееся на диске.
Кстати в Win8.1 Pro BitLocker уже был доступен.
Например, BitLocker не может использовать аппаратное шифрование с NVME-накопителями.
Samsung EVO или PRO всегда хранит данные в зашифрованном (AES) виде
Уже это утверждение в случае проприетарной реализации шифрования может (и должно) быть подвергнуто сомнению. Лично у меня к проприетарному шифрованию отношение простое: исходим из того, что его нет, и там обычный XOR, как в той истории.
UFO just landed and posted this here
ранше было так — физический доступ = ПОЛНЫЙ доступ, сейчас не всё так однозначно…
В целом на винде и яблоке шифрования нет, ни в каком виде, так чтобы ему можно было хоть чуточку доверять.

Если опустить либребут и «небезопастность х86», чем вас не устраивает шифрование на макинтошах?
Можно примеры примеры исследований которые могут обосновать ваше заявление?
Если так беспокоиться о шифровании, можно использовать, например, VeraCrypt (форк TrueCrypt). Утилита умеет шифровать системный диск и также спрашивать пароль при загрузке… Причем мало того, можно даже создать скрытую ОС, о наличии которой ничего явно не свидетельствует, на случай, если человек будет паяльником выпытывать пароль у владельца диска :)

Процесс шифрования, при наличии поддержки AES процессором — почти не влияет на скорость общения с диском.
Вы правы. Но статья не о том, как правильно зашифровать данные, а скорее из разряда: «Вот прикупил себе SSD. Чего это у него там такое? Встроенное шифрование? А как его включить? В инструкции нет ничего. Это что же, я за это заплатил, а оно лежит мёртвым грузом и не работает? Непорядок!».
По крайней мере, у меня это так было.
От встроенного шифрования мне, например, достаточно хотя бы возможности (почти) мгновенного форматирования SSD диска — достаточно удалить из памяти ключ и все, по сути, данные бесполезны.

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

Тут я бы поспорил. При использовании NVME-накопителя — очень влияет:
https://github.com/veracrypt/VeraCrypt/issues/136
Судя по ссылке, проблема специфична для TrueCrypt/VeraCrypt, раз DiskCryptor показывает производительность сопоставимую с производительностью незашифрованного диска.
Спасибо за статью! Как завадался вопросом для ноута-параноика.
Рад, если смог помочь.
Не могу отделаться от ощущения, что вы уже начали шифровать («как завадался...»).
На линуксах все намного проще. Есть софтовое luks шифрование (доступно из коробки без красноглазия на дебианоподобных дистрибутивах). Отъедает процентов 20 производительности, но работает как часы.
1. Проприетарному шированию нет доверия по определению — его невозможно проверить.
2. Прежде чем выбирать метод и инструмент сокрытия данных, стоит описать модель угроз.
3. Касательно надёжного шифрования:
— в GNU/Linux имеет штатный cryptsetup с вариантами dm-crypt, loop AES и (мейнстримовым) LUKS;
— в Windows есть несколько опенсурсных вариантов, Википедия в помощь.
В обоих ОС при этом возможно шифрование загрузочного раздела.
Комментарий заминусовали, но, как ни странно, человек оказался прав…

Очередная «история дня», связанная с фейлом в шифровании, в этот раз — в SSD-дисках. Исследователи университета Radboud в Нидерландах сообщили об обнаруженных уязвимостях в некоторых дисках SSD, которые позволяют обойти функцию шифрования диска и получилось доступ к данным на диске без использования пароля для расшифровки данных. Уязвимость затрагивает только те SSD-модели, поддерживающие аппаратное шифрование, где функции шифрования перенесены в отдельный встроенный чип, отдельный от главного процессора (модели Samsung, Crucial). Проблема заключается в кривой реализации спецификаций ATA Security и TCG Opal по внедрению аппаратного шифрования в самошифрующихся дисках.

Полный отчет можно получить тут (PDF), но вот из него сразу список некоторых затронутых моделей дисков:

image

(это только те, что были протестированы в рамках исследования)

К сожалению, ситуация становится хуже для пользователей Windows, использующих систему шифрования BitLocker — программного шифрования, встроенного в Windows. BitLocker устроен таким образом, что когда BitLocker обнаруживает аппаратное шифрование, то он говорит «а, ну тут все норм, я пошел», оставляя шифрование на усмотрение самого устройства. Собственно, это означает, что, с учетом всех этих обнаруженных уязвимостей в уже указанных дисках Samsung и Crucial (а также во множестве еще неизвестных моделей с кривой реализацией ATA Security и TCG Opal). Групповой политикой BitLocker можно заставить шифровать данные и программным методом, но это требует переформатирования дисков. Исследователи в своем отчете также рекомендуют использовать VeraCrypt вместо аппаратного шифрования.
Три важных момента:

— во-первых, не поддерживается Secure Boot
— во-вторых, работа sedutil-cli с NVME-дисками из Windows пока невозможна, лучше воспользоваться для этой цели Rescue disk (той самой флешкой).
— во-третьих, разблокированный диск сохраняется разблокированным, пока на него подаётся питание. Это значит, что если вы увидели, как падает входная дверь и нажали Reset на системнике — это вам не поможет (нужно именно завершить работу системы или банально выдернуть питание). В отличие от традиционного шифрования. Конечно, не смертельно: чаще технику сначала отключают и изымают, а уже потом начинают в ней копаться, но всё же… И если с десктопом ещё можно придумать всякое (скажем, повесить сетевой фильтр сбоку стола, чтобы лёгким движением руки обесточить хозяйство), то вот быстро отключить питание ноутбука уже не так просто.

Небольшой обзор средств для шифрования системы:
  • LUKS: открытый код, программное шифрование, уже есть в ядре Linux, скотчем и костылями можно прикрутить поддержку TPM, если подписать ядро, то можно и SecureBoot завести
  • BitLocker: проприетарный, программное шифрование, аппаратное — лишь на совместимых со стандартом eDrive дисках, встроен в Windows (умеет автоматически приостанавливаться и возобновляться до и после крупных обновлений системы), поддержка TPM «из коробки», большинство настроек только через политики/реестр (тот же TPM, дополнительный PIN-код в виде второго фактора, его сложность, размер ключа шифрования и т.п)
  • VeraCrypt: открытый код, программное шифрование, кросплатформенность, не умеет шифровать систему под Linux, не умеет работать с TPM, поддерживает SecureBoot, драматически снижает скорость работы NVME-накопителей, умеет обновлять Windows без полной расшифровки
  • DiskCryptor: открытый код, программное шифрование (но быстрое), заточен под Windows, не поддерживает даже GPT-диски (следовательно требует плясок с бубном в виде включения CSM и конвертации дисков в MBR, SecureBoot, разумеется, в пролёте), для обновления Windows придётся полностью расшифровывать систему
  • sedutil: аппаратное шифрование со всеми плюсами (работает прозрачно для операционной системы, не нагружает процессор) и минусами (мы полагаемся на проприетарную прошивку накопителя), не поддерживает SecureBoot
> — во-первых, не поддерживается Secure Boot
С чего бы это? Почему у меня работало? Пароль же от диска спрашивает еще до POST.

Пароль же от диска спрашивает еще до POST.

sedutil? Нет, после POST. Он отрабатывает вместо загрузчика ОС, расшифровывает накопитель и перезагружает систему, чтобы с расшифрованного накопителя стартовал родной загрузчик ОС.

SecureBoot «из коробки» в sedutil не поддерживается. Нужно распаковывать образ и подписывать bootx64.efi самостоятельно.

Кроме того, нет поддержки TPM. Её пытались прикрутить, но патчи уже протухли. не то, чтобы TPM сильно помогал, но слегка затруднить атакующему жизнь он способен (и поднимет тревогу при измении прошивки).
ниже ответил (не туда написал)
> sedutil? Нет, после POST. Он отрабатывает вместо загрузчика ОС, расшифровывает накопитель и перезагружает систему, чтобы с расшифрованного накопителя стартовал родной загрузчик ОС.
Не очень хорошо во всем этом разбираюсь, но пароль от диска у меня запрашивает ДО выхлопа POST. Ноут Thinkpad P50s, диск SanDisk X400 (хотя это не имеет значения, я полагаю).

Когда прошлый раз ставил систему при установке создался дополнительный диск FAT32 который назывался efi-boot или что-то такое. Недавно переустанавливал и установилось без SecureBoot, не знаю почему. Предполагаю что что-то я не то включил в Bios.

Но это все лирика — пароль у меня запрашивается до вывода вообще какой либо инфы в том числе и POST. Если не ввести в течении какого-то времени (думаю секунд 10) то ноут вообще вырубается.
Вероятно, какие-то заморочки мобильной платформы…

На десктопе (Sunrise Point, если важно) сначала проходит POST/вход в BIOS/выбор загрузочного накопителя (вся эта стандартная рутина с «нажмите Del для входа в настройки, F8 для выбора загрузочного устройства»), а потом уже расшифровка.
Sign up to leave a comment.

Articles