Comments 33
Хм… по-моему это не баг, а фича… очень гуманная фича.
BitLocker требует от накопителя не упомянутого в статье Opal, а eDrive, стандарта, продвигаемого Microsoft.
Например, NVME-накопители Samsung поддерживают Opal, но BitLocker на них использует программное шифрование, поскольку спецификацию eDrive, насколько мне известно, Microsoft не адаптировала к NVME.
Впрочем, добиться работы накопителей с поддержкой Opal в среде Windows возможно (но BitLocker в этом участия не принимает).
Например, NVME-накопители Samsung поддерживают Opal, но BitLocker на них использует программное шифрование, поскольку спецификацию eDrive, насколько мне известно, Microsoft не адаптировала к NVME.
Впрочем, добиться работы накопителей с поддержкой Opal в среде Windows возможно (но BitLocker в этом участия не принимает).
Главная проблема в том, что кроме паролей доступа, которые задают владельцы SSD, есть еще и мастер-пароль, который задается на фабрикеВ принципе не понимаю, как можно доверять устройствам, у которых есть какой-то «мастер-пароль, задаваемый на фабрике». Это же абсурд.
Вы наверное немного перепутали. Мастер-пароль присутствует в спецификации ATA Security. Раньше (и сейчас) эта фича была не для шифрования диска, а скорее как аналог пароля на биос, так, от любопытных глаз. В спецификации TCG Opal конечно мастер-пароля уже нет.
Но что-то там всё-таки можно напортачить, раз в таблице статьи Crucial не прошли проверку TCG Opal (3 колонка).
У тех, кто некорректно реализовал Opal, пароль, вводимый пользователем, не связан с ключом шифрования, насколько я понимаю.
Если сильно упрощённо:
При нормальной реализации пароль используется для расшифровки ключа, а уже ключом расшифровывается содержимое накопителя. Таким образом, не зная пароль (хранящийся в мозгах пользователя), не получится заполучить ключ шифрования (если пароль хороший, стойкий).
А у Crucial ключ шифрования никак не связан с паролем, который вводит пользователь. Решение о том, правильный ли введён пароль, принимает не бесстрастная «криптография» (как было бы, если бы ключ был сгенерирован на основе пароля), а контроллер. Таким образом, этот этап можно обойти, вскрыв контроллер и «вытащив» из него ничем не защищённый ключ + зашифрованные данные. И спокойно расшифровать их этим ключом.
Защита получается намного слабее. В первом случае её не сможет вскрыть условное ФБР (если не выбьет из пользователя пароль), а во втором случае — сможет, без всякого взаимодействия с пользователем.
Если сильно упрощённо:
При нормальной реализации пароль используется для расшифровки ключа, а уже ключом расшифровывается содержимое накопителя. Таким образом, не зная пароль (хранящийся в мозгах пользователя), не получится заполучить ключ шифрования (если пароль хороший, стойкий).
А у Crucial ключ шифрования никак не связан с паролем, который вводит пользователь. Решение о том, правильный ли введён пароль, принимает не бесстрастная «криптография» (как было бы, если бы ключ был сгенерирован на основе пароля), а контроллер. Таким образом, этот этап можно обойти, вскрыв контроллер и «вытащив» из него ничем не защищённый ключ + зашифрованные данные. И спокойно расшифровать их этим ключом.
Защита получается намного слабее. В первом случае её не сможет вскрыть условное ФБР (если не выбьет из пользователя пароль), а во втором случае — сможет, без всякого взаимодействия с пользователем.
Кому лень читать отчёт, рассказываю в двух словах, что сделали пацаны. Подключились через JTAG к контроллеру, поправили в его ОЗУ процедуру, проверяющую пароли, так, чтобы подходил любой пароль. Так как задаваемый пользователем пароль никак не связан с ключом шифрования диска (DEK), то такая модификация процедуры аутентификации делает данные на диске доступными через обычный интерфейс.
То, что пароль никак не связан с шифрованием — это баг в голове у тех, кто принял решение реализовать шифрование диска таким способом.
Всё просто — пользователь не сможет сменить пароль при таком раскладе. Тут и иллюзия безопасности (шифровано же) и удобство (можно сменить пароль, не перешифровывая диск).
UFO just landed and posted this here
А теперь представим, что все сделано как надо. Что в таком случае будет, если юзер — та-да-а! — забыл пароль?
Дается допустим 5 попыток, если все неправильные — генерируется новый мастер-ключ, старые данные по сути перестают быть доступными и стираются.
Вопрос в том, что главней — данные пользователя, или конфиденциальность. В первом случае это неудачное решение.
По уму шифрование диска — это конфиденциальность. Если пользователю важны данные — нужно делать бекапы, а не возможность их восстановления с «зашифрованного» диска.
Впрочем, да, «простому смертному юзверю» шифрованный диск и не нужен.
Впрочем, да, «простому смертному юзверю» шифрованный диск и не нужен.
Простые смертные, у которых на компах куча личной инфы (плюс возможно пароли к сайтам-банкам-etc) вряд-ли будут рады, если всё это будет легко доступно вору, который украл комп. Точно также родители вряд-ли будут рады если их развитые детки покопаются в их компах (или наоборот).
Так что, всё же, шифрование диска имеет смысл и для «простых смертных», или, говоря другими словами — если на компе есть хоть один файл, утечка которого нежелательна (хотя и не смертельна) — то это уже достаточное основание для шифрования.
Вопрос в том, что главней — данные пользователя, или конфиденциальность
Это уже проблема выбора пользователя — пусть в настройках выбирает.
Я не разработчик, но разве в этом случае пользователь не обязан отказаться от шифрования, если считает свою забывчивость слишком значительной? Мне казалось, что достижение конфиденциальности неотрывно от возникающего риска полной утери данных в случаях амнезии/склероза и т.д.
Юзер восстановит данные из бекапов. (бекапов, ха-ха-ха)
А в чем проблема? Сделать бэкап сейчас можно одной кнопкой. И восстановить тоже одной кнопкой. Оставаясь юзером.
Дело не в сложности реализации, а в том, что обычно люди (причем и простые юзеры и даже админы иногда) вообще не думают о бэкапах в принципе. Отчасти поэтому облака так популярны — пользователь зачастую вообще не думает, что его данные хранятся где-то вне устройства, и испытывает огромную радость, когда устройство умирает, а данные оказываются целыми. Хотя вроде бы что сложного в том, чтобы вечером подключать телефон, например, к компу и сливать копии данных.
А что будет если юзер — та-да-а и сам удалит свои файлы, или уронит диск или сделает еще какую-нибудь глупость?
Пусть запишет пароль на бумажке и положит в сейф. Пусть делает периодически бэкапы на другой диск, который сдает в банковскую ячейку.
Собственно зачем покупать и пользоваться КОММЕРЧЕСКИМ продуктом для шифрования, если он будет предоставлять всего лишь иллюзию безопасности?
Пусть запишет пароль на бумажке и положит в сейф. Пусть делает периодически бэкапы на другой диск, который сдает в банковскую ячейку.
Собственно зачем покупать и пользоваться КОММЕРЧЕСКИМ продуктом для шифрования, если он будет предоставлять всего лишь иллюзию безопасности?
Согласен со способом, JTAG не отключали примерно те же люди, потому не удивительно.
Оно не шифровано. Чтобы было шифровано, сами данные должны быть изменены. И если производитель говорит «шифровано», а на самом деле нет, это наглый обман, и за это должна быть серьёзная ответственность.
Если пользователю нужна лишь иллюзия безопасности, зачем ему вообще шифровать диск? Пусть просто пароль на вход в систему поставит и достаточно.
Там случайно DEK не один для всех дисков серии?
Если к диску можно просто так подключиться по JTAG и править в ОЗУ процедуры, то даже если DEK зависит от пароля, то можно отключить максимальное кол-во попыток и брутфорсом подобрать пароль. Я правильно понимаю? Это же бред какой то получается, защита от дурака.
Никогда такого не было, и вот опять…
вот ведь молодцы, независимое от пароля шифрование реализовали, это даже веселее, чем парольные хэши без соли.
xor ещё можно для «шифрования» использовать, эффект примерно тот же.
xor ещё можно для «шифрования» использовать, эффект примерно тот же.
ATA-пароли и не позиционировались как надёжное средство защиты, сама спецификация очень древняя. Другое дело TCG Opal, там при правильной реализации можно на что-то рассчитывать. Но всё равно мы как потребители не можем проверить, есть ли там аппаратные закладки, поэтому самым надёжным будет софтовое шифрование с открытыми исходниками.
Подход к реализации опции плавно перетёк с флешек.
Sign up to leave a comment.
Уязвимости SSD с аппаратным шифрованием позволяют злоумышленникам легко обходить защитные меры