Про Secure Boot

Олег

9 августа 2026

Были времена, когда вирусы прятались в загрузочном секторе дискеты и заражали компьютер еще до того, как экран успевал засветиться логотипом Windows. Тогда это казалось неразрешимой головоломкой: как защитить то, что загружается самым первым, когда антивирус еще даже не запущен? Ответ на этот вопрос эволюционировал почти три десятилетия и вылился в технологию Secure Boot.

Secure Boot — это технология, которая работает как строгий пропускной пункт. Она проверяет каждую программу, которая хочет запуститься при включении компьютера, и пропускает только те, у которых есть правильная цифровая подпись. Если подписи нет или она не совпадает — загрузка останавливается.

Задумывалась эта система как защита от вредоносного кода, который пытается перехватить управление на самых ранних этапах старта. Однако на практике она стала источником головной боли для многих: мешает устанавливать альтернативные операционные системы, создаёт сложности при работе со старым оборудованием и требует дополнительных манипуляций от системных администраторов.

Далее про то, как устроен этот механизм, зачем он нужен и как с ним работать.

С чего всё началось?

Чтобы понять, откуда взялся Secure Boot, вспомним старые добрые времена BIOS. Эта система появилась ещё в начале 1980-х, когда компьютеры были размером с холодильник, а о безопасности особо не задумывались. BIOS действовал по принципу "доверяй, но не проверяй": он просто искал что-то загрузочное на дискетах или жёстких дисках и запускал это без лишних вопросов. Никаких подписей, никаких сертификатов — только порядок устройств в настройках.

Именно этой наивностью пользовались первые буткиты — зловреды, которые прописывались в самый загрузочный сектор. Такой вирус запускался раньше операционной системы и получал полный контроль над компьютером ещё до того, как загружался антивирус. Он мог перехватывать пароли, подменять системные файлы, скрывать своё присутствие — и делать всё это абсолютно невидимо для защитного ПО. Удалить его было почти невозможно: даже полная переустановка Windows не помогала, потому что вирус сидел в области, которую форматирование не затрагивало.

Ситуация стала критической в середине 2000-х, когда буткиты вроде TDL-4 начали заражать компьютеры миллионными тиражами. Особенно опасными они были для корпоративного сектора и финансовых учреждений. Стало окончательно ясно: нужны кардинальные изменения в подходе к загрузке системы. Старый BIOS исчерпал себя не только функционально, но и с точки зрения безопасности.

Решение пришло вместе с UEFI — новой спецификацией, которая должна была заменить древний BIOS. Консорциум крупных IT-компаний, включая Intel, Microsoft и AMD, разработал не просто новую систему загрузки, а целую платформу с встроенными механизмами безопасности. Secure Boot стал одним из ключевых нововведений.

Secure Boot впервые появился в спецификации UEFI 2.2 в 2008 году, но настоящую популярность обрёл только с выходом Windows 8 в 2012-м. Тогда Microsoft потребовала от производителей материнских плат обязательную поддержку Secure Boot для получения сертификации совместимости с новой ОС. Решение было неоднозначным: с одной стороны, оно повышало безопасность миллиардов устройств, с другой — многие обвиняли корпорацию в попытке ограничить установку альтернативных операционных систем, таких как Linux. Скандалы вокруг "закрытой экосистемы" и "монополии Microsoft" разгорались с новой силой, но время показало, что технология прижилась и эволюционировала в сторону большей гибкости.

Для Microsoft Secure Boot стал обязательным требованием с Windows 11. Не из идеологических соображений, а потому что современные функции защиты типа Credential Guard, Device Guard, Hypervisor-protected Code Integrity зависят от цепочки доверия, которая тянется с самой загрузки.

Как работает Secure Boot?

Secure Boot базируется на криптографической модели цепочки доверия (Chain of Trust), где каждый этап загрузки верифицирует следующий до передачи управления. Технически это реализовано через инфраструктуру открытых ключей (PKI) и несколько уровней баз данных, прошитых в энергонезависимую память UEFI.

На аппаратном уровне в NVRAM материнской платы хранятся четыре основные базы данных:

