Открыть главное меню

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

Содержание

ИсторияПравить

В 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).

Режимы работыПравить

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]

Достоинства и недостаткиПравить

ДостоинстваПравить

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

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

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

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

НедостаткиПравить

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

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

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

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

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

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

ПримечанияПравить

  1. Спецификация UEFI.
  2. Will your computer’s «Secure Boot» turn out to be «Restricted Boot»? (англ.). Free Software Foundation. Дата обращения 23 декабря 2016.
  3. Windows 8 Secure Boot: The Controversy Continues (англ.). PC World. Дата обращения 23 декабря 2016.
  4. Is Microsoft Blocking Linux Booting on ARM Hardware? (англ.). Computerworld UK. Дата обращения 23 декабря 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. 1 2 3 4 Jeremy Kerr, Matthew Garrett, James Bottomley. UEFI Secure Boot Impact on Linux (англ.) (PDF). Дата обращения 23 декабря 2016.
  12. Corey Kallenberg, Sam Cornwell, Xeno Kovah, John Butterworth. Setup For Failure: Defeating Secure Boot (англ.) (PDF). The MITRE Corporation. Дата обращения 23 декабря 2016.
  13. Lucian Constantin. Researchers demo exploits that bypass Windows 8 Secure Boot (англ.). ITworld. Дата обращения 23 декабря 2016.

ЛитератураПравить