Sdílet prostřednictvím

Pokyny k vytvoření a správě zabezpečeného spouštěcího klíče systému Windows

Tento dokument vám pomůže při vytváření a správě klíčů zabezpečeného spouštění a certifikátů ve výrobním prostředí. Řeší dotazy související s vytvářením, ukládáním a načítáním klíčů platformy (PK), klíčů pro zabezpečenou aktualizaci firmwaru a klíčů pro výměnu klíčů třetích stran (KEK).

Poznámka:

Výrobci zařízení OEM, podniky a zákazníci mohou nalézt binární soubory PK, KEK, DB a DBX v Microsoftově zabezpečeném úložišti pro open-source spouštění. Binární soubory jsou formátované do očekávaného formátu EDKII, aby se snadno integrovaly do firmwaru.

Poznámka:

Microsoft Corporation KEK CA 2011 má vypršet v roce 2026 a všechny OEM musí vytvářet, podepisovat a odesílat aktualizace pro nový Microsoft Corporation KEK CA 2023 Microsoftu. Microsoftu to umožní aktualizovat zařízení na trhu pomocí nové certifikační autority Microsoft KEK, což umožňuje systémům pokračovat v přijímání aktualizací DATABÁZE a DBX po roce 2026. Pokyny a testovací doprovodné materiály najdete na stránce https://aka.ms/KEKUpdatePackage

Požadavky systému Windows pro rozhraní UEFI a zabezpečené spouštění najdete v požadavcích na certifikaci hardwaru systému Windows. Tento dokument nezavádí nové požadavky ani nepředstavuje oficiální program systému Windows. Je určena jako pokyny nad rámec požadavků na certifikaci, která pomáhá při vytváření efektivních a zabezpečených procesů pro vytváření a správu zabezpečených spouštěcích klíčů. To je důležité, protože zabezpečené spouštění rozhraní UEFI je založeno na použití infrastruktury veřejných klíčů k ověření kódu před povolením spuštění.

Čtenář by měl znát základy rozhraní UEFI, základní znalosti zabezpečeného spouštění (kapitola 27 specifikace UEFI) a model zabezpečení PKI.

Požadavky, testy a nástroje pro ověřování zabezpečeného spouštění ve Windows jsou dnes dostupné prostřednictvím sady Windows Hardware Certification Kit (HCK). Tyto prostředky HCK ale neřeší vytváření a správu klíčů pro nasazení Windows. Tento dokument se zabývá správou klíčů jako prostředkem, který pomáhá partnerům při nasazování klíčů používaných firmwarem. Není určen jako preskriptivní pokyny a neobsahuje žádné nové požadavky.

Na této stránce:

Tento dokument slouží jako výchozí bod při vývoji počítačů připravených pro zákazníky, nástrojů pro nasazení továrny a klíčových osvědčených postupů zabezpečení.

1. Zabezpečené spouštění, Windows a správa klíčů

Specifikace rozhraní UEFI (Unified Extensible Firmware Interface) definuje proces ověřování spouštění firmwaru s názvem Zabezpečené spouštění. Průmyslový standard Secure Boot definuje, jak firmware platformy spravuje certifikáty, ověřuje firmware a jak operační systém se zapojuje do tohoto procesu.

Zabezpečené spouštění je založené na procesu infrastruktury veřejných klíčů (PKI) pro ověřování modulů před tím, než se povolí jejich spuštění. Tyto moduly můžou zahrnovat ovladače firmwaru, optionální ROM, ovladače UEFI na disku, aplikace UEFI nebo zavaděče UEFI. Prostřednictvím ověřování imagí před spuštěním snižuje zabezpečené spouštění riziko útoků před spuštěním malwaru, jako jsou rootkity. Microsoft spoléhá na zabezpečené spouštění rozhraní UEFI ve Windows 8 a novějších v rámci architektury zabezpečení důvěryhodného spouštění, aby se zlepšilo zabezpečení platformy pro naše zákazníky. Zabezpečené spouštění se vyžaduje pro klientské počítače s Windows 8 a vyššími verzemi a pro Windows Server 2016, jak je definováno v požadavcích na kompatibilitu hardwaru s Windows.

Proces zabezpečeného spouštění funguje následovně a jak je znázorněno na obrázku 1:

  1. Komponenty spouštění firmwaru: Firmware ověřuje, že zavaděč operačního systému je důvěryhodný (Windows nebo jiný důvěryhodný operační systém.)
  2. Spouštěcí komponenty systému Windows: BootMgr, WinLoad, Spuštění jádra Systému Windows. Spouštěcí komponenty systému Windows ověřují podpis v jednotlivých komponentách. Nebudou načteny žádné nedůvěryhodné komponenty a místo toho se aktivuje náprava zabezpečeného spouštění.
    • Inicializace antivirového a antimalwarového softwaru: Tento software se kontroluje u speciálního podpisu vydaného Microsoftem, který ověřuje, že se jedná o důvěryhodný ovladač kritický pro spuštění a spustí se v rané fázi procesu spouštění.
    • Inicializace spouštěcího kritického ovladače: Podpisy pro všechny ovladače kritické pro spuštění se kontrolují jako součást ověření zabezpečeného spouštění ve WinLoadu.
  3. Další inicializace operačního systému
  4. Přihlašovací obrazovka systému Windows

Obrázek architektury integrity platformy

Obrázek 1: Architektura důvěryhodného spouštění systému Windows

Implementace zabezpečeného spouštění rozhraní UEFI je součástí architektury důvěryhodného spouštění od Microsoftu, která je představena ve Windows 8.1. Rostoucí trend vývoje zneužití malwaru se zaměřuje na spouštěcí cestu jako upřednostňovaný vektor útoku. Tato třída útoku je obtížná, protože antimalwarové produkty mohou být zakázány škodlivým softwarem, který jim brání v načítání zcela. Architektura důvěryhodného spouštění systému Windows a vytvoření „kořene důvěry“ se zabezpečeným spouštěním chrání zákazníka před škodlivým kódem spuštěným v bootovacím procesu tím, že zajistí, že se před samotným načtením operačního systému může spustit pouze podepsaný a certifikovaný "známý dobrý" kód a zavaděče.

1.1 infrastruktura Public-Key (PKI) a zabezpečené spouštění

Infrastruktura veřejných klíčů vytváří pravost a důvěryhodnost v systému. Zabezpečené spouštění využívá pkI ke dvěma účelům vysoké úrovně:

  1. Během spouštění zjistíte, jestli jsou moduly spouštění v rané fázi důvěryhodné.
  2. Aby bylo možné ověřit požadavky na služby, zahrnuje to úpravu databází Secure Boot a aktualizace firmwaru platformy.

Infrastruktura veřejných klíčů se skládá z:

  • Certifikační autorita (CA), která vydává digitální certifikáty.
  • Registrační autorita, která ověřuje identitu uživatelů, kteří požadují certifikát od certifikační autority.
  • Centrální adresář, do kterého se mají ukládat a indexovat klíče.
  • Systém správy certifikátů.

1.2 Kryptografie veřejného klíče

Kryptografie veřejného klíče používá dvojici matematicky souvisejících kryptografických klíčů, označovaných jako veřejný a privátní klíč. Pokud znáte jeden z klíčů, nemůžete snadno vypočítat, co je druhý klíč. Pokud se k šifrování informací používá jeden klíč, může tyto informace dešifrovat pouze odpovídající klíč. Pro zabezpečené spouštění se privátní klíč používá k digitálnímu podepisování kódu a veřejný klíč slouží k ověření podpisu v daném kódu, aby prokázal jeho pravost. Pokud dojde k ohrožení zabezpečení privátního klíče, systémy s odpovídajícími veřejnými klíči už nejsou zabezpečené. To může vést k útokům na spouštěcí sadu a poškodit pověst entity zodpovědné za zajištění zabezpečení privátního klíče.

