Secure Boot (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 для обеспечения управления ключами на уровне пользователь/системный администратор.

Режимы работы

[править | править код]

Setup Mode (режим настройки)

[править | править код]

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

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

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

Audit Mode (режим аудита)

[править | править код]

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

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

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

User Mode (пользовательский режим)

[править | править код]

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

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

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

Deployed Mode (развёрнутый режим)

[править | править код]

Переход в этот режим возможен из режима аудита записью 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

См. также

[править | править код]

Примечания

[править | править код]
  1. ↑ Спецификация UEFI.
  2. ↑ Will your computer’s «Secure Boot» turn out to be «Restricted Boot»? (англ.). Free Software Foundation. Дата обращения: 23 декабря 2016. Архивировано 28 ноября 2013 года.
  3. ↑ Windows 8 Secure Boot: The Controversy Continues (англ.). PC World. Дата обращения: 23 декабря 2016. Архивировано 31 марта 2017 года.
  4. ↑ Is Microsoft Blocking Linux Booting on ARM Hardware? (англ.). Computerworld UK. Дата обращения: 23 декабря 2016. Архивировано 5 апреля 2016 года.
  5. ↑ Спецификация UEFI, p. 1817.
  6. ↑ Спецификация UEFI, p. 1818.
  7. ↑ Спецификация UEFI, p. 1828.
  8. ↑ 1 2 Спецификация UEFI, p. 1819.
  9. ↑ 1 2 3 Спецификация UEFI, p. 1816.
  10. ↑ Спецификация UEFI, pp. 1803—1834.
  11. ↑ Technical white paper HP Sure Start (англ.). Дата обращения: 6 апреля 2022. Архивировано 19 ноября 2020 года.
  12. ↑ 1 2 3 4 Jeremy Kerr, Matthew Garrett, James Bottomley. UEFI Secure Boot Impact on Linux (англ.) (PDF). Дата обращения: 23 декабря 2016. Архивировано 19 июля 2017 года.
  13. ↑ mjg59 | Secure Boot bootloader for distributions available now. Дата обращения: 25 октября 2019. Архивировано 25 октября 2019 года.
  14. ↑ Secure the Windows 10 boot process — Microsoft 365 Security | Microsoft Docs. Дата обращения: 25 октября 2019. Архивировано 25 октября 2019 года.
  15. ↑ Corey Kallenberg, Sam Cornwell, Xeno Kovah, John Butterworth. Setup For Failure: Defeating Secure Boot (англ.) (PDF). The MITRE Corporation. Дата обращения: 23 декабря 2016. Архивировано 23 декабря 2016 года.
  16. ↑ Lucian Constantin. Researchers demo exploits that bypass Windows 8 Secure Boot (англ.). ITworld. Дата обращения: 23 декабря 2016. Архивировано 24 декабря 2016 года.
  17. ↑ Руководство администратора к СДЗ SafeNode System Loader. Дата обращения: 6 апреля 2022. Архивировано 14 августа 2020 года.
  18. ↑ Руководство по эксплуатации СДЗ Dallas Lock. Дата обращения: 6 апреля 2022. Архивировано 2 апреля 2022 года.

Литература

[править | править код]
Источник — https://ru.wikipedia.org/w/index.php?title=Secure_Boot&oldid=126052301