Secure Boot (z angličtiny – „secure boot“) je protokol, který je součástí specifikace UEFI [1] . Spočívá v ověřování elektronického digitálního podpisu běžících EFI aplikací pomocí asymetrické kryptografie vzhledem ke klíčům uloženým v úložišti klíčů systému.
Microsoft v roce 2011 zahrnul do požadavků na certifikaci počítačů s Windows 8 podmínku dodání takových systémů s povoleným Secure Boot pomocí klíče Microsoft. Systémy ARM (smartphony a některé notebooky) navíc vyžadovaly nemožnost deaktivovat Secure Boot. To vyvolalo velké veřejné pobouření a kritiku vůči Microsoftu, protože takové požadavky značně ztížily, a v případě systémů ARM, instalaci jiných operačních systémů než Microsoft Windows [2] [3] [4] .
Authenticated Variable – Proměnné, které ke změně vyžadují ověření. Secure Boot zahrnuje ukládání veřejných klíčů, podpisů a hash aplikací do ověřených proměnných uložených v energeticky nezávislé paměti. Takové proměnné lze přepsat dvěma způsoby [5] [6] [7] :
Přechod do tohoto režimu je možný z uživatelského režimu vymazáním PK.
Tento režim nevyžaduje autentizaci pro zápis PK, KEK, db, dbx.
Položka PK přepne systém do uživatelského režimu. Zápis jednotky do speciální proměnné AuditMode (lze zapisovat pouze v konfiguračním a uživatelském režimu) uvede systém do režimu auditu.
Režim auditu (režim auditu)Přechod do tohoto režimu je možný z režimu nastavení nebo uživatelského režimu zápisem jednotky do proměnné AuditMode. Když změníte režim na režim auditu, PK se vymaže.
Tento režim nevyžaduje autentizaci pro zápis PK, KEK, db, dbx. V režimu auditu lze spouštět neověřené obrazy a informace o všech fázích ověřování obrazu budou zaznamenány do speciální tabulky přístupné z operačního systému, která umožňuje testovat kombinace uložených klíčů a podpisů bez obav ze ztráty systému [9 ] .
Položka PK uvede systém do režimu nasazení.
Uživatelský režim (uživatelský režim)Přepnutí do tohoto režimu je možné z režimu nastavení zadáním PK nebo z režimu nasazení pomocí metody závislé na platformě (není specifikováno ve specifikaci).
Tento režim vyžaduje ověření ke změně úložišť klíčů a ověření spouštěcích obrazů.
Odstraněním PK se systém přepne do režimu nastavení. Zápis 1 do proměnné AuditMode uvede systém do režimu auditu. Zápis jedné do proměnné DeployedMode (lze zapisovat pouze v uživatelském režimu) uvede systém do režimu nasazení.
Deployed ModePřechod do tohoto režimu je možný z režimu auditu zápisem PK, nebo z uživatelského režimu zápisem jedničky do proměnné DeployedMode.
Nejbezpečnější režim [9] . Liší se od uživatelského režimu nastavením všech proměnných režimu (AuditMode, DeployedMode, SetupMode) na režim pouze pro čtení.
Přepnutí do jiných režimů (vlastní nebo konfigurační režim) je možné pouze prostřednictvím metod specifických pro platformu nebo autentizovaného PK clearingu [9] .
Před spuštěním neznámého obrazu UEFI musí projít procesem autorizace.
Aktualizace databáze důvěryhodných aplikací je dostupná i z operačního systému [10] .
Uživatel může nezávisle generovat a instalovat své vlastní klíče. Sami si je vygenerujte, podepište a nainstalujte do počítače. „Úplný cyklus“ generování klíčů je implementován pro operační systémy Linux i Windows.
V procesu generování klíče se zpravidla používá následující řetězec transformací:
PEM => DER => ESL => AUTH
Pro Windows existují speciální nástroje od Microsoftu a na Linuxu se používají OpenSSL a sada utilit EfiTools. Problém souvisí s chybějícím rozhraním pro nastavení vlastních klíčů v BIOSu některých výrobců. To také někdy vyžaduje samostatný nástroj.
Další složitost vytváří v některých případech potřebu zajistit kompatibilitu s vybavením od společnosti Microsoft. Kontrola funguje oběma způsoby a bez klíčů Microsoft nebude fungovat jejich software a hardware (například ovladače GOP pro externí grafické karty a ovladače PXE pro externí síťové karty, a tedy karty samotné). To znamená, že na určité úrovni budete muset MS věřit v každém případě.
Uživatel bude muset přidat klíč od společnosti Microsoft do db nebo KEK, což přináší další bezpečnostní rizika.
Na jednom počítači může být několik KEK a db. Tímto způsobem lze vytvořit několik větví důvěry. Nebo naopak, jedna db může být podepsána několika KEC (ačkoli to není vyžadováno)
HP Sure Start – řešení od Hewlett-Packard, je vlastně vestavěný hardwarový a softwarový SDZ. Implementuje funkci ochrany klíče Secure Boot. Secure Boot ve své současné podobě nabízí Microsoft jako minimální bezpečnostní standard pro ochranu před rootkity. Někteří výrobci přitom vyvíjejí vlastní řešení, která poskytují důvěryhodné spouštění ve spojení s řešením od Microsoftu, příkladem takového řešení je HP Sure Start [11] .
Když rootkity zasahují do kritických součástí operačního systému, podpisy odpovídajících součástí se stanou neplatnými. Takový operační systém se prostě nenačte [12] .
V případě potřeby omezte seznam možných operačních systémů ke spuštění, to lze provést zadáním příslušných podpisů do databáze podpisů [12] .
Ovladače zařízení, které vyžadují podporu ve fázi spouštění systému, musí mít podpis, který správně projde ověřením na všech platformách, kde lze taková zařízení použít. K tomu se budou muset všichni výrobci takového zařízení dohodnout se všemi výrobci platforem na přidání jejich klíčů do systémových úložišť. Nebo takové ovladače budou muset být podepsány klíčem, který je již součástí většiny platforem, ale pak se budou muset výrobci zcela spolehnout na vlastníka takového klíče (například Microsoft podepisuje shim bootloader [13] [14] ) . Je také možné vytvářet podpisy v řetězci, který končí klíčem obsaženým na většině platforem, ale i tento přístup má nevýhodu - když je odpovídající klíč odstraněn z úložiště klíčů (například kvůli zákazu načítání určitého operačního systému) , stávají se neplatnými i podpisy řidiče [12] .
Dodavatelé systému nemusí implementovat možnost deaktivovat zabezpečené spouštění. Postup přidávání klíčů třetích stran do trezoru musí být nepřístupný pro škodlivý software, což ztěžuje tento postup uživatelům. Tyto dva faktory dohromady značně znesnadňují používání nepodepsaných operačních systémů i těch podepsaných klíčem, který platforma nezná [12] .
Specifické implementace firmwaru zařízení od různých výrobců mohou obsahovat zranitelnosti, jejichž zneužití může vést k obejití mechanismu Secure boot nebo jeho vyrovnání [15] [16] .
Mechanismus Secure Boot může zabránit fungování důvěryhodných spouštěcích nástrojů. Vzhledem k tomu, že SDZ nahrazuje zavaděč OS vlastním zavaděčem, který obecně nemá signaturu, může Secure Boot zablokovat zavaděč SDZ a tím narušovat činnost SDZ jako celku.
Existují dvě řešení tohoto problému.
První je zakázání Secure Boot na počítačích s nainstalovaným SDZ. Příkladem takového přístupu je SDZ SafeNode System Loader [17] .
Druhým je dodání sady autentizovaných proměnných spolu s SDZ, osvědčujících platnost podpisu zavaděče. Po nastavení proměnných bude SDZ fungovat bez omezení ze Secure Boot. Příkladem tohoto přístupu je Dallas Lock SDZ. V tomto případě je s klávesami dodáván také nástroj keytool.efi [18] .