V systému veřejného klíče zabezpečeného spouštění máte následující:

  • 1.2.1 Šifrování RSA 2048

    RSA-2048 je asymetrický kryptografický algoritmus. Prostor potřebný k uložení modulu RSA-2048 v nezpracované formě je 2048 bitů.

  • 1.2.2 Certifikát podepsaný svým držitelem

    Certifikát podepsaný privátním klíčem, který odpovídá veřejnému klíči certifikátu, se označuje jako certifikát podepsaný svým držitelem. Certifikáty kořenové certifikační autority spadají do této kategorie.

  • 1.2.3 Certifikační autorita

    Certifikační autorita vydává podepsané certifikáty, které potvrzuje identitu subjektu certifikátu a váže ji k veřejnému klíči obsaženému v certifikátu. Certifikační autorita certifikát podepíše pomocí svého privátního klíče. Vydá odpovídající veřejný klíč všem zúčastněným stranám v kořenovém certifikátu certifikační autority podepsaném svým držitelem.

    Certifikační autority (CA) v zabezpečeném spouštění zahrnují OEM (nebo jejich delegáty) a Microsoft. Certifikační autority generují páry klíčů, které tvoří kořen vztahu důvěryhodnosti, a pak pomocí privátních klíčů podepisují legitimní operace, jako jsou povolené moduly EFI pro předčasné spuštění a žádosti o údržbu firmwaru. Odpovídající veřejné klíče jsou dodávány do firmwaru rozhraní UEFI na počítačích s povoleným zabezpečeným spouštěním a slouží k ověření těchto operací.

    (Další informace o používání certifikačních autorit a výměn klíčů jsou snadno dostupné na internetu, které souvisí s modelem zabezpečeného spouštění.)

  • 1.2.4 Veřejný klíč

    Veřejný klíč platformy se dodává na počítači a je přístupný nebo "veřejný". V tomto dokumentu použijeme k označení veřejného klíče příponu "pub". Například PKpub označuje veřejnou polovinu PK.

  • 1.2.5 Privátní klíč

    Aby infrastruktura veřejných klíčů fungovala, je potřeba privátní klíč bezpečně spravovat. Mělo by být přístupné několika vysoce důvěryhodným jednotlivcům v organizaci a umístěným v fyzicky zabezpečeném umístění s pevnými omezeními zásad přístupu. V tomto dokumentu použijeme k označení privátního klíče příponu priv. Například PKpriv označuje privátní polovinu infrastruktury veřejných klíčů.

  • 1.2.6 Certifikáty

    Primárním použitím digitálních certifikátů je ověření původu podepsaných dat, jako jsou binární soubory atd. Běžným použitím certifikátů je zabezpečení internetových zpráv pomocí protokolu TLS (Transport Layer Security) nebo SSL (Secure Sockets Layer). Ověření podepsaných dat pomocí certifikátu informuje příjemce o původu dat a o tom, jestli byla při přenosu změněna.

    Digitální certifikát obecně obsahuje na vysoké úrovni rozlišující název (DN), veřejný klíč a podpis. Dn identifikuje entitu – například společnost – obsahující privátní klíč, který odpovídá veřejnému klíči certifikátu. Podpis certifikátu pomocí privátního klíče a umístění podpisu do certifikátu spojuje privátní klíč s veřejným klíčem.

    Certifikáty mohou obsahovat některé jiné typy dat. Například certifikát X.509 obsahuje formát certifikátu, sériové číslo certifikátu, algoritmus použitý k podepsání certifikátu, název certifikační autority, který certifikát vydal, název a veřejný klíč entity, která požaduje certifikát, a podpis certifikační autority.

  • 1.2.7 Řetězení certifikátů

    Od: Řetězy certifikátů:

    Kořenová certifikační autorita je podepsána sama sebou, ostatní jsou podepsané kořenovou certifikační autoritou

    Obrázek 2: Řetěz tří certifikátů

    Uživatelské certifikáty jsou často podepsané jiným privátním klíčem, například privátním klíčem certifikační autority. Jedná se o řetěz dvou certifikátů. Ověření, že certifikát uživatele je pravý, zahrnuje ověření jeho podpisu, který vyžaduje veřejný klíč certifikační autority z jeho certifikátu. Než se ale dá použít veřejný klíč certifikační autority, je potřeba ověřit uzavřený certifikát certifikační autority. Vzhledem k tomu, že certifikát certifikační autority je podepsaný svým držitelem, slouží veřejný klíč certifikační autority k ověření certifikátu.

    Uživatelský certifikát nemusí být podepsaný privátním klíčem kořenové certifikační autority. Může být podepsán privátním klíčem zprostředkujícího, jehož certifikát je podepsaný privátním klíčem certifikační autority. Jedná se o instanci řetězu tří certifikátů: uživatelský certifikát, zprostředkující certifikát a certifikát certifikační autority. Ale více než jeden zprostředkovatel může být součástí řetězu, takže řetězy certifikátů mohou mít libovolnou délku.

1.3 Požadavky na PKI zabezpečeného spouštění

