The secure boot key database is empty: Resetting all Secure Boot certificate keys to platform defaults

uefi — Безопасная загрузка — Как добавить пользовательский сертификат в базу данных, если в BIOS нет такой опции?

спросил

Изменено
1 год, 4 месяца назад

Просмотрено
2к раз

У меня ноутбук HP 245G7. BIOS очень простой, и, похоже, внутри нет возможности добавить мой собственный сертификат в базу данных db для безопасной загрузки.

Если есть опция в этой модели, хотелось бы узнать.

Где-то читал, что такая опция есть только у бизнес-ноутбуков HP. Когда я звоню в службу поддержки HP, они говорят, что HP245G7 — это бизнес-ноутбук.
Учитывая это и предполагая, что в BIOS нет такой опции, каковы альтернативы добавлению моего собственного сертификата (файл .cer) в базу данных db?

Сертификат создается в Windows с помощью команды powershell New-SelfSignedCertificate

  • uefi

    • 9сертификат 0021

  • безопасная загрузка

4

Все микропрограммы технически делают это возможным, у них просто может не быть простого пользовательского интерфейса для этого на экране настройки, требуя, чтобы вы прошли долгий путь, создав ESL самостоятельно в режиме настройки, но этот режим должен быть доступен на х86.

Я постараюсь рассказать об этом позже, но в целом вам следует:

  1. Переключите функцию безопасной загрузки в «Режим настройки». Это может быть сделано в качестве специальной опции или путем очистки ключа платформы (PK) через прошивку.

    Когда система находится в режиме настройки, вы сможете обновить db и KEK из работающей ОС без необходимости секретного ключа, соответствующего KEK или PK. Например, для управления db можно использовать систему Linux или какой-либо инструмент, работающий из оболочки EFI.

    У меня есть свои заметки для системы Dell, где мне пришлось сделать это в два отдельных шага: сначала переключить систему в «Режим настройки» через настройки прошивки, затем загрузиться в Linux и вручную удалить содержимое PK .

     chattr -i /sys/firmware/efi/efivars/PK-8be4df61-93ca-11d2-aa0d-00e098032b8c
efi-updatevar -k PlatformKey.key -d 0 ПК

  2. Получите копии исходных списков db и KEK из переменных EFI «dbDefault» и «KEKDefault», которые требуются в реализациях безопасной загрузки.

    Примечание. В моих старых заметках для Dell говорится, что в этом нет необходимости, потому что у меня была конкретная опция для активации «Режима настройки» и мне не нужно было использовать опцию «Очистить все ключи» кувалдой, поэтому db и KEK сохранили свои первоначальные значения и Я мог бы просто добавить к ним.

    Однако, если вы в конечном итоге очищаете все ключи (что также приводит к режиму настройки из-за пустого PK), это остается полезной опцией.

  3. Создайте пользовательский список подписей (.esl) из dbDefault плюс свой пользовательский сертификат базы данных и добавьте его в переменную db . Аналогичным образом добавьте KEKDefault и свой собственный сертификат KEK в KEK .

    Что я нашел в своих заметках для создания этого значения, так это то, что cert-to-efi-sig-list и sign-efi-sig-list нужно использовать, с efi-updatevar затем импортировать ot.

    Однако также возможно добавлять сертификаты один за другим к существующему содержимому ‘db’ или ‘KEK’:

     chattr -i /sys/firmware/efi/efivars/KEK-8be4df61-93ca-11d2-aa0d-00e098032b8c
efi-updatevar -k MyPlatformKey. key -g 77fa9abd-0359-4d32-bd60-28f4e78f784b -a -c KEK/MS_KEK_CA_2011.der KEK
efi-updatevar -k MyPlatformKey.key -g $(uuidgen) -a -c MyKeyExchangeKey.crt KEK
chattr -i /sys/прошивка/efi/efivars/db-d719b2cb-3d3a-4596-a3bc-папа00e67656f
efi-updatevar -k MyKeyExchangeKey.key -a -c db/MS_UEFI_CA.der db
efi-updatevar -k MyKeyExchangeKey.key -a -c db/MS_Windows_PCA.der db
efi-updatevar -k MyKeyExchangeKey.key -a -c MySigningKey.crt БД

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

1

PowerShell можно использовать в Windows для управления сертификатами UEFI,
где BIOS не имеет необходимого пользовательского интерфейса.

В руководстве HP был найден следующий метод
Руководство по настройке безопасной загрузки.
Для этого необходимо, чтобы PowerShell был запущен от имени администратора.

Документ содержит чрезвычайно подробные описания PowerShell
команд и об использовании Windows signtool.exe для подготовки
ключи для установки.

Сам документ слишком объемный для включения в ответ.
Я только резюмирую ниже его главу 2 для необходимых шагов:

 2 Настройка индивидуальной среды безопасной загрузки
2.1 Резервное копирование существующей конфигурации безопасной загрузки
2.2 Переведите ПК HP в режим настройки безопасной загрузки
2.3 Получите открытые ключи PK и KEK
2.4 Самоподписывающиеся сертификаты
2.4.1 Создание нового ПК
2.4.2 Создание нового KEK
2.5 Установите новый ПК
2.5.1 PK: создайте допустимый пакет SetVariable()
2.5.2 Импорт PK с помощью инструментов Windows
2.6 Установите новый PK — подписанный KEK
2.6.1 KEK: Создайте допустимый пакет SetVariable()
2.6.2 Импорт KEK с помощью инструментов Windows
2.7 Установите новый подписанный KEK DB и DBX
2.8 Включите безопасную загрузку еще раз
2,9Добавьте дополнительные сертификаты в DB или DBX