PK (Platform Key) — корневой ключ платформы, задаваемый производителем оборудования. Он определяет владельца платформы и используется для управления всей цепочкой сертификатов.
KEK (Key Exchange Key Database) — база ключей обмена, через которую можно добавлять или удалять записи в db и dbx. Эти ключи подписываются PK.
db (Signature Database) — белый список. Содержит сертификаты и хэши доверенных исполняемых файлов, подписи которых допускаются к загрузке.
dbx (Forbidden Signature Database) — черный список. Включает отозванные или скомпрометированные сертификаты и хэши. Запись в dbx имеет приоритет над db — даже если файл числится в белом списке, но попал в dbx, загрузка будет заблокирована.

Процесс запуска выглядит так:

Инициализация UEFI-прошивки. После подачи питания микрокод процессора инициализирует платформу и передаёт управление UEFI-драйверам. На этом этапе Secure Boot активируется, если он включён в настройках.
Верификация загрузчика. UEFI-прошивка сканирует загрузочные устройства в соответствии с порядком, заданным в BootOrder. Обнаружив EFI-приложение (например, bootmgfw.efi для Windows или shim.efi для Linux), она извлекает его цифровую подпись (обычно в формате Authenticode PKCS#7) и проверяет её по цепочке сертификатов.
Алгоритм проверки:
- Сначала файл проверяется по базе dbx (чёрный список) — если его хэш или сертификат там найден, загрузка немедленно прерывается с ошибкой Security Violation.
- Затем проверяется db (белый список). Если подпись валидна и сертификат есть в базе доверенных, файл признаётся валидным и получает управление.
- Если подписи нет или она не прошла верификацию, UEFI пытается проверить хэш файла напрямую (если он добавлен в db). Если и это не помогло — загрузка блокируется.
Передача цепочки. После того как загрузчик получает управление, он обязан продолжить проверку. Например, загрузчик Windows (winload.efi) верифицирует цифровые подписи ядра (ntoskrnl.exe), критических драйверов (имеющих загрузочный статус SERVICE_BOOT_START), а также файлов подсистемы восстановления. Каждый компонент подписывается с использованием сертификатов Microsoft, добавленных в db производителем материнской платы.

Подпись может быть наложена не только напрямую, но и через вложенные сертификаты. Например, стандартный сертификат Microsoft UEFI CA является промежуточным, и его цепочка ведёт к корневому сертификату Microsoft, который также может быть зашит в db. Это позволяет гибко обновлять схемы подписи без перепрошивки всей UEFI.

Для Linux-экосистем используется цепочка через shim. Это небольшой EFI-загрузчик, подписанный Microsoft, который содержит встроенный сертификат дистрибутива. Запускаясь, shim проверяет подпись самого себя (через Microsoft-сертификат из db), затем верифицирует следующий загрузчик (например, GRUB) уже по своему внутреннему белому списку или через Machine Owner Key (MOK) — механизм, позволяющий пользователю добавлять собственные ключи в защищённую среду UEFI.

Важно понимать, что Secure Boot работает исключительно в контексте загрузочных EFI-приложений и драйверов, загружаемых до старта ядра. После передачи управления ядру операционная система может реализовывать собственную политику проверки (например, в Windows это Driver Signature Enforcement), но это уже отдельный уровень защиты, не связанный напрямую с UEFI Secure Boot.

Отключение Secure Boot или добавление пользовательских ключей (PK/KEK) требует физического доступа к UEFI Setup или подтверждения через протоколы Secure Boot Variables (имеется в виду интерфейс аутентифицированных переменных UEFI, защищённых от изменения из работающей ОС без соответствующих подписей). Любые изменения в базах данных должны быть подписаны ключом с более высоким уровнем иерархии (KEK для db/dbx, PK для KEK), что предотвращает компрометацию со стороны вредоносного ПО даже при наличии администраторских прав в системе.

TPM

TPM (Trusted Platform Module) — это отдельный криптографический процессор, который работает в связке с Secure Boot. Строго говоря, TPM не обязателен для Secure Boot, но вместе они создают мощный тандем: Secure Boot проверяет подписи, а TPM измеряет состояние системы.

В отличие от Secure Boot, который отвечает на вопрос "этот загрузчик подписан правильно?", TPM отвечает на вопрос "система загрузилась именно так, как ожидалось, или в процессе что-то изменилось?". Это называется измерением конфигурации.

При каждом этапе загрузки TPM создаёт криптографические хэши (отпечатки) всех запускаемых компонентов — от прошивки UEFI до загрузчика и ядра. Эти отпечатки сохраняются в защищённых регистрах PCR (Platform Configuration Registers) внутри TPM. Каждый PCR хранит хэш-сумму цепочки загруженных компонентов, причём обновляется он не перезаписью, а по формуле: новое_значение = хэш(старое_значение || данные_нового_компонента). Это позволяет отслеживать всю историю загрузки.

Если в системе появился буткит, который подменил загрузчик или ядро, его хэш не совпадёт с эталонным — и TPM это зафиксирует. Более того, TPM может запечатать (seal) данные — например, ключи шифрования диска BitLocker — таким образом, что они расшифруются только при условии, что текущее состояние PCR совпадает с ожидаемым. Если система была скомпрометирована, ключи просто не выдадутся, и диск останется зашифрованным.

Secure Boot не пускает в систему неподписанный код. TPM фиксирует, что именно загрузилось, и защищает критичные данные — пароли, ключи шифрования, сертификаты. Вместе они формируют тот самый корень доверия, без которого современная безопасность на уровне железа была бы невозможна.

TPM существует в двух вариантах:

Дискретный TPM (dTPM) — отдельная микросхема на материнской плате. Она физически изолирована от основного процессора, что делает её устойчивой к программным атакам. Считается более защищённым вариантом, но увеличивает себестоимость устройства.
Встроенный TPM (fTPM) — программная реализация, выполняющаяся в защищённой среде основного процессора (например, ARM TrustZone или Intel TXT). Функционально она аналогична дискретному TPM, но использует существующие вычислительные мощности. С точки зрения безопасности считается чуть менее надёжной, поскольку разделяет физический кристалл с основным процессором, но на практике разница для большинства сценариев несущественна.

Начиная с Windows 11, наличие TPM версии 2.0 стало обязательным системным требованием. Это вызвало много шума — миллионы старых ПК официально не поддерживают новую ОС, хотя технически они могли бы её запустить.

Установка Windows 11 без TPM, Secure Boot и ограничений памяти с помощью Rufus

Криптография

В основе Secure Boot лежит асимметричная криптография — та же технология, что используется в HTTPS и цифровых подписях. Суть проста: есть пара ключей — закрытый (секретный) и открытый (публичный). То, что подписано закрытым ключом, может проверить только соответствующий открытый.

Когда Microsoft подписывает загрузчик, она создаёт цифровую подпись с помощью своего закрытого ключа. Открытый сертификат Microsoft заранее прошит в UEFI (в базе db). При загрузке система расшифровывает подпись этим сертификатом, вычисляет хэш файла и сравнивает с оригиналом. Совпало — загрузка разрешена. Нет — блокировка.

Алгоритмы: чаще всего RSA с длиной ключа 2048 или 4096 бит. Некоторые платформы поддерживают ECDSA на эллиптических кривых — он быстрее при той же стойкости, но встречается реже. Хэши считаются по SHA-256 или SHA-384, подпись хранится в формате Authenticode PKCS#7 внутри EFI-файла.

Слабое место Secure Boot — не криптография, а человеческий фактор: пользователи отключают защиту или добавляют непроверенные ключи, сводя всю систему на нет.

Практика

Теория — это хорошо, но что происходит, когда обычный человек сталкивается с Secure Boot в реальной жизни? Оказывается, не всё так гладко, как может показаться в документации.

Настройка через UEFI Setup

Почти все современные материнские платы позволяют управлять Secure Boot через меню Setup. Обычно нужные настройки прячутся в разделе Security или Boot, но точное расположение зависит от производителя.

Казалось бы, что может быть проще — зашёл в настройки, поставил (или снял) галочку "Secure Boot Enable" — и всё работает. На практике всё сложнее. Многие системы не дают просто взять и отключить Secure Boot. Сначала нужно очистить все пользовательские ключи, перевести систему в Setup Mode, и только потом можно менять настройки. Это защитный механизм: чтобы злоумышленник не мог отключить защиту простым перезапуском в BIOS.

Ещё одна засада — разные производители называют одни и те же функции по-разному. То, что у ASUS называется "Secure Boot Control", у MSI может быть "Windows UEFI mode", а у Gigabyte — "Secure Boot Enable". Единого стандарта интерфейса не существует, поэтому приходится методом тыка искать нужную настройку или гуглить по модели материнской платы.

Типичная последовательность действий для включения/отключения:

Войти в UEFI Setup при загрузке.
Найти раздел Security или Boot.
Если Secure Boot активен и серый (недоступен для изменения) — найти опцию "Clear Secure Boot Keys" или "Restore Factory Keys".
Перевести систему в "Setup Mode" (это сбрасывает PK).
После этого настройки Secure Boot становятся доступными для изменения.
Не забудьте сохранить изменения (Save & Exit).

Совместимость с операционными системами

Windows 8 и более новые версии работают с Secure Boot из коробки — Microsoft ведь сама и продвигала эту технологию. Проблемы начинаются, когда хочется поставить что-то ещё.

Linux долгое время был головной болью для пользователей Secure Boot. В первые годы большинство дистрибутивов просто советовали отключить эту "вредную" функцию. Сейчас картина изменилась: Ubuntu, Fedora, SUSE, Debian научились работать с Secure Boot, но каждый решает задачу по-своему.

Самый популярный подход — использование shim-загрузчика, подписанного Microsoft. Этот загрузчик может запускать ядра Linux, подписанные собственными ключами дистрибутива. Получается двухуровневая система доверия: Microsoft доверяет shim, а shim доверяет конкретному дистрибутиву. На практике это работает так:

UEFI проверяет подпись shim (Microsoft-сертификат из db) — проходит.
shim проверяет подпись GRUB (по своему внутреннему сертификату или через MOK) — проходит.
GRUB проверяет подпись ядра (по ключам дистрибутива) — проходит.
Ядро загружается.

Но что делать, если нужно загрузить самодельное ядро или экзотический дистрибутив? Тут есть несколько вариантов:

Отключить Secure Boot — самый простой, но небезопасный путь.
Настроить собственные ключи — добавить свой сертификат в db (сложно, но даёт полный контроль).
Использовать MOK (Machine Owner Key) — механизм, позволяющий добавлять пользовательские ключи прямо во время загрузки через специальную утилиту mokutil. Это компромиссный вариант: не нужно отключать защиту целиком, но можно подписывать свои сборки.
Режим разработчика — некоторые материнские платы поддерживают специальный режим, в котором Secure Boot включён, но разрешена загрузка неподписанных EFI-файлов (редко встречается).

Для других ОС ситуация ещё хуже. FreeBSD и многие *BSD-системы долгое время не поддерживали Secure Boot. Windows 7 вообще не умеет с ним работать — для её установки Secure Boot нужно отключать. То же касается старых версий Linux и большинства Live-сборок.

Корпоративные сценарии

В больших организациях Secure Boot открывает интересные возможности, но создаёт и новые проблемы. Многие компании хотят использовать собственные ключи для подписи корпоративных образов операционных систем. Это даёт полный контроль над тем, что может запускаться на рабочих станциях — ни один сотрудник не загрузит "левую" флешку или неподписанный драйвер.

Массовое развертывание такой конфигурации требует специальных инструментов. Microsoft предоставляет утилиты для управления базами ключей UEFI (например, SignTool для подписи файлов и утилиты для работы с Secure Boot Variables), но процесс всё равно остаётся довольно сложным. Нужно:

Настроить инфраструктуру подписи (PKI с собственным центром сертификации).
Сгенерировать и распространить ключи на все машины (через групповые политики или скрипты).
Обучить администраторов новым процедурам и протоколам.
Настроить процессы обновления сертификатов (потому что ключи имеют срок годности).

Некоторые организации используют Secure Boot не только для защиты от вирусов, но и для контроля соответствия корпоративным стандартам. Можно настроить систему так, чтобы загружались только официально одобренные образы операционных систем с нужным набором драйверов и программного обеспечения. Это особенно актуально в банковском секторе, госучреждениях и на режимных объектах, где безопасность — критический фактор.

Однако есть и обратная сторона. Корпоративные политики безопасности, завязанные на Secure Boot, могут стать головной болью для IT-отдела. Если сертификат истёк или был отозван, а администратор не успел обновить ключи на всех машинах — часть парка может просто не загрузиться. Процесс восстановления в таком случае будет долгим и болезненным.

Что даёт Secure Boot хорошего?

После всех технических подробностей стоит честно оценить, что хорошего даёт Secure Boot обычным пользователям и организациям.

Реальная защита от буткитов

Главное достижение Secure Boot — практически полная ликвидация угрозы загрузочных вирусов. До появления этой технологии буткиты были серьёзной проблемой: они стартовали раньше антивируса, маскировали своё присутствие и выживали даже после переустановки системы. Традиционные антивирусы против них были бессильны, потому что не имели доступа на этапе загрузки.

Современные буткиты типа TDL-4, Alureon или побочные ответвления больше не могут заражать системы с включённым Secure Boot. Технология ставит непреодолимый барьер на самом раннем этапе: неподписанный или скомпрометированный загрузчик просто не получит управление. Даже если вредоносная программа каким-то образом попала на диск, она не сможет активироваться до старта ОС.

Важно понимать ограничения: Secure Boot защищает только от загрузочных угроз. Вирусы, трояны и эксплойты, которые проникают в уже работающую систему через браузер, email или заражённые документы, остаются задачей для обычных антивирусов и брандмауэров. Это слой защиты, а не панацея.

Гарантия целостности системы

Secure Boot даёт уверенность, что система загружается именно с тем софтом, который был изначально установлен. Если кто-то попытается заменить загрузчик, ядро или критический драйвер на заражённую или модифицированную версию, механизм проверит цифровую подпись и заблокирует загрузку при несовпадении.

Это особенно ценно для систем, работающих без присмотра или в условиях ограниченного физического доступа: банкоматы, платёжные терминалы, промышленные контроллеры, медицинское оборудование. Для таких устройств гарантия того, что они загружаются только с проверенным ПО, — критическое требование безопасности.

Усложнение целевых атак

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

Это не делает систему неуязвимой, но значительно поднимает планку для успешной атаки. Хакерам приходится использовать более сложные и дорогие методы — например, эксплуатировать уязвимости нулевого дня уже на уровне ядра или атаковать саму подсистему UEFI. Многие массовые атаки становятся экономически невыгодными, так как требуют ресурсов, сопоставимых с атаками на государственные структуры.

Снижение рисков при использовании сторонних носителей

Пользователи часто загружаются с USB-флешек, внешних дисков или сетевых репозиториев. Без Secure Boot такой носитель может содержать вредоносный загрузчик, который незаметно пропишется в систему. С Secure Boot любой неподписанный загрузочный носитель будет просто заблокирован — если только пользователь не отключил защиту вручную. Это снижает риск случайного заражения при использовании чужих или непроверенных накопителей.

Интеграция с другими механизмами защиты

Secure Boot не работает в вакууме. Он служит фундаментом для более сложных систем безопасности:

BitLocker использует измерения TPM (включая информацию о загруженных компонентах) для привязки ключей шифрования к конкретному состоянию системы.
Credential Guard и Device Guard в Windows опираются на цепочку доверия, которая начинается с Secure Boot.
Hypervisor-protected Code Integrity (HVCI) требует проверки подписей драйверов, которая корректно работает только при включённом Secure Boot.

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

Что даёт Secure Boot плохого?

У Secure Boot есть серьёзные недостатки, о которых стоит честно поговорить.

Сложность использования

Главная проблема Secure Boot — его сложность для конечного пользователя. Обычные люди часто сталкиваются с проблемами при попытке загрузиться с флешки или установить альтернативную операционную систему. Вместо привычной загрузки появляется непонятное сообщение об ошибке подписи: "Secure Boot Violation", "Invalid signature detected" или "Verification failed". Пользователь впадает в ступор — что это за ошибка, почему она появилась и как её исправить?

Системные администраторы тоже жалуются на сложность массового управления Secure Boot. Нет единых стандартизированных инструментов, каждый производитель предлагает свои утилиты с разными интерфейсами и возможностями. Для одного вендора — это отдельная утилита в Windows, для другого — только через UEFI Shell, для третьего — скрипты для Linux. Документация часто скудная или противоречивая.

Ошибки в настройке Secure Boot могут привести к полной неработоспособности системы. В отличие от программных настроек, которые легко поменять из Windows, проблемы с Secure Boot требуют доступа к UEFI Setup и глубокого понимания криптографических принципов. Заблокировали систему случайно? Готовьтесь разбираться с ключами, режимами Setup/User и очисткой базы db. Это не для слабонервных.

Проблемы совместимости

Несмотря на прогресс последних лет, совместимость остаётся болевой точкой. Многие полезные инструменты до сих пор не имеют подписей для работы с Secure Boot:

Загрузочные антивирусы — некоторые производители до сих пор не подписали свои Rescue-диски.
Утилиты диагностики железа — MemTest86, тесты жёстких дисков, стресс-тесты.
Инструменты восстановления данных — загрузочные среды для восстановления удалённых файлов или ремонта разделов.
Старые версии установщиков — например, Windows 7 или старые дистрибутивы Linux просто не знают о Secure Boot.

Особенно острая проблема в специализированных областях. Разработчики встраиваемых систем, исследователи безопасности, энтузиасты, создающие кастомные сборки, часто используют самодельные ядра и загрузчики, которые принципиально не могут получить официальную подпись от Microsoft. Процесс подписания либо недоступен, либо слишком дорог и бюрократизирован.

Ограниченная эффективность против современных угроз

Secure Boot защищает только от загрузочных угроз, но современный ландшафт кибербезопасности гораздо шире:

Атаки через браузер — вредоносные скрипты, фишинговые сайты, эксплойты нулевого дня.
Социальная инженерия — пользователя обманом заставляют запустить вредоносный файл.
Фишинг — кража паролей и данных через поддельные страницы.
Эксплойты прикладного ПО — уязвимости в офисных пакетах, браузерах, медиаплеерах.

Все эти угрозы остаются за пределами возможностей Secure Boot. Более того, технология может создавать ложное чувство безопасности. Пользователи думают, что раз Secure Boot включён — их система полностью защищена, и снижают бдительность в отношении других угроз: не обновляют антивирус, игнорируют обновления ОС, открывают подозрительные вложения.

Даже с включённым Secure Boot можно загрузить неподписанный загрузчик, если злоумышленник получил физический доступ к компьютеру и переключил систему в Setup Mode. Или если пользователь сам добавил в базу db вредоносный сертификат (например, поддавшись на социальную инженерию). Secure Boot — это не волшебная таблетка, а лишь один из слоёв защиты

Вопросы контроля и свободы

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

Есть обоснованные опасения, что Secure Boot может использоваться не только для защиты от вредоносного ПО, но и для ограничения свободы пользователей — как потенциальный инструмент вендор-лока, когда производитель решает, что можно запускать на "его" устройстве, а что нельзя. Хотя спецификация UEFI предусматривает возможность отключения Secure Boot и добавления пользовательских ключей, некоторые производители могут эту возможность ограничивать, выпуская прошивки с урезанным функционалом.

Особенно остро этот вопрос стоит на рынке мобильных устройств и ARM-систем, где Secure Boot часто жёстко привязан к ключам производителя, и отключить его без взлома прошивки невозможно. В мире x86-совместимых ПК ситуация пока более демократична, но тренд на усиление контроля со стороны вендоров настораживает.

Последние события, связанные с отзывом TLS сертификатов у российских компаний — готовый пример, как говорится, из первых рук.

Наследие и обратная совместимость

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

Также есть проблема с двойной загрузкой (dual-boot). Настроить корректную работу Windows и Linux на одном компьютере с Secure Boot можно, но это требует дополнительных шагов с MOK и shim, и далеко не всегда всё работает из коробки, особенно с экзотическими дистрибутивами.

Альтернативы

SecureBoot не единственная технология безопасной загрузки

Intel TXT и AMD SVM

Intel Trusted Execution Technology (TXT) и AMD Secure Virtual Machine (SVM) работают на более глубоком уровне, чем Secure Boot. Эти технологии встроены прямо в процессор и обеспечивают измеренную загрузку — каждый компонент системы (от прошивки до гипервизора) измеряется и записывается в защищённые регистры TPM.

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

TXT и SVM могут работать совместно с Secure Boot, создавая многоуровневую защиту. Secure Boot не даёт загружаться неподписанному коду, а TXT/SVM ведут подробный учёт того, что именно загрузилось, и позволяют удалённо аттестовать состояние системы. Это особенно востребовано в облачных средах и корпоративных центрах обработки данных.

ARM TrustZone

В мобильных устройствах и встраиваемых системах доминирует архитектура ARM с технологией TrustZone. Она создаёт два параллельных мира выполнения:

Secure World (безопасный мир) — изолированная среда для выполнения критических операций: проверка подписей, хранение ключей, криптографические вычисления.
Non-Secure World (обычный мир) — среда, где работает основная операционная система и приложения.

Загрузка начинается в Secure World, где выполняется верификация и инициализация критических компонентов. Только после этого управление передаётся в обычный мир. Такой подход обеспечивает жёсткую изоляцию функций безопасности от основной ОС, что может быть эффективнее цепочки доверия Secure Boot в некоторых сценариях — особенно на устройствах с ограниченными ресурсами.

Открытые альтернативы

Сообщество разработчиков открытого ПО создало несколько альтернатив проприетарным решениям:

coreboot — открытая замена UEFI/BIOS с собственными механизмами проверки подписей. Позволяет полностью контролировать процесс загрузки и использовать кастомные политики безопасности. Популярен в сообществе энтузиастов и у производителей Chromebook.
LinuxBoot — идёт ещё дальше, заменяя большую часть традиционной прошивки на урезанное ядро Linux. Загрузка начинается с минимального Linux-образа, который уже содержит всё необходимое для верификации, инициализации оборудования и запуска основной ОС. Это даёт максимальную гибкость и ускоряет загрузку.
OpenBoot / IEEE 1275 — историческая альтернатива, использовавшаяся в SPARC-станциях Sun Microsystems и некоторых PowerPC-системах. Основана на языке Forth и позволяла выполнять произвольные скрипты на этапе загрузки. Сейчас практически не встречается.

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

Ошибки и решения

Даже при правильно настроенной системе с Secure Boot пользователи и администраторы регулярно сталкиваются с ошибками. Вот самые частые из них и способы решения.

Secure Boot Violation

На чёрном экране появляется сообщение "Secure Boot Violation - Invalid signature detected. Check Secure Boot policy in Setup" или похожее. Загрузка останавливается, система не стартует.

Причины:

Попытка загрузиться с неподписанного носителя (флешка, внешний диск).
Установка неподписанного или самодельного загрузчика.
Замена системных EFI-файлов (например, после обновления прошивки или восстановления системы).
Устаревший shim-загрузчик в Linux-системах.

Решения:

Временное отключение. Зайти в UEFI Setup и отключить Secure Boot для однократной загрузки с нужного носителя. После установки включить обратно.
Использовать подписанный загрузчик. Для Linux — использовать дистрибутивы с shim (Ubuntu, Fedora, SUSE) или подписать свой загрузчик через MOK.
Добавить ключ в базу db. Если вы собираетесь постоянно использовать неподписанный загрузчик, можно добавить его сертификат в доверенные. Требует генерации собственных ключей и подписи файлов.
Переключиться в Setup Mode. Очистить ключи Secure Boot и перевести систему в режим настройки — после этого можно загружать что угодно, но защита фактически отключена.

Быстрый fix для большинства случаев:

Войти в UEFI Setup → Security → Secure Boot → 
Выбрать "Boot Mode" → изменить с "Standard" на "Custom" → 
Вернуться и отключить Secure Boot → Save & Exit.

Invalid signature detected

Сообщение "Invalid signature detected. The system will not boot" или "Signature verification failed". Часто сопровождается указанием конкретного файла, который не прошёл проверку.

Причины:

Загрузчик или драйвер повреждён (например, битые сектора на диске).
Файл был модифицирован (вручную, вирусом или неудачным обновлением).
Сертификат, которым подписан файл, отозван или добавлен в dbx.
Истёк срок действия сертификата.
Версия загрузчика не соответствует сертификату (например, старый загрузчик на системе с новыми ключами).

Решения:

Восстановить файл из резервной копии. Если известен конкретный файл — заменить его на оригинальный (например, с установочного диска Windows).
Обновить загрузчик. Для Linux — выполнить обновление пакета shim или GRUB через Live-CD. Для Windows — запустить восстановление системы с установочного носителя.
Проверить диск на ошибки. Возможно, файл повреждён физически. Запустить chkdsk или fsck с Live-носителя.
Временно отключить проверку. Если нужно срочно загрузиться для восстановления — отключить Secure Boot в UEFI.
Очистить кэш UEFI. В редких случаях помогает сброс настроек UEFI до заводских и перезапись ключей.

Если ошибка появилась после обновления Windows, часто помогает принудительная перезагрузка через восстановление:

При загрузке трижды прервать старт (кнопкой Reset).
Запустится среда восстановления.
Выбрать "Восстановление при загрузке" или откатить последнее обновление.

Verification failed

Сообщение "Verification failed: (0x1A) Security Violation" или просто "Verification failed" с кодом ошибки.

Причины:

Проблемы с цепочкой сертификатов (например, не найден корневой сертификат в db).
Некорректная настройка ключей (смешаны ключи от разных производителей).
Попытка загрузить EFI-файл, подписанный ключом, которого нет в db.
Использование старых версий загрузчиков, подписанных отозванными сертификатами (например, старый shim с уязвимостью CVE-2020-10713 был добавлен в dbx и больше не загружается).

Решения:

Обновить прошивку UEFI. Производители периодически обновляют базу dbx, добавляя новые отозванные сертификаты. Свежая прошивка может решить проблему.
Сбросить ключи до заводских. В UEFI Setup найти "Restore Factory Keys" — это восстановит стандартные ключи Microsoft, убрав все пользовательские изменения.
Проверить цепочку подписи. Для Linux — убедиться, что используется актуальный shim, подписанный Microsoft. Проверить через sbverify --list /boot/efi/EFI/...
Использовать MOK. Если вы подписали ядро своим ключом — проверить, что ключ добавлен в MOK. Утилита mokutil --list-enrolled покажет текущие ключи.
Полностью переустановить загрузчик. Для Windows — загрузиться с установочного диска и выполнить bootrec /rebuildbcd. Для Linux — переустановить GRUB через chroot.

Error 0x00000000 / 0x00000001 — "Secure Boot is not configured correctly"

Система не загружается с сообщением о некорректной конфигурации Secure Boot. Часто встречается на ноутбуках после обновления BIOS.

Причины:

В UEFI включён Secure Boot, но база ключей пуста или повреждена.
Ошибка при записи ключей в NVRAM.
Сбой прошивки при обновлении.

Решения:

Сброс UEFI до заводских настроек (обычно опция "Load Optimized Defaults").
Если не помогает — переустановить ключи через "Restore Factory Keys" или "Install Default Secure Boot Keys".
В крайнем случае — перепрошить BIOS свежей версией с официального сайта производителя.
Проверить батарейку CMOS — если она села, настройки UEFI могут сбрасываться при выключении питания, что приводит к потере ключей.

Проблемы с MOK (Machine Owner Key) в Linux

При загрузке появляется синий экран MOK Management с предложением зарегистрировать ключ или с ошибкой о его отсутствии.

Причины:

Дистрибутив Linux использует собственные ключи для подписи ядра.
Пользователь добавил свой ключ через mokutil, но не подтвердил его в MOK Management при перезагрузке.
Ключ был удалён или истёк.

Решения:

Зарегистрировать ключ через MOK Management. При перезагрузке появится синий экран — выбрать "Enroll MOK", затем "View key" и "Continue". Подтвердить добавление.
Проверить статус MOK. В терминале: mokutil --list-enrolled и mokutil --sb-state.
Удалить проблемный ключ. sudo mokutil --delete (если ключ был добавлен ошибочно).
Временно отключить проверку. В UEFI Setup отключить Secure Boot, загрузиться, настроить, затем включить обратно.

Превентивные меры

Перед установкой альтернативной ОС проверьте её совместимость с Secure Boot.
Обновляйте прошивку UEFI — производители добавляют новые ключи в db и dbx.
Используйте официальные образы с подписанными загрузчиками (Ubuntu, Fedora, официальные ISO Windows).
Создавайте резервные копии ключей перед изменением настроек Secure Boot (можно экспортировать через утилиты вроде sbkeysync).
Для корпоративных сред — разработайте регламент управления ключами и процесс обновления сертификатов.

Итого

Secure Boot — это не панацея и не злой умысел Microsoft, а эволюционный шаг в развитии безопасности загрузочного процесса. Как любая технология, она имеет свои сильные и слабые стороны.

Главный итог: для 90% пользователей Secure Boot лучше оставить включённым. Он не мешает повседневной работе, защищает от серьёзного класса угроз и служит фундаментом для других механизмов безопасности — BitLocker, Credential Guard, HVCI. Плата за эту защиту — редкие, но неприятные моменты, когда нужно загрузиться с флешки или установить альтернативную ОС.

Для энтузиастов и разработчиков Secure Boot — это инструмент, который можно настроить под себя. Добавление собственных ключей через MOK или генерация пользовательского PK/KEK даёт полный контроль над тем, что можно загружать, без полного отключения защиты. Да, это сложнее, чем переключатель "вкл/выкл", но для тех, кому безопасность действительно важна — это адекватная цена.

Для корпоративных сред Secure Boot — обязательный элемент defence-in-depth. В сочетании с TPM и другими механизмами он позволяет строить системы с гарантированной целостностью на уровне железа. Но требует вдумчивого подхода к управлению ключами и администрированию.

Что в итоге? Технология, которая начиналась как реакция на буткиты, стала стандартом индустрии. Она неидеальна, иногда раздражает, но свою основную задачу выполняет — загрузочные вирусы, бывшие бичом 2000-х, сегодня практически исчезли из массовых атак. И в этом заслуга Secure Boot есть.