Kořen důvěryhodnosti definovaný rozhraním UEFI se skládá z klíče platformy a všech klíčů, které OEM nebo ODM zahrnuje v jádru firmwaru. Zabezpečení před rozhraním UEFI a kořen důvěryhodnosti se neřeší procesem zabezpečeného spouštění rozhraní UEFI, ale publikacemi NATIONAL Institute of Standards and Technology (NIST) a Trusted Computing Group (TCG), na které odkazuje tento dokument.

  • 1.3.1 Požadavky na zabezpečené spouštění

    Při implementaci zabezpečeného spouštění je potřeba zvážit následující parametry:

    • Požadavky zákazníků
    • Požadavky na kompatibilitu hardwaru s Windows
    • Požadavky na generování a správu klíčů

    Je potřeba vybrat hardware pro správu klíčů zabezpečeného spouštění, jako jsou moduly hardwarového zabezpečení (HSM), zvážit zvláštní požadavky na počítače, které se mají dodávat vládám a dalším agenturám, a nakonec proces vytváření, naplnění a správy životního cyklu různých zabezpečených spouštěcích klíčů.

  • 1.3.2 Klíče související se zabezpečeným spouštěním

    Klíče používané pro zabezpečené spouštění jsou následující:

    pk, kek, db, dbx a firmware key, winrt key

    Obrázek 3: Klíče související se zabezpečeným spouštěním

    Obrázek 3 výše představuje podpisy a klíče v počítači se zabezpečeným spouštěním. Platforma je zabezpečená prostřednictvím klíče platformy, který výrobce OEM nainstaluje do firmwaru během výroby. Další klíče jsou používány zabezpečeným spouštěním k ochraně přístupu k databázím, které ukládají klíče, aby bylo možné povolit nebo zakázat spouštění firmwaru.

    Autorizovaná databáze (db) obsahuje veřejné klíče a certifikáty, které představují důvěryhodné součásti firmwaru a zavaděče operačního systému. Zakázaná databáze podpisů (dbx) obsahuje hodnoty hash škodlivých a ohrožených komponent a také ohrožené klíče a certifikáty a blokuje spuštění těchto škodlivých komponent. Síla těchto zásad je založená na podepisování firmwaru pomocí authenticode a infrastruktury veřejných klíčů (PKI). Infrastruktura veřejných klíčů je dobře zavedený proces pro vytváření, správu a odvolávání certifikátů, které během výměny informací navazují vztah důvěryhodnosti. Infrastruktura veřejných klíčů je jádrem modelu zabezpečení zabezpečeného spouštění.

    Níže jsou uvedeny další podrobnosti o těchto klíčích.

  • 1.3.3 Klíč platformy (PK)

    Podle bodu 27.5.1 rozhraní UEFI 2.3.1 Errata C klíč platformy vytvoří vztah důvěryhodnosti mezi vlastníkem platformy a firmwarem platformy. Vlastník platformy zaregistruje veřejnou polovinu klíče (PKpub) do firmwaru platformy podle bodu 7.2.1 rozhraní UEFI 2.3.1 Errata C. Tento krok přesune platformu do uživatelského režimu z režimu instalace. Microsoft doporučuje, aby klíč platformy byl typu EFI_CERT_X509_GUID s algoritmem RSA veřejného klíče, délkou veřejného klíče 2048 bitů a algoritmus podpisu sha256RSA. Vlastník platformy může použít typ EFI_CERT_RSA2048_GUID , pokud se jedná o úložný prostor. Veřejné klíče slouží ke kontrole podpisů, jak je popsáno výše v tomto dokumentu. Vlastník platformy může později použít privátní polovinu klíče (PKpriv):

    • Pokud chcete změnit vlastnictví platformy, musíte firmware umístit do definovaného režimu nastavení UEFI, který zakáže zabezpečené spouštění. Vraťte se do režimu nastavení jenom v případě, že je potřeba to udělat během výroby.
    • U zařízení s stolními počítači a servery můžou OEM spravovat pk a nezbytné infrastruktury veřejných klíčů, které jsou k němu přidruženy, nebo se rozhodnout používat pkovou sadu spravovanou Microsoftem pro OEM. Infrastruktura veřejných klíčů spravovaná Microsoftem je chráněná moduly hardwarového zabezpečení Microsoftu a spravovaná jako součást osvědčených postupů infrastruktury veřejných klíčů. Je to upřednostňovaný PK pro ekosystém Windows.

    1.3.3.1 Registrace nebo aktualizace klíče výměny klíčů (KEK) a připojení klíče platformy

    Vlastník platformy zaregistruje veřejnou polovinu klíče platformy (PKpub) voláním UEFI Boot Service SetVariable(), jak je uvedeno v oddílu 7.2.1 specifikace UEFI Spec 2.3.1 errata C a resetování platformy. Pokud je platforma v režimu nastavení, nový PKpub se podepíše svým protějškem PKpriv . Pokud je platforma v uživatelském režimu, musí být nová PKpub podepsaná pomocí aktuálního PKpriv. Pokud je veřejný klíč typu EFI_CERT_X509_GUID, toto musí být podepsáno přímo PKpriv, nikoli privátním klíčem žádného certifikátu vydaného na základě veřejného klíče.

    1.3.3.2 Vymazání klíče platformy

    Vlastník platformy vymaže veřejnou polovinu klíče platformy (PKpub) zavoláním služby UEFI Boot Service SetVariable() s velikostí proměnné 0 a resetováním platformy. Pokud je platforma v režimu nastavení, prázdná proměnná se nemusí ověřovat. Pokud je platforma v uživatelském režimu, musí být prázdná proměnná podepsána aktuálním PKpriv; Podrobnosti najdete v části 7.2 (Proměnné služby) ve specifikaci rozhraní UEFI 2.3.1 Errata C. Důrazně doporučujeme, aby se produkční PKpriv nikdy nepoužíval k podepsání balíčku k resetování platformy, protože to umožňuje programově zakázat zabezpečené spouštění. Jedná se především o předprodukční testovací scénář.

    Klíč platformy může být také vymazán pomocí zabezpečené metody specifické pro platformu. V takovém případě musí být režim nastavení globální proměnné také aktualizován na hodnotu 1.

    image: pk určuje režim nastavení nebo uživatelský režim.

    Obrázek 4: Diagram stavu klíče platformy

    1.3.3.3 Generování PK

    Podle doporučení UEFI musí být veřejný klíč uložen v nevývolatelném úložišti, které je na PC odolné proti manipulaci a odstranění. Privátní klíče zůstávají v bezpečí u partnera nebo v kanceláři zabezpečení OEM a na platformu se načtou jen veřejné klíče. Další podrobnosti najdete v části 2.2.1 a 2.3.

    Microsoft poskytuje PK pro OEM, aby eliminovala odpovědnost za údržbu a zabezpečení certifikátu PK. Veřejný klíč je chráněn moduly hardwarového zabezpečení (HSM) od Microsoftu a je spravován jako součást operací Microsoft PKI.

    Počet vygenerovaných pk je podle uvážení vlastníka platformy (OEM). Tyto klíče můžou být:

    1. Jeden na počítač. Mít jeden jedinečný klíč pro každé zařízení. To může být vyžadováno pro vládní agentury, finanční instituce nebo jiné serverové zákazníky s vysokými požadavky na zabezpečení. K vygenerování privátních a veřejných klíčů pro velký počet počítačů může vyžadovat dodatečné úložiště a výkon kryptografického zpracování. To zvyšuje složitost mapování zařízení s odpovídající PK při odesílání aktualizací firmwaru do zařízení v budoucnu. Existuje několik různých řešení HSM pro správu velkého počtu klíčů na základě dodavatele HSM. Další informace najdete v tématu Generování zabezpečených spouštěcích klíčů pomocí HSM.

    2. Jedna na model. Jeden klíč na jeden model počítače. Kompromisem je, že pokud dojde k ohrožení klíče, budou ohroženy všechny počítače v rámci stejného modelu. Microsoft to doporučuje pro stolní počítače.

    3. Jedna na produktovou řadu. Pokud dojde k ohrožení klíče, bude ohrožená celá řada produktů.

    4. Jeden na OEM. I když to může být nejjednodušší nastavit, pokud je klíč ohrožen, bude každý počítač, který vyrábíte, zranitelný. Aby se urychlila operace na výrobním podlaží, PK a potenciálně další klíče by mohly být předem vygenerovány a uloženy v bezpečném umístění. Tyto hodnoty lze později načíst a použít v montážním řádku. Kapitoly 2 a 3 obsahují další podrobnosti.

    1.3.3.4 Opětovné vytvoření klíče PK

    To může být potřeba, pokud dojde k ohrožení infrastruktury veřejných klíčů nebo jako požadavek zákazníka, který z bezpečnostních důvodů může rozhodnout o registraci vlastní infrastruktury veřejných klíčů.

    Opětovné vytvoření klíče je možné provést buď pro model zařízení nebo počítač na základě toho, jakou metodu jste vybrali k vytvoření veřejného klíče. Všechny novější počítače budou podepsány nově vytvořeným veřejným klíčem.

    Aktualizace PK na produkčním počítači by vyžadovala buď aktualizaci proměnné podepsané stávající PK, která by nahradila PK, nebo balíček aktualizace firmwaru. OEM může také vytvořit balíček SetVariable() a distribuovat ho pomocí jednoduché aplikace, jako je PowerShell, který pouze změní PK. Balíček aktualizace firmwaru by byl podepsán zabezpečeným klíčem aktualizace firmwaru a ověřen firmwarem. Pokud provádíte aktualizaci firmwaru ke aktualizaci PK, měli byste dbát na to, aby byly zachovány KEK, db a dbx.

    Na všech PC se doporučuje nepoužívat PK jako klíč pro bezpečnou aktualizaci firmwaru. Pokud dojde k ohrožení PKpriv, tak je ohrožený i zabezpečený klíč pro aktualizaci firmwaru, protože jsou totožné. V takovém případě aktualizace pro registraci nového PKpub nemusí být možná, protože proces aktualizace byl také ohrožen.

    Na počítačích SOC existuje další důvod, proč PK jako zabezpečený klíč aktualizace firmwaru nepoužívat. Důvodem je to, že klíč aktualizace zabezpečeného firmwaru se trvale vypálí do pojistk na počítačích, které splňují požadavky na certifikaci hardwaru systému Windows.

  • 1.3.4 Klíč výměny klíčů (KEK) Klíče výměny klíčů vytvářejí vztah důvěryhodnosti mezi operačním systémem a firmwarem platformy. Každý operační systém (a potenciálně každá aplikace třetí strany, která potřebuje komunikovat s firmwarem platformy), zaregistruje do firmwaru platformy veřejný klíč (KEKpub).

    1.3.4.1 Zápis klíčů pro výměnu klíčů

    Klíče výměny klíčů jsou uložené v databázi podpisů, jak je popsáno v databázích podpisů 1.4 (Db a Dbx). Podpisová databáze je uložená jako ověřená proměnná UEFI.

    Vlastník platformy zaregistruje klíče výměny klíčů buď voláním SetVariable(), jak je uvedeno v části 7.2(Variable Services) ve specifikaci UEFI 2.3.1 Errata C. se EFI_VARIABLE_APPEND_WRITE sadou atributů a parametrem Data obsahujícím nové klíče nebo načtením databáze pomocí getVariable(), připojením nového klíče k existujícím klíčům a následným zápisem databáze pomocí SetVariable(), jak je uvedeno v části 7.2 (Variable Services) ve specifikaci rozhraní UEFI 2.3.1 Errata C bez EFI_VARIABLE_APPEND_WRITE sady atributů.

    Pokud je platforma v režimu nastavení, proměnná databáze podpisu nemusí být podepsána, ale parametry volání SetVariable() musí být stále připravené tak, jak je uvedeno pro ověřené proměnné v oddílu 7.2.1. Pokud je platforma v uživatelském režimu, musí být podpisová databáze podepsaná pomocí aktuálního PKpriv.

    1.3.4.2 Vymazání KEK

    Klíč KEK je možné vymazat (odstranit). Upozorňujeme, že pokud na platformě není nainstalovaná infrastruktura veřejných klíčů, není nutné podepsat "jasné" požadavky. Pokud jsou podepsané, pak k vymazání klíče KEK vyžaduje balíček podepsaný pk a k vymazání databáze nebo dbx vyžaduje balíček podepsaný jakoukoli entitou, která je v klíči KEK.

    1.3.4.3 Microsoft KEK

    Následující certifikát Microsoft KEK je nutný k povolení odvolání chybných imagí aktualizací dbx a případně aktualizací databáze pro přípravu na novější podepsané image systému Windows.

  1. Microsoft Corporation KEK 2K CA 2023

    • Hash certifikátu SHA-1: 459AB6FB5E284D272D5E3E6ABC8ED663829D632B.
    • GUID vlastníka podpisu: {77fa9abd-0359-4d32-bd60-28f4e78f784b}.
    • Společnost Microsoft poskytne partnerům certifikát, který lze přidat jako podpis typu EFI_CERT_X509_GUID nebo jako podpis typu EFI_CERT_RSA2048_GUID.
    • Certifikát Microsoft KEK lze stáhnout z: https://go.microsoft.com/fwlink/?linkid=2239775.

