Корректно ли настроен SecureBoot с использованием собственных ключей?

Question

[questioner2]

На Debian 13 сгенерировал ключ и сертификат, сертификат сконвертировал в .der формат, ключом подписал UKI образ:

ukify genkey --secureboot-private-key=secureboot-private-key.key --secureboot-certificate=secureboot-certificate.crt
openssl x509 -in secureboot-certificate.crt -outform DER -out secureboot-certificate.crt.der
ukify build --secureboot-private-key=secureboot-private-key.key --secureboot-certificate=secureboot-certificate.crt --linux "$KERNEL" --initrd "$INITRD" --cmdline="$CMDLINE"

Зашёл в BIOS Setup, удалил существующие SecureBoot ключи, установил .der сертификат в качестве PK, KEK и db. Проверил, всё работает - грузятся только .efi, подписанные моим сгенерированным ключом.

Цель настройки SecureBoot: не дать модифицировать загрузочные файлы злоумышленнику, имеющему физический доступ к устройству.
Система установлена на зашифрованный раздел, за исключением efi раздела, и на UEFI установлен сложный пароль. При этом не рассматриваем ситуацию, когда злоумышленник может модифицировать память NVRAM.

Как использование одного и того же ключа для PK, KEK и db повлияет на безопасность настройки SecureBoot?

Comments

[Дмитрий]

Как использование одного и того же ключа для PK, KEK и db повлияет на безопасность настройки SecureBoot?

напрямую.
Один и тот же ключ — одна точка отказа.
Если он утечёт — система открыта, заходи, подписывай свой руткит, делай что угодно.
Для этого и делают иерархию доверия.
Ключи для подписывания и администрирования должны быть разные в идеале.
Если ключ на оффлайн токене, а токен спрятан в яйце, то проблем никаких. Но как только утечёт приватник,то у злоумышленника полный контроль.

[questioner2]

Дмитрий, зачем разделять точки отказа в выбранной мною схеме? В любом случае хоть один ключ должен быть доступен руту для автоматического подписывания uki образов при обновлениях. И в любом случае на фоне компрометации рута становится мало смысла в защите загрузки от буткитов.

На каждом устройстве свой отдельный PK, чтоб компрометация одного из них не влияла на остальные.

[questioner2]

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

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