Self Encrypting Drives - Chain load OS

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

Да.

В ходе эксперимента, сделал и такое.

Что да как восстановить???

Восстанови из бекапа.

Не совсем по теме топика.

Бывает.

Как-то сложно всё это. «Passphrase вводится» под чутким руководством майора, стоящего с паяльником за спиной.

Лучше уж на уровне ОС всё это шифрануть, и что бы загрузчик с ядром находились где-то во вне на microSD-шке, которую можно в анусе перевозить. А ноут, ну да просто чистый ноут, товарищ майор! Там ничего нет!

Да и полагаться на крипту от производителя SSD? Там мож закладка. Или унылые баги, которые всё раскодируют по пассфразе 123.

Вы таки правы. Отчасти.

Версия о майере нас не интересует и не актуально - это раз.

Дырка в UEFI/BIOS производителя компа?

Через сутки, никто с ним не станет иметь дела на рынке - суть два.

Через сутки, никто с ним не станет иметь дела на рынке - суть два.

Ага, расскажи нам про рынок в свете всех этих Intel/ME, meltdown-ами и прочими даунами. Тото я вижу рыночек порешал и все перестали штеуд покупать.

На это вам сообщу - никто вам не запрещает противостоять им.

Как - учимся вместе!

Неужели никто не заинтересован в защите своих данных?

Неужели?

вводится и загружается busybox-linux, показывая все партиция SSD

Загружается, я так понимаю, из initrd? А чем ты его создаёшь (в рачике же должны быть нормальные средства генерации инитрд, с которыми будет грузиться сам)? В общем, его и настраивай, чтобы после ввода пароля он монтировал нужные ФС и передавал управление иниту.

А вообще, имхо, выше правильно написано - дурью не майся и шифруй на уровне ОС, благо aes-ni в каждом калькуляторе

Эта задача не столь однозначна. Или так видится моей башне.

С одной стороны, набор sedutil-cli и pre-boot authentication построен на использовании initrd с syslinux. syslinux quite happy загружается с fat partition но по спецификации своей - не умеет загружать партицию f2fs.

С другой стороны, f2fs имеет инструментарий для нативного шифрования out-of-the-box.

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

Мерси за ваше видение проблемы.

Я был заинтересован, но отказался в пользу программного шифрования. Потому что при аппаратном диск остаётся расшифрованным, пока поступает питание.

То есть, ты отошёл открыть дверь, но заблокировал сеанс ОС. Тебя приняли в коридоре. Воткнули флешку с Live-дистрибутивом, перезагрузили комп (банально кнопкой Reset). Питание не прерывалось, твой накопитель остался разблокированным.

Добавлю: к тому же, sedutil не умеет работать с TPM. Есть патчи, обучающие его этому, но они уже протухли и надо сидеть разбираться, как их применить к актуальной кодовой базе.

А вот завести LUKS с TPM - можно. Как и VeraCrypt и даже, прости господи, BitLocker.

TMP позволяет защититься от изменения прошивки, от смены ключей SecureBoot, много от чего, зависит от того, к каким регистрам (PCR) привяжешь:

PCR 0: Исполняемый код базового системного встроенного ПО PCR 2: Расширенный или подключаемый исполняемый код PCR 3: Расширенные или подключаемые данные встроенного ПО PCR 4: Диспетчер загрузки PCR 5: GPT/Таблица разделов PCR 6: Возобновить из событий состояния питания S4 и S5 PCR 7: Состояние защищенной загрузки PCR 12: События, инициируемые изменением данных, и крайне переменные события

То есть, как только вражина попытается выключить SecureBoot (надеюсь, у тебя там прописаны твои собственные ключи и удалены стандартные, чтобы никто не мог загрузиться с обычного Live-дистрибутива Linux/Windows, где загрузчик подписан ключом Microsoft) или снять копию с накопителя, подключив его к другой системе - он обломится.

А на стороне sedutil - аппаратное шифрование и всё. Ну оно чуть побыстрее, да. Но проприетарное. И вон у Crucial нашли эпичный баг в прошивках SSD, когда ключ шифрования данных не был связан с твоим паролем. То есть, вопросом «правильный ли пароль» заведовала прошивка, а не криптография.

За что забанили-то хоть?

Ссаными тряпками блица погнали с форума.

За то, что регистранты не нужны.

https://www.ru.nl/publish/pages/909275/draft-paper_1.pdf

An overview of possible flaws in hardware-based full-disk encryption was given. We have analyzed the hardware fulldisk encryption of several SSDs by reverse engineering their firmware, with focus on these flaws. The analysis uncovers a pattern of critical issues across vendors. For multiple models, it is possible to bypass the encryption entirely, allowing for a complete recovery of the data without any knowledge of passwords or keys.

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

То есть, мы, атакуюя, вскрываем накопитель, считываем этот ключ напрямую и нам плевать на пароль пользователя.

Это дырень. Ключ шифрования данных должен формироваться с участием пароля. Чтобы нельзя было его получить, если не знаешь пароль.

Мдя, там даже всё ещё хуже бывает:

Furthermore, we found that a vendor-specific command allow for arbitrary modifications within the address space. This
enables malware with remote access to the host PC to infect
the drive’s firmware, allowing it to hide itself and/or to survive re-installation of the host PC’s OS.

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