1.3.4.4 KEKDefault Dodavatel platformy musí zadat výchozí sadu klíčů výměny klíčů v proměnné KEKDefault. Další informace najdete v části specifikace rozhraní UEFI 27.3.3.

1.3.4.5 OEM/3rd party KEK - přidání více KEKů

Zákazníci a vlastníci platforem nemusí mít vlastní klíč KEK. Na počítačích s operačním systémem, který není Windows RT, může výrobce OEM mít další sady KEK, které umožňují dalším výrobcům OEM nebo důvěryhodným třetím stranám kontrolu nad databází db a dbx.

  • 1.3.5 Klíč aktualizace firmwaru zabezpečeného spouštěníKlíč aktualizace zabezpečeného firmwaru slouží k podepsání firmwaru, když je potřeba ho aktualizovat. Tento klíč musí mít minimální sílu klíče RSA-2048. Všechny aktualizace firmwaru musí být bezpečně podepsané výrobcem OEM, jejich důvěryhodným delegátem, jako je ODM nebo IBV (nezávislý dodavatel systému BIOS), nebo zabezpečenou podpisovou službou.

    Podle publikace NIST 800-147, aktualizace firmwaru pro pole musí podporovat všechny prvky pokynů.

    Veškerá aktualizace úložiště flash firmwaru musí být podepsána tvůrcem.

    Firmware musí kontrolovat podpis aktualizace.

  • 1.3.6 Vytvoření klíčů pro zabezpečenou aktualizaci firmwaru

    Stejný klíč bude použit k podepisování všech aktualizací firmwaru, protože veřejná polovina bude uložená na počítači. Aktualizaci firmwaru můžete také podepsat klíčem, který se váže na klíč pro zabezpečenou aktualizaci firmwaru.

    Na jeden počítač může být jeden klíč, například PK nebo jeden na model nebo jeden na produktovou řadu. Pokud je na každém PC jeden klíč, znamenalo by to, že bude potřeba vygenerovat miliony jedinečných aktualizačních balíčků. Zvažte prosím na základě dostupnosti zdrojů, jakou metodu by pro vás fungovala. Dobrým kompromisem je mít klíč na model nebo produktovou řadu.

    Veřejný klíč aktualizace zabezpečeného firmwaru (nebo jeho hodnota hash za účelem úspory místa) by byl uložen v některém chráněném úložišti na platformě – obecně chráněné flash (PC) nebo jednorázové programovatelné pojistky (SOC).

    Pokud je uložena pouze hodnota hash tohoto klíče (pro úsporu místa), aktualizace firmwaru bude obsahovat klíč a první fáze procesu aktualizace ověří, že veřejný klíč v aktualizaci odpovídá hodnotě hash uložené na platformě.

    Kapsle jsou prostředky, pomocí kterých může operační systém předávat data do prostředí UEFI v rámci restartování. Systém Windows volá UEFI UpdateCapsule() k doručování aktualizací systémového a počítačového firmwaru. Při spuštění před voláním ExitBootServices(),Windows předá všechny nové aktualizace firmwaru nalezené ve Windows Driver Store do UpdateCapsule(). Firmware systému UEFI může tento proces použít k aktualizaci systémového a počítačového firmwaru. Díky využití této podpory firmwaru Windows může OEM spoléhat na stejný běžný formát a proces aktualizace firmwaru pro systém i firmware počítače. Firmware musí implementovat tabulku ACPI ESRT, aby podporoval rozhraní UEFI UpdateCapsule() pro Windows.

    Podrobnosti o implementaci podpory pro platformu aktualizace firmwaru Windows UEFI najdete v následující dokumentaci: Platforma aktualizace firmwaru UEFI systému Windows.

    Aktualizační kapsle mohou být v paměti nebo na disku. Systém Windows podporuje aktualizace paměti.

    1.3.6.1 Kapsle (kapsle v paměti)

    Následuje tok událostí, které slouží k fungování kapsle aktualizace v paměti.

    1. Kapsle je vložena do paměti aplikací v operačním systému.
    2. Událost poštovní schránky je nastavená tak, aby informovala systém BIOS o čekající aktualizaci.
    3. Počítač se restartuje, ověří obraz kapsle a aktualizaci provádí BIOS.

  • 1.3.7 Pracovní postup typické aktualizace firmwaru

    1. Stáhněte a nainstalujte ovladač firmwaru.
    2. Restartujte.
    3. Zavaděč operačního systému zjistí a ověří firmware.
    4. Zavaděč operačního systému předá binární blob k rozhraní UEFI.
    5. Rozhraní UEFI provádí aktualizaci firmwaru (tento proces vlastní dodavatel čipu).
    6. Detekce zavaděče operačního systému úspěšně dokončena.
    7. Operační systém dokončí spouštění.

1.4 Podpisové databáze (Db a Dbx)

  • 1.4.1 Povolená databáze podpisů (db)

    Obsah databáze EFI _IMAGE_SECURITY_DATABASE určuje, jaké image jsou při ověřování načtených imagí důvěryhodné. Databáze může obsahovat více certifikátů, klíčů a hodnot hash, aby bylo možné identifikovat povolené image.

    Aby mohl zavaděč operačního systému Windows načíst, musí být do databáze zahrnutý následující certifikát:

  1. Windows UEFI CA 2023
    • Hash certifikátu SHA-1: 45A0FA32604773C82433C3B7D59E7466B3AC0C67.
    • GUID vlastníka podpisu: {77fa9abd-0359-4d32-bd60-28f4e78f784b}.
    • Společnost Microsoft poskytne partnerům certifikát, který lze přidat jako podpis typu EFI_CERT_X509_GUID nebo jako podpis typu EFI_CERT_RSA2048_GUID.
    • Windows UEFI CA 2023 lze stáhnout zde: https://go.microsoft.com/fwlink/?linkid=2239776.

