Secure Boot — Википедия

Secure Boot (с англ. — «безопасная загрузка») — протокол, являющийся частью спецификации UEFI^[1]. Заключается в проверке электронной цифровой подписи выполняемых EFI-приложений, используя асимметричную криптографию относительно ключей, хранящихся в ключевом хранилище системы.

В 2011 году Microsoft включила в требования для сертификации компьютеров под управлением Windows 8 условие поставки таких систем с включённым Secure Boot с использованием ключа Microsoft. Более того, для ARM-систем (смартфоны и некоторые ноутбуки) требовалась невозможность отключения Secure Boot. Это вызвало большой общественный резонанс и критику в сторону Microsoft, поскольку такие требования значительно затрудняли, а в случае ARM-систем делали невозможной установку операционных систем, отличных от Microsoft Windows^[2][3][4].

Аутентифицированные переменные (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).
• Machine Owner Key (MOK) — Реализация ключа Secure Boot специфичная для ОС семейства Linux. Многие варианты Linux поддерживают Secure Boot, но он создает проблемы при использовании нестандартных ядер ОС и модулей. Для обхода это проблемы был разработан концепт МОК. МОК может использоваться с подписанным загрузчиком Shim для обеспечения управления ключами на уровне пользователь/системный администратор.

Переход в этот режим возможен из пользовательского режима очисткой 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].

Пользователь может самостоятельно сгенерировать и установить собственные ключи. Самостоятельно сгенерировать их, подписать и установить на компьютер. «Полный цикл» генерации ключей реализован и для ОС Linux, и для Windows.

Как правило в процессе генерации ключей применяется следующая цепочка преобразований:

PEM => DER => ESL => AUTH

Для Windows есть специальные инструменты от Майкрософт, а на Linux используется OpenSSL и набор утилит EfiTools. Cуществует проблема, связанная с отсутствием интерфейса для установки пользовательских ключей в BIOS некоторых производителей. Для этого также иногда требуется отдельная утилита.

Дополнительную сложность создает необходимость обеспечения совместимости с оборудованием от Майкрософт в ряде случаев. Проверка работает в обе стороны и без ключей Майкрософт их ПО и аппаратура (к примеру, GOP-драйверы внешних видеокарт и PXE-драйверы внешних сетевых карт, а значит и сами карты) работать не будут. То есть на определенном уровне довериться МС придется в любом случае.

Пользователю придется добавить ключ от Майкрософт в db или КЕК, что создает дополнительные риски для безопасности.

На одном компьютере может быть несколько КЕК и db. Таким образом может образоваться несколько ветвей доверия. Или же наоборот, одна db может быть подписана несколькими КЕК (хотя это и не требуется)

HP Sure Start — решение от компании Hewlett-Packard, фактически является встроенным аппаратно-программным СДЗ. Реализует функцию защиты ключей Secure Boot. Secure Boot в его текущем виде предлагается Microsoft как некий минимальный стандарт безопасности при защите от руткитов. Некоторые производители при этом разрабатывают свои решения, обеспечивающие доверенную загрузку в связке с решением от Microsoft, примером такого решения является HP Sure Start^[11].

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

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

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

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

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

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

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

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

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

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

• Работа с СДЗ

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

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

Первое — отключение Secure Boot на компьютерах с установленным СДЗ. Примером такого подхода может служить СДЗ SafeNode System Loader^[17].

Второе — поставка вместе с СДЗ комплекта аутентифицированные переменных, удостоверяющих валидность подписи загрузчика. После установки переменных работа СДЗ будет производиться без ограничений со стороны Secure Boot. Примером такого подхода может служить СДЗ Dallas Lock. Вместе с ключами в таком случае поставляется и утилита keytool.efi^[18].

• UEFI BIOS некоторых производителей имеют слабо развитый интерфейс для управления Secure Boot

• Тивоизация
• Embrace, Extend, and Extinguish (с англ. — «поддержать, надстроить и уничтожить») — политика Microsoft для устранения конкурентов и монополизации рынка
• СДЗ

• Unified Extensible Firmware Interface Specification. Version 2.6 (англ.) (PDF) (январь 2016). Дата обращения: 22 декабря 2016.