Правильно ли настроен SecureBoot с использованием собственных ключей?
По вводным: на 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?
Опишите проблему, и специалист поможет с настройкой, исправлением ошибки или доработкой сайта. Подберём понятный план работ без лишней переписки.
Пока нет других ответов. Будьте первым, кто поможет автору.
Ответить на вопрос
Схема с собственными ключами Secure Boot в целом рабочая, но установка одного и того же сертификата в PK, KEK и db — не лучший вариант с точки зрения модели доверия. Технически это может работать: UEFI принимает подписи, UKI грузится, неподписанные EFI не запускаются. Но PK, KEK и db имеют разные роли, и лучше разделять их ключи.
Кратко по ролям: PK владеет платформой и позволяет менять KEK; KEK позволяет обновлять базы db/dbx; db содержит ключи, которыми подписаны загрузчики/UKI. Если один ключ используется везде, компрометация этого ключа дает слишком много возможностей. Для домашней машины это может быть приемлемо, но для аккуратной настройки лучше сделать отдельные ключи.
Цель “не дать модифицировать загрузочные файлы человеку с физическим доступом” достигается только частично. Secure Boot проверяет подпись загрузочной цепочки, но не защищает данные на диске. Если root-раздел не зашифрован, злоумышленник может читать/менять файлы системы, подменять конфиги, добавлять unit-файлы или менять initramfs до следующей сборки. Поэтому Secure Boot нужно сочетать с шифрованием диска и защитой доступа к UEFI Setup.
Минимальный нормальный набор:
Также не забывайте про dbx: если вы полностью удалили vendor keys, часть штатных загрузчиков и recovery-сценариев перестанет работать. Это нормально, если вы осознанно строите свою цепочку, но обязательно храните копии ключей и EFI Shell/LiveUSB, подписанные вашим ключом. Иначе при ошибке в сборке UKI можно получить систему, которая сама себя не загрузит.
Итог: “правильно” в базовом смысле — да, если грузятся только подписанные EFI. “Правильно” в безопасной архитектуре — лучше разделить ключи, добавить LUKS, закрыть UEFI и проверить сценарий восстановления.