S výjimkou systémů, které jsou uzamčeny pouze pro spouštění systému Windows, by výrobce OEM měl zvážit zahrnutí certifikačních autorit UEFI třetích stran a certifikační autority Microsoft Option ROM, aby mohly ovladače A aplikace UEFI od třetích stran běžet na počítači bez nutnosti dalších kroků pro uživatele.

  1. Microsoft Corporation UEFI CA 2011

    • Hash certifikátu SHA-1: 46DEF63B5CE61CF8BA0DE2E6639C1019D0ED14F3.
    • GUID vlastníka podpisu: {77fa9abd-0359-4d32-bd60-28f4e78f784b}.
    • Společnost Microsoft poskytne partnerům certifikát, který lze přidat jako podpis typu EFI_CERT_X509_GUID nebo jako podpis typu EFI_CERT_RSA2048_GUID.
    • Microsoft Corporation UEFI CA 2011 lze stáhnout zde: https://go.microsoft.com/fwlink/p/?linkid=321194.

  2. Microsoft UEFI CA 2023

    • Hash certifikátu SHA-1: B5EEB4A6706048073F0ED296E7F580A790B59EAA.
    • GUID vlastníka podpisu: {77fa9abd-0359-4d32-bd60-28f4e78f784b}.
    • Společnost Microsoft poskytne partnerům certifikát, který lze přidat jako podpis typu EFI_CERT_X509_GUID nebo jako podpis typu EFI_CERT_RSA2048_GUID.
    • Microsoft UEFI CA 2023 lze stáhnout zde: https://go.microsoft.com/fwlink/?linkid=2239872.

  3. Microsoft Option ROM UEFI CA 2023

    • Hash certifikátu SHA-1: 3FB39E2B8BD183BF9E4594E72183CA60AFCD4277.
    • GUID vlastníka podpisu: {77fa9abd-0359-4d32-bd60-28f4e78f784b}.
    • Společnost Microsoft poskytne partnerům certifikát, který lze přidat jako podpis typu EFI_CERT_X509_GUID nebo jako podpis typu EFI_CERT_RSA2048_GUID.
    • Microsoft Option ROM UEFI CA 2023 lze stáhnout zde: https://go.microsoft.com/fwlink/?linkid=2284009.

  • 1.4.2 DbDefault: Dodavatel platformy musí poskytnout výchozí sadu položek pro podpisovou databázi v proměnné dbDefault. Další informace najdete v části 27.5.3 ve specifikaci rozhraní UEFI.

  • 1.4.3 Zakázaná databáze podpisů (dbx)

    EFI_IMAGE_SIGNATURE_DATABASE1 Obsah dbx musí být zkontrolován při ověřování obrázků před kontrolou databáze a všechny shody musí bránit spuštění image. Databáze může obsahovat více certifikátů, klíčů a hodnot hash, aby bylo možné identifikovat zakázané image. Požadavky na certifikaci hardwaru systému Windows uvádějí, že musí být k dispozici dbx, proto lze jakoukoli fiktivní hodnotu, například hash SHA-256 0, použít jako bezpečný zástupný symbol, dokud společnost Microsoft nezačne dodávat aktualizace dbx. Kliknutím sem stáhnete nejnovější seznam odvolaných certifikátů UEFI od Microsoftu.

  • 1.4.4 DbxDefault: Dodavatel platformy může poskytnout výchozí sadu položek pro podpisovou databázi v proměnné dbxDefault. Další informace najdete v části 27.5.3 ve specifikaci rozhraní UEFI.

1.5 Klíče vyžadované pro zabezpečené spouštění na všech počítačích

Poznámka:

Výrobci zařízení OEM, podniky a zákazníci mohou nalézt binární soubory PK, KEK, DB a DBX v Microsoftově zabezpečeném úložišti pro open-source spouštění. Binární soubory jsou formátované do očekávaného formátu EDKII, aby se snadno integrovaly do firmwaru.

Název klíče nebo databáze Proměnná Vlastník Poznámky

PKpub

PK

Výrobce OEM

PK – pouze 1. Musí být RSA 2048 nebo silnější.

https://go.microsoft.com/fwlink/?linkid=2255361

Microsoft Corporation KEK 2K CA 2023

KEK

Microsoft

Umožňuje aktualizace db a dbx:

https://go.microsoft.com/fwlink/p/?linkid=2239775.

Windows UEFI CA 2023

databáze

Microsoft

Tato certifikační autorita v databázi podpisů (db) umožňuje spuštění systému Windows: https://go.microsoft.com/fwlink/?LinkId=2239776

Zakázaná databáze podpisů

dbx

Microsoft

Seznam známých chybných klíčů, certifikačních autorit nebo imagí od Microsoftu

Zabezpečený klíč aktualizace firmwaru

Výrobce OEM

Doporučuje se, aby tento klíč byl jiný než PK.

Tabulka 1: Klíče a databáze potřebné pro zabezpečené spouštění

2. Řešení správy klíčů

Níže jsou uvedeny některé metriky, které jsme použili k porovnání.

2.1 Použité metriky

Následující metriky vám můžou pomoct vybrat počítač HSM na základě požadavků specifikace UEFI 2.3.1 Errata C a vašich potřeb.

  • Podporuje RSA 2048 nebo vyšší? - Specifikace UEFI 2.3.1 Errata C doporučuje klíče, aby byly RSA-2048 nebo lepší.
  • Má možnost generovat klíče a znaménko?
  • Kolik klíčů může uložit? Ukládá klíče na HSM nebo na připojeném serveru?
  • Metoda ověřování pro získání klíče Některé počítače umožňují mít více entit ověřování, aby byly dostupné pro obnovení klíče.

Cenotvorba

  • Jaký je cenový bod? Moduly hardwarového zabezpečení můžou být v rozsahu od 1 500 Kč do 70 000 USD v závislosti na dostupných funkcích.

Výrobní prostředí

  • Rychlost provozu na výrobním patře. Kryptografické procesory můžou urychlit vytváření klíčů a přístup.
  • Snadné nastavení, nasazení, údržba.
  • Vyžaduje se sada dovedností a školení?
  • Přístup k síti pro zálohování a vysokou dostupnost

Standardy a dodržování předpisů

  • Jakou úroveň dodržování předpisů FIPS má? Je odolný proti manipulaci?
  • Podpora jiných standardů, například rozhraní MS Crypto API.
  • Splňuje požadavky státní správy a dalších agentur?

Spolehlivost a zotavení po havárii

  • Umožňuje zálohování klíčů?

    Zálohy je možné uložit na místě v bezpečném umístění, které je jiné fyzické umístění než počítač certifikační autority a modul hardwarového zabezpečení (HSM) a /nebo v umístění mimo pracoviště.

  • Umožňuje vysokou dostupnost pro zotavení po havárii?

2.2 Možnosti správy klíčů

  • 2.2.1 Modul hardwarového zabezpečení (HSM)

    Na základě výše uvedených kritérií je toto pravděpodobně nejvhodnější a nejbezpečnější řešení. Většina HSM splňuje standardy FIPS 140–2 stupeň 3. Dodržování předpisů úrovně 3 FIPS 140-2 je přísné na ověřování a vyžaduje, aby klíče nebyly exportovány nebo importovány z HSM.

    Podporují několik způsobů úložiště klíčů. Můžou být uložené buď místně na samotném HSM, nebo na serveru připojeném k HSM. Na serveru jsou klíče šifrované a uložené a je vhodnější pro řešení, která vyžadují uložení velkého množství klíčů.

    Zásady zabezpečení kryptografického modulu určují fyzickou zásadu zabezpečení, včetně mechanismů fyzického zabezpečení implementovaných v kryptografickém modulu, jako jsou manipulační zapečetění, zámky, manipulační reakce a přepínače zeroizace a alarmy. Umožňuje také určit akce vyžadované operátory, aby se zajistilo, že je zachováno fyzické zabezpečení, jako je pravidelná kontrola plomb prokazujících zásah nebo testování reakce na neoprávněnou manipulaci a přepínačů pro vymazání.

    • 2.2.1.1 Modul hardwarového zabezpečení sítě

      Toto řešení je nejlepší ve své třídě z hlediska zabezpečení, dodržování standardů, generování klíčů, úložiště a načítání. Většina těchto počítačů podporuje vysokou dostupnost a umožňuje zálohování klíčů.

      Náklady na tyto produkty mohou být v desítkách tisíc dolarů na základě dalších služeb, které nabízejí.

    • 2.2.1.2 Samostatný HSM

      Tyto funkce fungují skvěle se samostatnými servery. Můžete použít rozhraní MICROSOFT CAPI a CNG nebo jakékoli jiné zabezpečené rozhraní API podporované modulem HSM. Tyto moduly HSM jsou k dispozici v různých formátech podporujících sběrnice USB, PCIe a PCMCIA.

      Volitelně podporují zálohování klíčů a vysokou dostupnost.

  • 2.2.2 Vlastní poskytovatelé řešení

    Kryptografie s veřejným klíčem může být náročná a vyžaduje pochopení kryptografických konceptů, které můžou být nové. Existují vlastní poskytovatelé řešení, kteří by mohli pomoct se zajištěním zabezpečeného spouštění pro práci ve výrobním prostředí.

    Existují různé typy vlastních řešení, které nabízejí dodavatelé systému BIOS, společnosti HSM a konzultační firmy v oblasti PKI, aby PKI zabezpečeného spouštění fungovalo ve výrobním prostředí.

    Někteří poskytovatelé jsou uvedeni níže:

  • 2.2.3 Trusted Platform Module (TPM)

    Čip TPM (Trusted Platform Module) je hardwarový čip na základní desce, který ukládá kryptografické klíče používané k šifrování. Mnoho počítačů obsahuje čip TPM, ale pokud ho počítač nemá, není realistické ho přidat. Po povolení může modul Trusted Platform Module pomoct zabezpečit úplné šifrování disků, jako jsou funkce Nástroje Microsoft BitLocker. Pevné disky jsou zamknuté nebo zapečetěné, dokud počítač neskončí proces ověření systému nebo ověřování.

    Čip TPM může generovat, ukládat a chránit klíče používané v procesu šifrování a dešifrování.

    Nevýhodou čipů TPM je, že nemusí mít rychlé kryptografické procesory pro urychlení zpracování ve výrobním prostředí. Nejsou také vhodné pro ukládání velkého počtu klíčů. Zálohování, vysoká dostupnost a dodržování standardů FIPS 140-2 úrovně 3 nemusí být dostupné.

  • 2.2.4 Čipové karty

    Čipová karta může generovat a ukládat klíče. Sdílejí některé funkce, které HSM podporují, jako je ověřování a kontrola pravopisu, ale neobsahují velké úložiště klíčů ani zálohování. Vyžadují ruční zásah a nemusí být vhodné pro automatizaci a použití v produkčním prostředí, protože výkon může být nízký.

    Nevýhody chytrých karet jsou podobné TPM. Nemusí mít rychlé kryptografické procesory, aby urychlily zpracování ve výrobním prostředí. Nejsou také vhodné pro ukládání velkého počtu klíčů. Zálohování, vysoká dostupnost a dodržování standardů FIPS 140-2 úrovně 3 nemusí být dostupné.

  • 2.2.5 Rozšířený ověřovací certifikát

    Certifikáty EV jsou certifikáty s vysokou zárukou, jejichž privátní klíče jsou uložené v hardwarových tokenech. Toto pomáhá stanovit pevnější praktiky správy klíčů. Certifikáty EV mají stejné nevýhody jako čipové karty.

  • 2.2.6 Přístupy zaměřené na software (NEDOPORUČUJE SE)

    Pro správu klíčů používejte kryptografická rozhraní API. To může zahrnovat uložení klíče do kontejneru klíčů na šifrovaný pevný disk a možné pro další sandboxování a zabezpečení použít virtuální počítač.

    Tato řešení nejsou tak bezpečná jako použití HSM a otevírají větší prostor pro útok.

    2.2.6.1 Makecert (NEDOPORUČUJE SE)

    Makecert je nástroj Microsoft a lze ho použít následujícím způsobem pro generování klíčů. Ke snížení plochy útoku možná budete muset počítač fyzicky izolovat. Počítač, na který je zapnutý PKpriv, by neměl být připojený k síti. Měla by být v zabezpečeném umístění a v ideálním případě by měla alespoň používat čtečku čipových karet, pokud ne skutečný HSM.

    makecert -pe -ss MY -$ individual -n "CN=your name here" -len 2048 -r

    Další informace najdete v tématu Nástroj pro vytvoření certifikátu (Makecert.exe).

    Toto řešení se nedoporučuje.

2.3 Generování klíčů HSM a úložiště pro zabezpečené spouštěcí klíče

  • 2.3.1 Ukládání privátních klíčů

    Požadavek na místo pro každý klíč RSA-2048 je 2048 bitů. Skutečné umístění úložiště klíčů závisí na zvoleném řešení. HSM je dobrým způsobem ukládání klíčů.

    Fyzické umístění počítačů v továrně by mělo být chráněná oblast s omezeným přístupem uživatelů, jako je zabezpečená klece.

    V závislosti na vašich požadavcích mohou být tyto klíče také uloženy v různých geografických umístěních nebo zálohovat v jiném umístění.

    Požadavky na opětovné vytvoření klíče pro tyto klíče se můžou lišit podle zákazníka (viz příloha A pro pokyny k opětovnému vytvoření klíče certifikační autority federálního mostu).

    Ty se dají udělat jednou za rok. Možná budete muset mít k těmto klíčům přístup až 30 let (v závislosti na požadavcích na opětovné vytvoření klíče atd.).

  • 2.3.2 Načtení privátních klíčů

    Může být potřeba klíče získat z mnoha důvodů.

    1. Veřejný klíč může být potřeba obnovit, aby bylo možné vydat aktualizovaný veřejný klíč kvůli kompromitaci nebo dodržování předpisů státní správy nebo jiných agentur.
    2. KEKpri se použije k aktualizaci databáze a dbx.
    3. Zabezpečený klíč aktualizace firmwaru –pri se použije k podepisování novějších aktualizací.

  • 2.3.3 Ověřování

    Ověřování podle FIPS 140-2 je založeno na úrovni přístupu.

    Úroveň 2

    Úroveň zabezpečení 2 vyžaduje minimálně ověřování na základě role, ve kterém kryptografický modul ověřuje autorizaci operátora, aby převzal konkrétní roli a provedl odpovídající sadu služeb.

    Úroveň 3

    Úroveň zabezpečení 3 vyžaduje mechanismy ověřování založené na identitách, což zvyšuje zabezpečení poskytované mechanismy ověřování na základě role určené pro úroveň zabezpečení 2. Kryptografický modul ověřuje identitu operátora a ověřuje, že identifikovaný operátor má oprávnění převzít konkrétní roli a provést odpovídající sadu služeb.

    Počítače, jako je HSM, podporují úroveň zabezpečení 3, která vyžaduje ověřování založené na identitě k m. To znamená, že entitám K se udělí přístup k HSM pomocí tokenu, ale v daném okamžiku musí být k dispozici alespoň k z tokenů m, aby ověřování fungovalo, aby bylo možné získat přístup k privátním klíčům z HSM.

    Například k přístupu k HSM by měly být 3 z 5 tokenů autentizovány. Tito členové můžou být bezpečnostní pracovníci, autorizátoři transakcí nebo členové vrcholového vedení.

    Tokeny HSM

    Můžete mít zásadu pro HSM, která vyžaduje, aby token existoval:

    • Lokálně

    • Vzdáleně

    • Nakonfigurováno tak, aby bylo automatizované

    Osvědčeným postupem je použít kombinaci tokenu a hesla na základě tokenu.

2.4 Zabezpečené spouštění a podepisování třetích stran

  • 2.4.1 Podepisování ovladačů UEFI

    Ovladače rozhraní UEFI musí být podepsané certifikační autoritou nebo klíčem v databázi, jak je popsáno jinde v dokumentu, nebo musí mít hodnotu hash image ovladače, která je součástí databáze. Microsoft bude poskytovat službu podepisování ovladačů UEFI pomocí certifikační autority Microsoft UEFI CA 2023, která je podobná službě podepisování ovladačů WHQL. Všechny ovladače podepsané tímto příkazem budou bez problémů fungovat na všech počítačích, které zahrnují certifikační autoritu Microsoft UEFI. OEM může také podepisovat důvěryhodné ovladače a zahrnout certifikační autoritu OEM do databáze nebo zahrnout hodnoty hash ovladačů do databáze. Ve všech případech se ovladač UEFI (Option ROM) nespustí, pokud není v databázi důvěryhodný.

    Všechny ovladače, které jsou součástí image firmwaru systému, není nutné znovu ověřit. Být součástí celkové image systému poskytuje dostatečnou jistotu, že ovladač je na počítači důvěryhodný.

    Společnost Microsoft tuto možnost zpřístupní všem uživatelům, kteří chtějí podepisovat ovladače UEFI. Tento certifikát je součástí testů zabezpečeného spouštění Systému Windows HCK. Sledujte [tento blog]((https://blogs.msdn.microsoft.com/windows_hardware_certification/2013/12/03/microsoft-uefi-ca-signing-policy-updates/), kde najdete více informací o zásadách podepisování a aktualizacích UEFI CA.

  • 2.4.2 Zavaděče spouštění

    Podpisový certifikát ovladače Microsoft UEFI lze použít k podepisování jiných operačních systému. Například zavaděč Linuxu ve Fedora bude podepsán.

    Toto řešení nevyžaduje přidání dalších certifikátů do databáze klíčů. Kromě nákladově efektivních je možné ji použít pro libovolnou distribuci Linuxu. Toto řešení by fungovalo pro jakýkoli hardware, který podporuje Systém Windows, aby byl užitečný pro širokou škálu hardwaru.

    UEFI-CA lze stáhnout zde: https://go.microsoft.com/fwlink/p/?LinkID=321194. Následující odkazy obsahují další informace o podepisování a odesílání rozhraní Windows HCK UEFI:

3. Souhrn a zdroje

Tato část má v úmyslu shrnout výše uvedené části a zobrazit krok za krokem:

  1. Vytvoření zabezpečené certifikační autority nebo identifikace partnera pro bezpečné generování a ukládání klíčů

    Pokud nepoužíváte řešení třetí strany:

    1. Nainstalujte a nakonfigurujte software HSM na serveru HSM. Pokyny k instalaci najdete v referenční příručce k HSM. Server bude buď připojený k samostatnému nebo síťovému HSM.

      Informace o konfiguraci HSM najdete v oddílu 2.2.1, 2.3 a dodatku C.

      Většina hsm nabízí dodržování předpisů FIPS 140–2 úrovně 2 a 3. Nakonfigurujte HSM pro dodržování předpisů úrovně 2 nebo 3. Dodržování předpisů úrovně 3 má přísnější požadavky ohledně ověřování a přístupu k klíčům, a proto je bezpečnější. Doporučuje se úroveň 3.

    2. Nakonfigurujte HSM pro zajištění vysoké dostupnosti, zálohování a ověřování. Projděte si referenční příručku k HSM.

      Postupujte podle pokynů poskytovatele HSM k nastavení HSM pro zajištění vysoké dostupnosti a zálohování.

      Síťové hsmy mají obvykle více síťových portů pro oddělení provozu; umožňuje serveru komunikovat se síťovými HSM v síti odděleně od běžné produkční sítě.

      Jakmile jsou členové bezpečnostního týmu identifikováni a jsou jim přiřazeny tokeny. Budete muset nastavit hardwarový bezpečnostní modul (HSM) pro k-z-m ověřování.

    3. Zabezpečené spouštěcí klíče a certifikáty před generováním Viz oddíly 1.3 až 1.5

      Pomocí rozhraní API HSM můžete předem vygenerovat klíče a certifikáty pro PK a Firmware Update Key.

      Povinné – PK (doporučujeme 1 na model), klíč aktualizace firmwaru (doporučujeme 1 na model), Microsoft KEK, Db, DbxNOTE: Microsoft KEK, db a dbx nemusí být generovány výrobcem OEM a jsou uvedené pro úplnost. Volitelné – databáze KEK od výrobce OEM/3rd party, dbx a všechny další klíče, které by se dostaly do databáze OEM.

  2. Aplikujte image Windows na počítač.

  3. Nainstalujte databázi Microsoftu a dbx. Viz oddíl 1.3.6 a příloha B – rozhraní API zabezpečeného spouštění.

    1. Nainstalujte Windows UEFI CA 2023 do databáze.

    2. Nainstalujte prázdný dbx, pokud ho Microsoft neposkytuje. Systém Windows při prvním restartování automaticky aktualizuje DBX na nejnovější dbX prostřednictvím služby Windows Update.

    Poznámka:

    Použijte rutiny PowerShellu, které jsou součástí testů Windows HCK nebo používají metody poskytované dodavatelem systému BIOS.

  4. Nainstalujte Microsoft KEK. Viz oddíl 1.3.3.

    Instalace Microsoft KEK do databáze UEFI KEK

    Upozornění

    Použijte rutiny PowerShellu, které jsou součástí testů Windows HCK nebo používají metody poskytované dodavatelem systému BIOS.

  5. Volitelný krok – komponenty zabezpečeného spouštění od výrobce OEM/třetí strany Viz oddíl 1.3.4 a 1.4.

    1. Potřebujete zjistit, zda máte potřebu vytvořit KEK, db a dbx od OEM nebo třetí strany.

    2. Podepište OEM/ třetí strany db a dbx s OEM/ třetí strany KEK (vytvořené dříve) pomocí HSM API.

    3. Nainstalujte KEK, db a dbx od OEM/externího výrobce.

  6. Podepisování ovladačů UEFI – viz oddíl 2.4.

    Pokud podporujete přídavné karty nebo ostatní ovladače UEFI, aplikace nebo zavaděče, nainstalujte do UEFI databáze Microsoft UEFI CA 2023 a Microsoft Corporation UEFI CA 2011.

  7. Klíč aktualizace firmwaru zabezpečeného spouštění – viz oddíl 1.3.5.

    1. Pouze počítače s jiným systémem než Windows RT: Nainstalujte veřejný klíč aktualizace zabezpečeného firmwaru nebo jeho hodnotu hash, abyste ušetřili místo.

    2. Pouze v případě SoC možná budete muset postupovat jinak, například zapsat klíč zabezpečené aktualizace firmwaru: veřejný nebo jeho hash.

  8. Povolení zabezpečeného spouštění Viz příloha B – zabezpečená spouštěcí rozhraní API.

    1. Nainstalujte OEM/ODM PKpub (je preferován certifikát, ale klíč je také možný) do UEFI PK.

    2. Zaregistrujte PK pomocí rozhraní API Secure Boot. Počítač by teď měl být povolený pro zabezpečené spouštění.

    Poznámka:

    Pokud nainstalujete PK na konci, není nutné, aby MS KEK, db, dbx byly podepsány – žádné informace o podpisu (SignerInfo) nemusí být přítomny. Toto je zkratka.

  9. Testování zabezpečeného spouštění: Podle pokynů proveďte všechny proprietární testy a testy Windows HCK. Viz příloha B – zabezpečená spouštěcí rozhraní API.

  10. Plavidlová platforma: PKpriv se pravděpodobně už nikdy nebude používat, uchovejte ji v bezpečí.

  11. Údržba: Budoucí aktualizace firmwaru jsou bezpečně podepsané pomocí "privátního" klíče aktualizace zabezpečeného firmwaru pomocí podpisové služby.

3.1 Zdroje

Dokument White Paper o strategiích zabezpečení – https://go.microsoft.com/fwlink/p/?linkid=321288

Odeslání Windows HCK –https://go.microsoft.com/fwlink/p/?linkid=321287

Příloha A – kontrolní seznam infrastruktury veřejných klíčů zabezpečeného spouštění pro výrobu

Níže je uvedený kontrolní seznam vysoké úrovně, který shrnuje kroky potřebné k povolení zabezpečeného spouštění na počítačích s jiným systémem než Windows RT.

Nastavení zabezpečeného spouštění

  1. Definujte strategii zabezpečení (identifikujte hrozby, definujte proaktivní a reaktivní strategii) podle dokumentu white paper v části 4.

  2. Identifikujte bezpečnostní tým podle dokumentu white paper v oddílu 4.

  3. Vytvořte zabezpečenou certifikační autoritu nebo identifikujte partnera (doporučené řešení) pro bezpečné generování a ukládání klíčů.

  4. Určete zásady pro četnost změny klíčů. To může záviset na tom, jestli máte nějaké zvláštní požadavky zákazníků, jako jsou vlády nebo jiné agentury.

  5. V případě ohrožení zabezpečení spouštěcího klíče mějte plán nepředvídaných událostí.

  6. Určete, kolik pk a dalších klíčů budete generovat podle bodu 1.3.3 a 1.5.

    To bude založeno na zákaznickém základu, řešení úložiště klíčů a zabezpečení počítačů.

    Pokud používáte doporučené řešení pro správu klíčů třetí strany, můžete kroky 7 až 8 přeskočit.

  7. Pro správu klíčů pořizovat server a hardware. – síť nebo samostatný HSM podle oddílu 2.2.1. Zvažte, jestli budete potřebovat jeden nebo několik modulů HSM pro vysokou dostupnost a strategii zálohování klíčů.

  8. Identifikujte alespoň 3 až 4 členy týmu, kteří budou mít ověřovací token pro ověřování v HSM.

  9. Pomocí HSM nebo třetí strany můžete předem vygenerovat klíče a certifikáty související se zabezpečeným spouštěním. Klíče budou záviset na typu počítače: SoC, Windows RT nebo jiné než Windows RT. Další informace najdete v částech 1.3 až 1.5.

  10. Naplňte firmware příslušnými klíči.

  11. Zaregistrujte klíč zabezpečené platformy spouštění, abyste povolili zabezpečené spouštění. Další podrobnosti najdete v dodatku B.

  12. Podle pokynů proveďte všechny proprietární testy a testy zabezpečeného spouštění HCK. Další podrobnosti najdete v dodatku B.

  13. Odešlete počítač. PKpriv se pravděpodobně už nikdy nepoužíval, udržujte ho v bezpečí.

Údržba (aktualizace firmwaru)

Možná budete muset aktualizovat firmware z několika důvodů, jako je aktualizace komponenty UEFI nebo oprava ohrožení zabezpečení spouštěcího klíče nebo pravidelné opětovné vytvoření klíče zabezpečeného spouštění.

Další informace najdete v oddílech 1.3.5 a 1.3.6.

Příloha B – rozhraní API zabezpečeného spouštění

  1. Zabezpečené rozhraní API pro spouštění

    Následující rozhraní API souvisejí s rozhraním UEFI nebo zabezpečeným spouštěním:

    1. GetFirmwareEnvironmentVariableEx: Načte hodnotu zadané proměnné prostředí firmwaru.

    2. SetFirmwareEnvironmentVariableEx: Nastaví hodnotu zadané proměnné prostředí firmwaru.

    3. GetFirmwareType: Načte typ firmwaru.

  2. Nastavení veřejného klíče

    Pomocí rutiny Set-SecureBootUEFI zapněte zabezpečené spouštění. Po nastavení platformového klíče, se systémové vynucení Secure Boot neprojeví až do dalšího restartování. Před restartováním by váš kód mohl volat GetFirmwareEnvironmentVariableEx() nebo rutinu PowerShellu: Get-SecureBootUEFI, aby potvrdil obsah databází Secure Boot.

  3. Ověření

    Ke kontrole stavu proměnné zabezpečeného spouštění můžete použít Msinfo32.exe nebo rutiny PowerShellu. Neexistuje žádné rozhraní WMI. Můžete také otestovat tím, že někdo vloží nesprávně podepsaný spouštěcí USB flash disk (například z windows HCK Secure Boot Manual Logo Test) a ověřit, že se nepovedlo spustit.

  4. Rutiny PowerShellu pro zabezpečené spouštění

    • Confirm-SecureBootUEFI: Je zabezpečené spouštění UEFI zapnuto, Ano nebo Ne?

      SetupMode == 0 && SecureBoot == 1

    • Set-SecureBootUEFI: Nastavte nebo přidejte ověřené proměnné UEFI zabezpečeného bootu

    • Get-SecureBootUEFI: Získání ověřených hodnot proměnných UEFI secureboot

    • Format-SecureBootUEFI: Vytvoří EFI_SIGNATURE_LISTs a EFI_VARIABLE_AUTHENTICATION_2 serializace

  5. Pokyny pro Windows HCK a Secure Boot

    Následující kroky platí pro systémové testy a testy počítačů bez třídy ovladače.

    1. Zakažte ochranu zabezpečeného spouštění.

      Zadejte konfiguraci systému BIOS a zakažte zabezpečené spouštění.

    2. Nainstalujte klientský software HCK.

    3. Spusťte všechny testy Windows HCK s výjimkou následujících:

      • BitLocker TPM a testy hesel pro obnovení pomocí PCR[7]
      • Testy pro BitLocker TPM a obnovovací hesla pro počítače Arm se zabezpečeným spouštěním
      • Test loga zabezpečeného spouštění
      • Test manuálního loga zabezpečeného spouštění

    4. Zadejte konfiguraci systému BIOS, povolte zabezpečené spouštění a obnovte zabezpečené spouštění do výchozí konfigurace.

    5. Spusťte následující testy bitlockeru a zabezpečeného spouštění:

      • BitLocker TPM a testy hesel pro obnovení pomocí PCR[7]
      • Testy pro BitLocker TPM a obnovovací hesla pro počítače Arm se zabezpečeným spouštěním
      • Test loga zabezpečeného spouštění (automatizovaný)

    6. Zadejte konfiguraci systému BIOS a vymažte konfiguraci zabezpečeného spouštění. Tím se počítač obnoví do režimu nastavení odstraněním veřejného klíče (PK) a dalších klíčů.

      Poznámka:

      Podpora pro vymazání je vyžadována pro počítače x86/x64.

    7. Spusťte ruční test loga zabezpečeného spouštění.

      Poznámka:

      Zabezpečené spouštění vyžaduje podepsané ovladače Windows HCK nebo VeriSign na počítačích s jiným systémem než Windows RT.

  6. Windows HCK Secure Boot Logo Test (automatizovaný)

    Tento test zkontroluje správnou konfiguraci zabezpečeného spouštění. Sem patří:

    • Zabezpečené spouštění je povoleno.
    • PK není známý testovací PK.
    • KEK obsahuje produkční Microsoft KEK.
    • db obsahuje produkční certifikační autoritu systému Windows.
    • dbx přítomný.
    • Vytváří nebo odstraňuje se mnoho proměnných o velikosti 1kB.
    • Vytvoří nebo odstraní se proměnná o velikosti 32 kB.

  7. Rozložení složky s ručním testováním zabezpečeného spouštění systému Windows HCK

    Rozložení složky pro testování loga zabezpečeného spouštění systému Windows HCK podle manuálu je popsáno níže:

    • "\Test" složka má následující:

      • Výrobní a servisní test
      • Povolení zabezpečeného spouštění v konfiguraci testu prostřednictvím kódu programu
      • Testy údržby
      • Připojení certifikátu k databázi, ověření funkce
      • Připojte hodnotu hash k dbx, ověřte funkci
      • Připojení certifikátu k dbx, ověření funkce
      • Připojte 600+ hodnot hash k dbx a ověřte velikost.
      • Programaticky změnit PK

    • "\Generate" složka obsahuje skripty, které zobrazují následující:

      • Jak se vytvořily testovací certifikáty

      • Součástí jsou testovací certifikáty a privátní klíče.

      • Jak byly vytvořeny všechny testy

      • Přeměna certifikátů a hodnot hash na podepsané balíčky

      • Můžete to spustit sami, nahradit vlastní certifikáty.

    • "\certs" složka obsahuje všechny certifikáty, které potřebujete ke spuštění systému Windows:

      Poznámka:

      Nepoužívejte metodu použitou "ManualTests\generate\TestCerts" ke generování klíčů a certifikátů. To je určené jenom pro testovací účely Windows HCK. Používá klíče, které jsou uložené na disku, což je velmi nezabezpečené a nedoporučuje se. To není určené pro použití v produkčním prostředí.

  • "ManualTests\example\OutOfBox" složka obsahuje skripty, které můžete využít k instalaci zabezpečeného spouštění na produkčních počítačích.

    "ManualTests\generate\tests\subcreate_outofbox_example.ps1" ukazuje, jak byly tyto příklady vygenerovány a mají sekce "TODO," kde může partner nahradit svůj PK a další metadata.

  1. Podepisování a odesílání UEFI systému Windows HCK

    Další informace najdete na následujících odkazech:

Příloha C – Mapování jistoty politiky certifikátů Federální certifikační autority Bridge

  1. Základní

    Tato úroveň poskytuje nejnižší stupeň záruky týkající se identity jednotlivce. Jednou z hlavních funkcí této úrovně je poskytnutí integrity dat podepsaným informacím. Tato úroveň je relevantní pro prostředí, ve kterých je riziko škodlivé aktivity považováno za nízké. Není vhodná pro transakce vyžadující ověření a obecně není dostatečná pro transakce vyžadující důvěrnost, ale může být použita pro ty, u kterých jsou certifikáty s vyšší úrovní záruky nedostupné.

  2. Základní

    Tato úroveň poskytuje základní úroveň záruky relevantní pro prostředí, kde existují rizika a důsledky ohrožení dat, ale nejsou považovány za významné význam. To může zahrnovat přístup k soukromým informacím, kdy pravděpodobnost škodlivého přístupu není vysoká. Předpokládá se, že uživatelé na této úrovni zabezpečení nebudou pravděpodobně škodliví.

  3. střední

    Tato úroveň je relevantní pro prostředí, kde jsou rizika a důsledky ohrožení dat střední. To může zahrnovat transakce, které mají významnou peněžní hodnotu nebo riziko podvodů nebo zahrnují přístup k soukromým informacím, kde je pravděpodobnost škodlivého přístupu podstatná.

  4. Vysoko

    Tato úroveň je vhodná pro použití, pokud jsou hrozby pro data vysoké nebo jsou důsledky selhání služeb zabezpečení vysoké. To může zahrnovat transakce s velmi vysokou hodnotou nebo vysokou úroveň rizika podvodu.

Generování a podepisování zabezpečených spouštěcích klíčů pomocí HSM (příklad)

Pokyny pro ověření volby UEFI ROM

Přehled zabezpečeného spouštění