>> А функциональность мутного чипа в результате какая? А, атакующему ключ выдать нахаляву?
> б-ть, НЕТ - он его выдает твоему т-пому рукoжопoму опенсорсному г-ну, Ну как бы фэйл в том что он нахаляву атакующему подмахивает - и вообще не важно чему и почему. А init=/bin/bash можно так то и без всяких системд вкатить и ввалиться в этот ваш рамдиск без спроса всяких козлов так то.
В результате смысл в аппаратном чипе с ТАКОЙ реализацией вызывает определенные вопросы. С таким же успехом можно было ключ шифрования из файлика шифровать, результат будет примерно такой же.
> причем так что перехватить его нельзя, причем именно тому конкретному на который
> настроен - потому что именно так это должно работать.
Ну как бы цель и не ключ а данные на диске. А "перехватить нельзя" - булшит, имея права рута будет примерно 9000 способов узнать о ядре и его внутренностях все что вы хотели узнать но боялись спросить. Вплоть до последних битов любых ключей, диск оно ж шифрует значит и все ключи для этого в раме висят. Конечно есть такая штука как Lockdown и там рута с доступом в именно физические адреса могут и послать, но врядли ты с ним работаешь, разве что тебе OEM на мобилке вкатил такой подарок - защищая СВОЙ девайс, от ТЕБЯ. Но это пока WIP и не массово.
> А вот это самое г-но - ОБЯЗАНО было по спецификации проверять, можно
> тут спросить ключ у TPM или надо спрашивать пароль с клавиатуры
> - но - обоcpaлось, потому что оно - т-пое рукожoпoe опенсорсное г-но.
Как по мне - там вся идея на автомате получить ключ из чипака в софт и пустить кого попало - лютое УГ. Это типа автологина в систему, только еще хуже, потому что там хотя-бы не претендовали на то что это "секурно" и ложных ожиданий у хомяка не было. А тут хомяк еще и залетит когда его файло попадет кому-то не тому.