3

Зарегистрируйтесь или войдите в систему

Зарегистрируйтесь с помощью Google

Зарегистрироваться через Facebook

Зарегистрируйтесь, используя адрес электронной почты и пароль

Опубликовать как гость

Электронная почта

Требуется, но не отображается

Опубликовать как гость

Электронная почта

Требуется, но не отображается

Нажимая «Опубликовать свой ответ», вы соглашаетесь с нашими условиями обслуживания, политикой конфиденциальности и политикой использования файлов cookie

.

Значение всех ключей UEFI

Введение

Спецификация UEFI (2.3.1c) определяет несколько хранилищ ключей и их форматы: ключ платформы (PK), ключ обмена ключами (KEK), базу данных ключей (db) и база данных запрещенных сигнатур (dbx). В этом посте описываются отношения между ними и то, как они реализованы в эталонной реализации Tianocore. Это означает, что не все возможное реализовано, потому что Tianocore строго следует требованиям сертификации оборудования Windows 8.

Безопасные переменные UEFI

Все ключи хранятся в безопасных переменных UEFI (см. раздел 7.2 спецификации UEFI). Защищенная переменная не может быть обновлена, если человек, пытающийся обновить, не может доказать (с помощью цифровой подписи на указанной полезной нагрузке, называемой дескриптором аутентификации), что он владеет закрытой частью ключа, использованного для создания переменной. Спецификации UEFI допускают только два типа ключей подписи: X509 и RSA2048. Защищенную переменную можно очистить, записав пустое обновление (которое все еще должно содержать действительный дескриптор аутентификации).

Дескриптор аутентификации

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

Режимы настройки и пользователя

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

В пользовательском режиме платформа будет проверять, имеет ли любая попытка записи в защищенную переменную правильно подписанный дескриптор аутентификации. В пользовательском режиме платформа также будет отображать флаг безопасной загрузки (который включен по умолчанию). Если установлена ​​безопасная загрузка, будут выполняться только бинарные файлы efi, которые

  1. не имеют знака, но имеют хэш sha-256, который находится в db, а не в dbx или
  2. подписаны и имеют подпись в db, но не в dbx или
  3. подписаны либо ключом в KEK, либо ключом в db, и ни ключ, ни подпись не появляются в dbx.

Ключ платформы (ПК)

Ключ платформы — это ключ к платформе, который хранится в переменной ПК. Его работа заключается в управлении доступом к переменной PK и переменной KEK. В большинстве реализаций в PK может храниться только один ключ, и PK может быть только X509.ключ.

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

Переменная PK может только обновляться дескриптором аутентификации, подписанным ключом платформы.

Примечание. Ключ платформы , а не может использоваться для подписи исполняемых двоичных файлов.

Ключ обмена ключами (KEK)

Ключ обмена ключами используется для обновления базы данных сигнатур и хранится в переменной KEK. Его можно использовать либо для обновления текущих баз данных сигнатур, либо для подписи двоичных файлов для действительного выполнения. В большинстве современных реализаций переменная KEK может содержать несколько ключей, которые могут иметь тип X509.или RSA2048, любой из которых может выполнять функцию ключа обмена ключами.

Переменная KEK может только обновляться дескриптором аутентификации, подписанным ключом платформы.

База данных запрещенных подписей (dbx)

База данных запрещенных подписей используется для аннулирования двоичных файлов efi и загружаемых ПЗУ, когда платформа работает в безопасном режиме. Он хранится в переменной dbx. Переменная dbx может содержать ключи, подписи или хэши. В режиме безопасной загрузки подпись, хранящаяся в двоичном файле efi (или вычисленная с помощью SHA-256, если двоичный файл не подписан), сравнивается с записями в базе данных. В исполнении отказывается, если либо

  1. Двоичный файл не имеет знака, а хэш SHA-256 двоичного файла имеет формат dbx или

    2. .

  2. Образ подписан и подпись соответствует записи в dbx или
  3. Образ подписан, и ключ, использованный для создания подписи, соответствует записи в dbx.

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

Переменная dbx может только обновляться дескриптором аутентификации, подписанным ключом обмена ключами.

База данных сигнатур (db)

База данных сигнатур используется для проверки подписанных двоичных файлов efi и загружаемых ПЗУ, когда платформа работает в безопасном режиме. Он хранится в переменной db. Переменная db может содержать смешанный набор ключей, подписей или хэшей. В режиме безопасной загрузки подпись, хранящаяся в двоичном файле efi (или хэш SHA-256, если подписи нет), сравнивается с записями в базе данных. Образ будет выполнен, если либо

  1. изображение не подписано и хеш SHA-256 изображения находится в базе данных или
  2. образ подписан и сама подпись есть в базе или
  3. образ подписан и ключ подписи есть в базе данных (и подпись действительна).

Переменная db может только обновляться дескриптором аутентификации, подписанным ключом обмена ключами.

Как работает проверка ключа

Несмотря на проверку ключа с помощью X509или ключи RSA2048 выглядят как стандарт SSL, но это не совсем так: цепочка ключей проверяется только до ключа в базах данных и не далее. Это означает, что ни один из ключей не должен быть самоподписанным, и что обычный подход ssl для проверки на всем пути к корневому ЦС не используется.

Читайте также: