Secure boot

Аутентифицированные переменные (Authenticated Variable) — переменные, для изменения которых требуется аутентификация. Secure Boot подразумевает хранение публичных ключей, подписей и хешей приложений в аутентифицированных переменных, хранящихся в энергонезависимой памяти. Такие переменные могут быть перезаписаны двумя способами[5][6][7]:

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

• Platform Key (PK) — публичный ключ владельца платформы. Подписи соответствующим приватным ключом необходимы для смены PK или изменения KEK, db и dbx (описаны далее). Хранилище PK должно быть защищено от вмешательства и удаления.[8]
• Key Exchange Key (KEK) — публичные ключи операционных систем. Подписи соответствующими приватными ключами необходимы для изменения баз данных подписей (db, dbx, описаны далее). Хранилище KEK должно быть защищено от вмешательства.[8]
• Базы данных подписей (db, dbx) — Базы данных подписей и хешей доверенных приложений (db) и недоверенных приложений (dbx).

Переход в этот режим возможен из пользовательского режима очисткой PK.

В этом режиме не требуется аутентификация для записи PK, KEK, db, dbx.

Запись PK переводит систему в пользовательский режим. Запись единицы в специальную переменную AuditMode (доступна для записи только в режиме настройки и пользовательском режиме) переводит систему в режим аудита.

Переход в этот режим возможен из режима настройки или пользовательского режима записью единицы в переменную AuditMode. При смене режима на режим аудита очищается PK.

В этом режиме не требуется аутентификация для записи PK, KEK, db, dbx. В режиме аудита могут быть запущены не прошедшие проверку образы, а информация о всех этапах валидации образов будет записана в специальную таблицу, доступную из операционной системы, что позволяет тестировать комбинации сохраненных ключей и подписей, не опасаясь потери работоспособности системы[9].

Запись PK переводит систему в развернутый режим.

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

В этом режиме требуется аутентификация для изменения ключевых хранилищ, а также выполняется валидация запускаемых образов.

Удаление PK переводит систему в режим настройки. Запись единицы в переменную AuditMode переводит систему в режим аудита. Запись единицы в переменную DeployedMode (доступную для записи только в пользовательском режиме) переводит систему в развёрнутый режим.

Переход в этот режим возможен из режима аудита записью PK, или из пользовательского режима записью единицы в переменную DeployedMode.

Самый безопасный режим[9]. Отличается от пользовательского режима переводом всех переменных режима (AuditMode, DeployedMode, SetupMode) в режим только для чтения.

Переход в другие режимы (пользовательский или режим настройки) возможен только через платформозависимые методы или аутентифицированную очистку PK[9].

Перед запуском неизвестного UEFI-образа он должен пройти процесс авторизации.

1. Сброс. На этом этапе происходит инициализация платформы при загрузке.
2. Инициализация хранилища ключей.
3. Валидация UEFI-образа. Для успешной авторизации подпись или хеш образа должны содержаться в db, и не должны присутствовать в dbx.
4. Если UEFI-образ не прошёл валидацию, прошивка может использовать другие методы валидации (например, спросить у авторизованного пользователя — владельца приватного ключа, соответствующий которому публичный ключ находится в KEK). Результатом на этом этапе может являтся разрешение (шаг 8), отказ (шаг 6) или отсрочка.
5. В случае отсрочки информация о подписи добавляется в специальную таблицу, доступную из операционной системы.
6. В случае отказа или отсрочки производится попытка выполнения следующего варианта загрузки (шаг 3).
7. В случае разрешения подпись образа сохраняется в базу данных подписей.
8. Запуск образа.

Обновление базы данных доверенных приложений также доступно из операционной системы.[10]

• Защита от вредоносного ПО

При вмешательстве руткитов в критические компоненты операционной системы подписи соответствующих компонентов становятся невалидными. Такая операционная система попросту не будет загружена.[11]

• Локальные политики безопасности

При необходимости ограничить список возможных для запуска операционных систем это можно сделать внесением соответствующих подписей в базы данных подписей.[11]

• Выбор оборудования

Драйверы устройств, поддержка которых необходима на стадии загрузки системы, должны иметь подпись, которая бы корректно проходила проверку на всех платформах, где такие устройства могут использоваться. Для этого всем производителям такого оборудования придётся согласовываться со всеми производителями платформ для добавления их ключей в хранилища систем. Или такие драйверы придётся подписывать ключом, который уже содержится в большинстве платформ, но тогда производителям придётся целиком полагаться на владельца такого ключа (например, Microsoft подписывает загрузчик shim[12][13]). Также можно создавать подписи по цепочке, заканчивающейся ключом, содержащимся в большинстве платформ, но даже этот подход имеет недостаток — при удалении соответствующего ключа из ключевого хранилища (например, для запрета загрузки определённой операционной системы) подписи драйверов также становятся невалидными.[11]

• Выбор операционной системы

Поставщики систем не обязаны реализовывать возможность отключения Secure Boot. Процедура добавления сторонних ключей в хранилище должна быть недоступна для вредоносного программного обеспечения, следствием чего является усложнение этой процедуры для пользователей. Два этих фактора в совокупности значительно затрудняют использование неподписанных операционных систем, а также подписанных неизвестным для платформы ключом.[11]

• Уязвимости в реализации

Конкретные реализации прошивок устройств различных производителей могут содержать уязвимости, эксплуатирование которых может привести к обходу механизма Secure boot или его нивелированию.[14][15]

• Работа с СДЗ

Механизм Secure Boot может препятствовать работе средств доверенной загрузки. Поскольку СДЗ подменяют загрузчик ОС собственным загрузчиком, в общем случае не имеющим подписи, Secure Boot может заблокировать загрузчик СДЗ и следовательно помешать работе СДЗ в целом.

Существуют два решения этой проблемы.

Первое - отключение Secure Boot на компьютерах с установленным СДЗ.

Второе - поставка вместе с СДЗ комплекта аутентифицированные переменных, удостоверяющих валидность подписи загрузчика. После установки переменных работа СДЗ будет производиться без ограничений со стороны Secure Boot.