Доступ к LUKS разделу GNU/Linux-а... просто зажав Enter

https://www.opennet.ru/opennews/art.shtml?num=59702
Ага, вот так вот просто (почти) зажав Enter, можно не то что обойти ввод
пароля, но и вообще получить доступ к дешифрованному разделу LUKS. Но
для этого надо использовать ключ в TPM. Вот именно из-за подобных
инцидентов я не доверяю никаких криптотокенам/ключам/TPM/etc -- если я
чётко знаю что *я* должен ввести ключевой материал, то это я понимаю,
могу прикидывать риски и доверять так или иначе. А если это чёрный ящик,
где я, будучи не НИИ/НТЦ/ФСБ, не могу ничего проверить или узнать, то не
могу этому доверять. Безусловно никто не отменяет keylogger и прочие
штуки, но уж просто зажав Enter получить доступ к шифрованной информации
(грубо говоря)... это как-то уж совсем ни в какие ворота.

комментарий 0:

From: kmeaw
Date: 2023-09-03 00:37:37Z

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

Это обычный баг в early userspace, где программист допустил по крайней
мере две ошибки:

1) не затёр регистры измерений перед тем, как дать пользователю
отладочный шелл;

2) запустил параллельные процессы (автоматическую разблокировку и
ручную) там, где этого не нужно - достаточно было бы fallback на ввод
аварийной парольной фразы вручную только тогда, когда автоматика
сломалась.

комментарий 1:

From: Sergey Matveev
Date: 2023-09-03 07:04:24Z

*** kmeaw [2023-09-03 01:37]:
>Но ведь в описанной уязвимости никак не используются доверие
>пользователя к TPM.

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