Wskazówki dotyczące tworzenia i zarządzania kluczem bezpiecznego rozruchu systemu Windows

Ten dokument pomaga poprowadzić producentów OEM i ODM w tworzeniu kluczy i certyfikatów Secure Boot oraz zarządzaniu nimi w środowisku produkcyjnym. Odpowiada na pytania związane z tworzeniem, przechowywaniem i pobieraniem kluczy platformy (PK), bezpiecznymi kluczami aktualizacji oprogramowania układowego i kluczami wymiany kluczy innych firm (KEKs).

Uwaga / Notatka

Producenci urządzeń, przedsiębiorstwa i klienci mogą znaleźć zalecane pliki binarne PK, KEK, DB i DBX firmy Microsoft w repozytorium open source secure boot firmy Microsoft. Pliki binarne są formatowane zgodnie z oczekiwanym formatem EDKII, aby łatwo zintegrować je z oprogramowaniem układowym.

Producenci OEM urządzeń mogą znaleźć wymagania dotyczące konfiguracji bezpiecznego rozruchu dla systemu Windows 11 w wersji 25H2 w sekcji 1.6 tego artykułu.

Uwaga / Notatka

Certyfikat Microsoft Corporation KEK CA 2011 wygaśnie w 2026 roku, a wszyscy OEM muszą tworzyć, podpisywać i przesyłać aktualizacje dla nowego certyfikatu Microsoft Corporation KEK CA 2023 do Microsoft. Umożliwi to firmie Microsoft aktualizowanie urządzeń na rynku przy użyciu nowego urzędu certyfikacji KEK firmy Microsoft, dzięki czemu systemy będą nadal otrzymywać aktualizacje DB i DBX po 2026 roku. Aby uzyskać instrukcje i przetestować zabezpieczenia, odwiedź stronę https://aka.ms/KEKUpdatePackage

Wymagania systemu Windows dotyczące interfejsu UEFI i bezpiecznego rozruchu można znaleźć w temacie Wymagania dotyczące certyfikacji sprzętu systemu Windows. Ten dokument nie wprowadza nowych wymagań ani nie reprezentuje oficjalnego programu systemu Windows. Jest ona przeznaczona jako wskazówki wykraczające poza wymagania dotyczące certyfikacji, aby pomóc w tworzeniu wydajnych i bezpiecznych procesów tworzenia kluczy bezpiecznego rozruchu i zarządzania nimi. Jest to ważne, ponieważ bezpieczny rozruch UEFI jest oparty na użyciu infrastruktury kluczy publicznych do uwierzytelniania kodu przed zezwoleniem na wykonanie.

Oczekuje się, że czytelnik zna podstawy interfejsu UEFI, podstawową wiedzę na temat bezpiecznego rozruchu (rozdział 27 specyfikacji UEFI) i model zabezpieczeń infrastruktury kluczy publicznych.

Wymagania, testy i narzędzia weryfikacji bezpiecznego rozruchu w systemie Windows są dostępne dzisiaj za pośrednictwem zestawu certyfikacji sprzętu systemu Windows (HCK). Jednak te zasoby HCK nie dotyczą tworzenia kluczy i zarządzania nimi w przypadku wdrożeń systemu Windows. Ten dokument dotyczy zarządzania kluczami jako zasobu, który ułatwia partnerom wdrażanie kluczy używanych przez oprogramowanie układowe. Nie jest ona przeznaczona jako normatywne wskazówki i nie obejmuje żadnych nowych wymagań.

Na tej stronie:

Ten dokument jest punktem wyjścia do opracowywania komputerów gotowych do użycia przez klientów, narzędzi wdrażania w fabryce oraz najważniejszych najlepszych praktyk w zakresie zabezpieczeń.

1. Bezpieczny rozruch, system Windows i zarządzanie kluczami

Specyfikacja interfejsu UEFI (Unified Extensible Firmware Interface) definiuje proces uwierzytelniania wykonywania oprogramowania układowego o nazwie Bezpieczny rozruch. Jako standard branżowy Secure Boot definiuje sposób, w jaki oprogramowanie układowe platformy zarządza certyfikatami, uwierzytelnia oprogramowanie układowe oraz jak system operacyjny integruje się z tym procesem.

Bezpieczny rozruch jest oparty na procesie infrastruktury kluczy publicznych (PKI) do uwierzytelniania modułów, zanim będą mogły być wykonywane. Te moduły mogą obejmować sterowniki firmware, sterowniki ROM opcji, sterowniki UEFI na dysku, aplikacje UEFI lub programy rozruchowe UEFI. Dzięki uwierzytelnieniu obrazu przed wykonaniem, Secure Boot zmniejsza ryzyko ataków typu rootkits, które mogą pojawić się przed uruchomieniem systemu. Firma Microsoft korzysta z bezpiecznego rozruchu UEFI w systemie Windows 8 lub nowszym w ramach architektury zabezpieczeń zaufanego rozruchu w celu poprawy bezpieczeństwa platformy dla naszych klientów. Bezpieczny rozruch jest wymagany dla komputerów klienckich z systemem Windows 8 lub nowszym oraz systemu Windows Server 2016 zgodnie z definicją w wymaganiach dotyczących zgodności sprzętu systemu Windows.

Proces bezpiecznego rozruchu działa w następujący sposób i jak pokazano na rysunku 1:

  1. Składniki rozruchu oprogramowania układowego: Oprogramowanie układowe sprawdza, czy moduł ładujący systemu operacyjnego jest zaufany (system Windows lub inny zaufany system operacyjny).
  2. Składniki rozruchu systemu Windows: BootMgr, WinLoad, Uruchamianie jądra systemu Windows. Składniki rozruchu systemu Windows weryfikują podpis każdego składnika. Żadne niezaufane składniki nie zostaną załadowane, a zamiast tego wywołają procedurę naprawczą bezpiecznego rozruchu.
    • Inicjowanie oprogramowania antywirusowego i oprogramowania chroniącego przed złośliwym kodem: To oprogramowanie jest sprawdzane pod kątem specjalnego podpisu wystawionego przez firmę Microsoft, sprawdzając, czy jest to zaufany sterownik krytyczny dla rozruchu i zostanie uruchomione na początku procesu rozruchu.
    • Inicjowanie sterownika krytycznego rozruchu: Podpisy wszystkich sterowników krytycznych dla rozruchu są sprawdzane w ramach weryfikacji bezpiecznego rozruchu w narzędziu WinLoad.
  3. Inicjalizacja dodatkowego systemu operacyjnego
  4. Ekran logowania systemu Windows

obraz architektury integralności platformy

Rysunek 1. Architektura zaufanego rozruchu systemu Windows

Implementacja bezpiecznego rozruchu UEFI jest częścią zaufanej architektury rozruchu firmy Microsoft wprowadzonej w systemie Windows 8.1. Rosnący trend w rozwoju złośliwego oprogramowania polega na atakowaniu ścieżki rozruchowej jako preferowanego wektora ataku. Ta klasa ataku była trudna do ochrony, ponieważ produkty chroniące przed złośliwym kodem mogą być wyłączone przez złośliwe oprogramowanie, które uniemożliwia ich całkowite ładowanie. Dzięki architekturze zaufanego rozruchu systemu Windows i utworzeniu root zaufania za pomocą Bezpiecznego Rozruchu, użytkownik jest chroniony przed złośliwym kodem wykonywanym w ścieżce rozruchu, zapewniając, że tylko podpisany, certyfikowany kod "znany jako dobry" oraz programy rozruchowe mogą być wykonywane przed załadowaniem samego systemu operacyjnego.

1.1 infrastruktura Public-Key (PKI) i bezpieczny rozruch

Infrastruktura kluczy publicznych ustanawia autentyczność i zaufanie do systemu. Bezpieczny rozruch wykorzystuje infrastrukturę PKI do dwóch celów wysokiego poziomu.

  1. Podczas rozruchu w celu określenia, czy moduły wczesnego rozruchu są zaufane do uruchomienia.
  2. W celu uwierzytelnienia żądań usług, należy uwzględnić modyfikację baz danych Secure Boot oraz aktualizację oprogramowania układowego platformy.

Infrastruktura kluczy publicznych składa się z następujących elementów:

  • Urząd certyfikacji, który wystawia certyfikaty cyfrowe.
  • Urząd rejestracji, który weryfikuje tożsamość użytkowników żądających certyfikatu z urzędu certyfikacji.
  • Centralny katalog, w którym przechowywane są i indeksowane klucze.
  • System zarządzania certyfikatami.

1.2 Kryptografia klucza publicznego

Kryptografia klucza publicznego używa pary powiązanych matematycznie kluczy kryptograficznych, znanych jako klucz publiczny i prywatny. Jeśli znasz jeden z kluczy, nie możesz łatwo obliczyć, czym jest drugi. Jeśli jeden klucz jest używany do szyfrowania informacji, tylko odpowiedni klucz może odszyfrować te informacje. W przypadku bezpiecznego rozruchu klucz prywatny jest używany do cyfrowego podpisywania kodu, a klucz publiczny służy do weryfikowania podpisu w tym kodzie w celu potwierdzenia jego autentyczności. W przypadku naruszenia zabezpieczeń klucza prywatnego systemy z odpowiednimi kluczami publicznymi nie są już bezpieczne. Może to prowadzić do ataków zestawu rozruchowego i zaszkodzi reputacji jednostki odpowiedzialnej za zapewnienie bezpieczeństwa klucza prywatnego.

W systemie bezpiecznego rozruchu z kluczem publicznym masz następujące elementy:

  • 1.2.1 Szyfrowanie RSA 2048

    RSA-2048 to asymetryczny algorytm kryptograficzny. Miejsce potrzebne do przechowywania modulu RSA-2048 w postaci pierwotnej wynosi 2048 bitów.

  • 1.2.2 Certyfikat z podpisem własnym

    Certyfikat podpisany przez klucz prywatny zgodny z kluczem publicznym certyfikatu jest znany jako certyfikat z podpisem własnym. Certyfikaty głównego urzędu certyfikacji należą do tej kategorii.

  • 1.2.3 Urząd certyfikacji

    Urząd certyfikacji wystawia podpisane certyfikaty, które potwierdzają tożsamość podmiotu certyfikatu i wiążą tę tożsamość z kluczem publicznym zawartym w certyfikacie. Urząd certyfikacji podpisuje certyfikat przy użyciu jego klucza prywatnego. Wystawia on odpowiedni klucz publiczny wszystkim zainteresowanym stronom w certyfikacie głównego urzędu certyfikacji z podpisem własnym.

    Podczas bezpiecznego rozruchu urzędy certyfikacji (CA) to producent OEM (lub jego delegaci) oraz firma Microsoft. Urzędy certyfikacji generują pary kluczy, które tworzą katalog główny zaufania, a następnie używają kluczy prywatnych do podpisywania uzasadnionych operacji, takich jak dozwolone moduły EFI wczesnego rozruchu i żądania obsługi oprogramowania układowego. Odpowiednie klucze publiczne są dostarczane do oprogramowania układowego UEFI na komputerach z włączoną obsługą bezpiecznego rozruchu i są używane do weryfikowania tych operacji.

    (Więcej informacji na temat używania urzędów certyfikacji i wymiany kluczy jest łatwo dostępne w Internecie, który odnosi się do modelu bezpiecznego rozruchu).

  • 1.2.4 Klucz publiczny

    Publiczny klucz platformy jest dostarczany z komputerem i jest dostępny publicznie. W tym dokumencie użyjemy sufiksu "pub", aby oznaczyć klucz publiczny. Na przykład PKpub oznacza publiczną połowę PK.

  • 1.2.5 Klucz prywatny

    Aby infrastruktura kluczy publicznych działała, należy bezpiecznie zarządzać kluczem prywatnym. Powinna być dostępna dla kilku wysoce zaufanych osób w organizacji i znajdujących się w fizycznie bezpiecznej lokalizacji z silnymi ograniczeniami zasad dostępu. W tym dokumencie użyjemy sufiksu "priv", aby oznaczyć klucz prywatny. Na przykład PKpriv oznacza prywatną część PK.

  • 1.2.6 Certyfikaty

    Podstawowym zastosowaniem certyfikatów cyfrowych jest zweryfikowanie źródła podpisanych danych, takich jak pliki binarne itp. Typowym zastosowaniem certyfikatów jest bezpieczeństwo wiadomości internetowych przy użyciu protokołu Transport Layer Security (TLS) lub Secure Sockets Layer (SSL). Zweryfikowanie podpisanych danych przy użyciu certyfikatu pozwala odbiorcy znać źródło danych i czy zostały zmienione podczas przesyłania.

    Certyfikat cyfrowy ogólnie zawiera na wysokim poziomie nazwę wyróżniającą (DN), klucz publiczny i podpis. Nazwa wyróżniająca identyfikuje jednostkę — na przykład firmę — która posiada klucz prywatny zgodny z kluczem publicznym certyfikatu. Podpisywanie certyfikatu przy użyciu klucza prywatnego i umieszczanie podpisu w certyfikacie wiąże klucz prywatny z kluczem publicznym.

    Certyfikaty mogą zawierać inne typy danych. Na przykład certyfikat X.509 zawiera format certyfikatu, numer seryjny certyfikatu, algorytm użyty do podpisania certyfikatu, nazwę urzędu certyfikacji, nazwę certyfikatu, nazwę i klucz publiczny jednostki żądającej certyfikatu oraz podpis urzędu certyfikacji.

  • 1.2.7 Łączenie certyfikatów

    Od: Łańcuchy certyfikatów:

    Główny urząd certyfikacji jest z podpisem własnym, inne osoby podpisane przez główny urząd certyfikacji

    Rysunek 2. Łańcuch trzech certyfikatów

    Certyfikaty użytkownika są często podpisane przez inny klucz prywatny, taki jak klucz prywatny urzędu certyfikacji. Stanowi to łańcuch dwóch certyfikatów. Zweryfikowanie, czy certyfikat użytkownika jest autentyczny, polega na sprawdzeniu jego podpisu, co wymaga użycia klucza publicznego urzędu certyfikacji z jego certyfikatu. Jednak zanim będzie można użyć klucza publicznego urzędu certyfikacji, należy zweryfikować dołączony certyfikat urzędu certyfikacji. Ponieważ certyfikat urzędu certyfikacji jest z podpisem własnym, klucz publiczny urzędu certyfikacji jest używany do weryfikowania certyfikatu.

    Certyfikat użytkownika nie musi być podpisany kluczem prywatnym głównego urzędu certyfikacji. Może być podpisane kluczem prywatnym pośrednika, którego certyfikat został podpisany kluczem prywatnym urzędu certyfikacji. Jest to wystąpienie łańcucha trzech certyfikatów: certyfikat użytkownika, certyfikat pośredniczący i certyfikat urzędu certyfikacji. Jednak więcej niż jeden pośrednik może być częścią łańcucha, więc łańcuchy certyfikatów mogą mieć dowolną długość.

1.3 Wymagania dotyczące infrastruktury kluczy publicznych bezpiecznego rozruchu

Zdefiniowane przez UEFI podstawowe zaufanie składa się z klucza platformy oraz wszelkich kluczy, które OEM lub ODM włącza do rdzenia oprogramowania sprzętowego. Zabezpieczenia sprzed UEFI i podstawa zaufania nie są rozwiązywane przez proces bezpiecznego rozruchu UEFI, lecz poprzez publikacje National Institute of Standards and Technology (NIST) oraz Trusted Computing Group (TCG) przywołane w tym dokumencie.

  • 1.3.1 Wymagania dotyczące bezpiecznego rozruchu

    Aby zaimplementować bezpieczny rozruch, należy wziąć pod uwagę następujące parametry:

    • Wymagania klienta
    • Wymagania dotyczące zgodności sprzętu systemu Windows
    • Wymagania dotyczące generowania kluczy i zarządzania.

    Należy wybrać sprzęt do zarządzania kluczami bezpiecznego rozruchu, takich jak sprzętowe moduły zabezpieczeń (HSM), rozważyć specjalne wymagania dotyczące komputerów, aby wysłać je do instytucji rządowych i innych agencji, a na koniec proces tworzenia, wypełniania i zarządzania cyklem życia różnych kluczy bezpiecznego rozruchu.

  • 1.3.2 Klucze związane z bezpiecznym rozruchem

    Klucze używane do bezpiecznego rozruchu znajdują się poniżej:

    pk, kek, db, dbx oraz klucz do oprogramowania układowego, klucz winrt

    Rysunek 3. Klucze związane z bezpiecznym rozruchem

    Rysunek 3 powyżej reprezentuje podpisy i klucze na komputerze z bezpiecznym rozruchem. Platforma jest zabezpieczona za pośrednictwem klucza platformy instalowanego przez producenta OEM w oprogramowaniu układowym podczas produkcji. Inne klucze są używane przez Bezpieczny Rozruch do ochrony dostępu do baz danych, które przechowują klucze w celu umożliwienia lub zabronienia wykonania oprogramowania układowego.

    Autoryzowana baza danych (db) zawiera klucze publiczne i certyfikaty reprezentujące zaufane składniki oprogramowania układowego i moduły ładujące systemu operacyjnego. Zabroniona baza danych sygnatur (dbx) zawiera skróty złośliwych i narażonych składników, a także naruszone klucze i certyfikaty oraz blokuje wykonywanie tych złośliwych składników. Siła tych zasad opiera się na podpisywaniu oprogramowania układowego przy użyciu technologii Authenticode i infrastruktury kluczy publicznych (PKI). Infrastruktura kluczy publicznych to dobrze ugruntowany proces tworzenia, zarządzania i odwoływanie certyfikatów, które ustanawiają zaufanie podczas wymiany informacji. Infrastruktura kluczy publicznych jest podstawą modelu zabezpieczeń bezpiecznego rozruchu.

    Poniżej przedstawiono więcej szczegółów dotyczących tych kluczy.

  • 1.3.3 Klucz platformy (PK)

    Zgodnie z sekcją 27.5.1 UEFI 2.3.1 Errata C, klucz platformy ustanawia relację zaufania między właścicielem platformy a jej oprogramowaniem układowym. Właściciel platformy rejestruje publiczną połowę klucza (PKpub) w oprogramowaniu układowym platformy, zgodnie z sekcją 7.2.1 UEFI 2.3.1 Errata C. Ten krok przenosi platformę z trybu konfiguracji do trybu użytkownika. Firma Microsoft zaleca, aby klucz platformy był typu EFI_CERT_X509_GUID z algorytmem klucza publicznego RSA, długością klucza publicznego 2048 bitów i algorytmem podpisu sha256RSA. Właściciel platformy może użyć typu EFI_CERT_RSA2048_GUID , jeśli miejsce do magazynowania jest problemem. Klucze publiczne służą do sprawdzania podpisów zgodnie z opisem we wcześniejszej sekcji tego dokumentu. Właściciel platformy może później użyć prywatnej połowy klucza (PKpriv):

  • Aby zmienić własność platformy, należy umieścić oprogramowanie układowe w trybie konfiguracji zdefiniowanym przez interfejs UEFI, co wyłącza bezpieczny rozruch. Przywróć tryb konfiguracji tylko wtedy, gdy jest to konieczne podczas produkcji.

  • W przypadku urządzeń stacjonarnych i serwerów producenci OEM mogą zarządzać kluczami PK i niezbędnymi skojarzonymi z nimi infrastrukturami PKI lub zdecydować się na użycie zarządzanego przez firmę Microsoft klucza PK dla OEM. PK zarządzane przez firmę Microsoft jest chronione przez moduły HSM firmy Microsoft i zarządzane w ramach najlepszych praktyk PKI. Jest to preferowany klucz publiczny (PK) dla ekosystemu Windows.

1.3.3.1 Aby zarejestrować lub zaktualizować klucz wymiany kluczy (KEK) oraz zarejestrować klucz platformy

Właściciel platformy rejestruje publiczną połowę klucza platformy (PKpub), wywołując usługę UEFI Boot Service SetVariable() zgodnie z sekcją 7.2.1 specyfikacji UEFI 2.3.1 errata C, a następnie resetuje platformę. Jeśli platforma jest w trybie konfiguracji, nowy PKpub zostanie podpisany przy użyciu swojego odpowiednika PKpriv . Jeśli platforma jest w trybie użytkownika, nowy PKpub musi być podpisany przy użyciu bieżącego PKpriv. Jeśli klucz PK jest typu EFI_CERT_X509_GUID, to musi być podpisany przez bezpośredni klucz PKpriv, a nie klucz prywatny żadnego certyfikatu wystawionego w ramach PK.

1.3.3.2 Wyczyszczenie klucza platformy

Właściciel platformy wyczyści publiczną połowę klucza platformy (PKpub), wywołując usługę UEFI Boot Service SetVariable() o rozmiarze 0, a następnie resetując platformę. Jeśli platforma jest w trybie konfiguracji, pusta zmienna nie musi być uwierzytelniona. Jeśli platforma jest w trybie użytkownika, pusta zmienna musi być podpisana bieżącym kluczem PKpriv; aby uzyskać szczegółowe informacje, zobacz sekcję 7.2 (Usługi zmiennych) w specyfikacji UEFI 2.3.1 Errata C. Zdecydowanie zaleca się, aby produkcyjny klucz PKpriv nigdy nie był używany do podpisywania pakietu w celu zresetowania platformy, ponieważ umożliwia to programowe wyłączenie bezpiecznego rozruchu. Jest to przede wszystkim scenariusz testowy przedprodukcyjny.

Klucz platformy może być również wyczyszczony przy użyciu bezpiecznej metody specyficznej dla platformy. W takim przypadku należy również zaktualizować tryb konfiguracji zmiennej globalnej do 1.

obraz: pk określa tryb konfiguracji lub tryb użytkownika

Rysunek 4. Diagram stanu klucza platformy

1.3.3.3 Generacja PK

Zgodnie z zaleceniami UEFI klucz publiczny musi być przechowywany w magazynie nietrwałym, który jest odporny na naruszenia i usuwanie na komputerze. Klucze prywatne pozostają bezpieczne w partnerze lub w biurze zabezpieczeń producenta OEM i tylko klucz publiczny jest ładowany na platformę. Więcej szczegółów można znaleźć w sekcji 2.2.1 i 2.3.

Firma Microsoft udostępnia klucz PK dla OEM , aby wyeliminować odpowiedzialność za utrzymanie i zabezpieczanie certyfikatu PK. Klucz PK jest chroniony przez moduły HSM firmy Microsoft i zarządzany w ramach operacji PKI firmy Microsoft.

Liczba generowanych PK zależy od uznania właściciela platformy (OEM). Te klucze mogą być następujące:

  1. Jeden na komputer. Posiadanie jednego unikatowego klucza dla każdego urządzenia. Może to być wymagane w przypadku agencji rządowych, instytucji finansowych lub innych klientów serwerów z wysokimi potrzebami w zakresie zabezpieczeń. Może to wymagać dodatkowej mocy magazynowania i przetwarzania kryptograficznego w celu wygenerowania prywatnych i publicznych kluczy dla dużej liczby komputerów. Zwiększa to złożoność mapowania urządzeń z ich odpowiednim kluczem PK podczas wdrażania przyszłych aktualizacji oprogramowania sprzętowego do tych urządzeń. Istnieje kilka różnych rozwiązań HSM do zarządzania dużą liczbą kluczy, zależnie od dostawcy HSM. Aby uzyskać więcej informacji, zobacz Secure Boot Key Generation Using HSM (Generowanie klucza bezpiecznego rozruchu przy użyciu modułu HSM).

  2. Jeden na model. Posiadanie jednego klucza na model komputera. Kompromis polega na tym, że jeśli klucz zostanie naruszony, wszystkie maszyny w tym samym modelu będą narażone na zagrożenia. Jest to zalecane przez firmę Microsoft w przypadku komputerów stacjonarnych.

  3. Jeden na linię produktu. W przypadku naruszenia zabezpieczeń klucza cała linia produktu byłaby podatna na zagrożenia.

  4. Jeden na producenta OEM. Chociaż może to być najprostsze do skonfigurowania, jeśli klucz zostanie naruszony, każdy wyprodukowany komputer będzie narażony na zagrożenia. Aby przyspieszyć działanie na hali produkcyjnej, klucz PK i potencjalnie inne klucze mogą być wstępnie generowane i przechowywane w bezpiecznej lokalizacji. Mogą zostać później pobrane i użyte na linii montażowej. Rozdziały 2 i 3 zawierają więcej szczegółów.

1.3.3.4 Ponowne łączenie klucza PK

Może to być konieczne, jeśli klucz PK zostanie naruszony lub jako wymaganie przez klienta, który ze względów bezpieczeństwa może zdecydować się na zarejestrowanie własnego klucza PK.

Ponowne tworzenie klucza można wykonać dla modelu lub komputera w oparciu o metodę wybraną do utworzenia klucza PK. Wszystkie nowsze komputery zostaną podpisane przy użyciu nowo utworzonego klucza PK.

Zaktualizowanie klucza PK na komputerze produkcyjnym wymagałoby aktualizacji zmiennej podpisanej przy użyciu istniejącego klucza PK w celu jego zastąpienia lub instalacji pakietu aktualizacji oprogramowania układowego. OEM może również utworzyć pakiet SetVariable() i rozpowszechnić go za pomocą prostej aplikacji, takiej jak program PowerShell, który po prostu zmienia klucz PK. Pakiet aktualizacji oprogramowania układowego zostanie podpisany kluczem bezpieczeństwa aktualizacji oprogramowania układowego i zweryfikowany przez oprogramowanie układowe. W przypadku aktualizacji oprogramowania układowego w celu zaktualizowania klucza platformy (PK) należy zadbać o zachowanie klucza KEK, bazy db i dbx.

Na wszystkich komputerach zaleca się, aby nie używać klucza PK jako bezpiecznego klucza aktualizacji oprogramowania układowego. Jeśli PKpriv został naruszony, klucz bezpiecznej aktualizacji oprogramowania układowego również jest naruszony (ponieważ są takie same). W takim przypadku aktualizacja rejestracji nowego PKpub może nie być możliwa, ponieważ proces aktualizacji również został naruszony.

Na komputerach SOCs istnieje inny powód, aby nie używać klucza PK jako bezpiecznego klucza aktualizacji oprogramowania układowego. Dzieje się tak, ponieważ bezpieczny klucz aktualizacji oprogramowania układowego jest trwale zapisany w bezpiecznikach na komputerach spełniających wymagania dotyczące certyfikacji sprzętu systemu Windows.

  • 1.3.4 Klucz wymiany kluczy (KEK) Klucze wymiany kluczy ustanawiają relację zaufania między systemem operacyjnym a oprogramowaniem układowym platformy. Każdy system operacyjny (i potencjalnie każda aplikacja innej firmy, która musi komunikować się z oprogramowaniem układowym platformy) rejestruje klucz publiczny (KEKpub) w oprogramowaniu układowym platformy.

    1.3.4.1 Rejestrowanie kluczy wymiany kluczy

    Klucze wymiany kluczy są przechowywane w bazie danych sygnatur zgodnie z opisem w 1.4 Signature Databases (Db and Dbx)). Baza danych sygnatur jest przechowywana jako uwierzytelniona zmienna UEFI.

    Właściciel platformy rejestruje klucze wymiany kluczy, wywołując metodę SetVariable() zgodnie z sekcją 7.2 (Usługi zmiennych) w ramach specyfikacji UEFI 2.3.1 Errata C. z zestawem EFI_VARIABLE_APPEND_WRITE atrybutów i parametrem Dane zawierającym nowe klucze lub odczytując bazę danych przy użyciu metody GetVariable(), dołączając nowy klucz wymiany kluczy do istniejących kluczy, a następnie zapisując bazę danych przy użyciu metody SetVariable()zgodnie z sekcją 7.2 (Usługi zmiennych) w ramach specyfikacji UEFI 2.3.1 Errata C bez zestawu atrybutów EFI_VARIABLE_APPEND_WRITE .

    Jeśli platforma jest w trybie konfiguracji, zmienna bazy danych sygnatury nie musi być podpisana, ale parametry wywołania SetVariable() należy nadal przygotować zgodnie z określonymi wymaganiami dla zmiennych autoryzowanych w sekcji 7.2.1. Jeśli platforma jest w trybie użytkownika, baza danych podpisów musi być podpisana przy użyciu bieżącego klucza PKpriv

    1.3.4.2 Wyczyszczenie KEK

    Możliwe jest "wyczyszczenie" (usunięcie) KEK. Należy pamiętać, że jeśli klucz PK nie jest zainstalowany na platformie, "czyste" żądania nie są wymagane do podpisania. Jeśli są podpisane, wtedy do wyczyszczenia KEK wymagany jest pakiet podpisany kluczem PK, a do wyczyszczenia db lub dbx wymagany jest pakiet podpisany przez dowolną jednostkę obecną w KEK.

    1.3.4.3 Microsoft KEK

    Następujący certyfikat KEK firmy Microsoft jest wymagany do umożliwienia odwołania nieprawidłowych obrazów przez zaktualizowanie dbx oraz potencjalnie zaktualizowanie bazy db, aby przygotować się na nowsze obrazy podpisane przez Windows.

  1. Microsoft Corporation KEK 2K CA 2023

    • Skrót certyfikatu SHA-1: 459AB6FB5E284D272D5E3E6ABC8ED663829D632B.
    • WłaścicielPodpisu GUID: {77fa9abd-0359-4d32-bd60-28f4e78f784b}.
    • Microsoft udostępni certyfikat partnerom i może on zostać dodany jako podpis typu EFI_CERT_X509_GUID lub EFI_CERT_RSA2048_GUID.
    • Certyfikat KEK firmy Microsoft można pobrać z: https://go.microsoft.com/fwlink/?linkid=2239775.

1.3.4.4 KEKDefault Dostawca platformy musi podać domyślny zestaw kluczy wymiany kluczy w zmiennej KEKDefault. Aby uzyskać więcej informacji, zapoznaj się ze specyfikacją UEFI w sekcji 27.3.3.

1.3.4.5 OEM/z zewnątrz KEK — dodawanie wielu kluczy KEK

Klienci i właściciele platform nie muszą mieć własnego KEK. Na komputerach innych niż te z systemem Windows RT, producent OEM może mieć dodatkowe KEKs umożliwiające kontrolę nad bazą danych (db) i dbx przez dodatkowych producentów OEM lub zaufane osoby trzecie.

  • 1.3.5 Klucz aktualizacji oprogramowania układowego bezpiecznego rozruchuKlucz aktualizacji bezpiecznego oprogramowania układowego służy do podpisywania oprogramowania układowego, gdy trzeba go zaktualizować. Ten klucz musi mieć minimalną siłę klucza RSA-2048. Wszystkie aktualizacje oprogramowania układowego muszą być bezpiecznie podpisane przez producenta OEM, ich zaufany pełnomocnik, taki jak ODM lub IBV (niezależny dostawca systemu BIOS) lub przez bezpieczną usługę podpisywania.

    Zgodnie z publikacją NIST 800-147 Aktualizacja oprogramowania sprzętowego w terenie musi wspierać wszystkie elementy wytycznych:

    Każda aktualizacja pamięci flash oprogramowania sprzętowego musi być podpisana przez twórcę.

    Oprogramowanie układowe musi sprawdzić podpis aktualizacji.

  • 1.3.6 Tworzenie kluczy dla bezpiecznej aktualizacji oprogramowania układowego

    Ten sam klucz będzie używany do podpisywania wszystkich aktualizacji oprogramowania układowego, ponieważ część publiczna będzie znajdować się na komputerze. Można również podpisać aktualizację oprogramowania układowego za pomocą klucza, który jest powiązany z kluczem aktualizacji bezpiecznego oprogramowania układowego.

    Może istnieć jeden klucz na komputer, taki jak PK lub jeden na model lub jeden na linię produktu. Jeśli istnieje jeden klucz na komputer, co oznaczałoby, że miliony unikatowych pakietów aktualizacji będą musiały zostać wygenerowane. Zastanów się nad dostępnością zasobów, jaka metoda będzie ci działać. Posiadanie klucza dla modelu lub linii produktów jest dobrym kompromisem.

    Klucz publiczny aktualizacji bezpiecznego oprogramowania układowego (lub jego skrót w celu zaoszczędzenia miejsca) będzie przechowywany w jakimś chronionym magazynie na platformie — zwykle chroniona pamięć flash (w komputerze PC) lub bezpieczniki programowane jednorazowo (w układach SoC).

    Jeśli jest przechowywany tylko skrót tego klucza (aby zaoszczędzić miejsce), aktualizacja oprogramowania układowego będzie zawierać klucz, a pierwszy etap procesu aktualizacji sprawdzi, czy klucz publiczny w aktualizacji jest zgodny z skrótem przechowywanym na platformie.

    Kapsułki to środek, za pomocą którego system operacyjny może przekazywać dane do środowiska UEFI podczas ponownego uruchamiania. System Windows wywołuje interfejs UEFI UpdateCapsule() w celu dostarczania aktualizacji oprogramowania układowego systemu i komputera. Podczas rozruchu, przed wywołaniem ExitBootServices(), system Windows przekaże wszystkie nowe aktualizacje oprogramowania układowego znajdujące się w magazynie sterowników systemu Windows do funkcji UpdateCapsule(). Oprogramowanie układowe systemu UEFI może użyć tego procesu do aktualizacji systemu i oprogramowania układowego komputera. Dzięki obsłudze oprogramowania układowego przez Windows, OEM może polegać na tym samym typowym formacie i procesie aktualizacji oprogramowania zarówno dla systemu, jak i komputera. Oprogramowanie układowe musi zaimplementować tabelę ACPI ESRT w celu obsługi interfejsu UEFI UpdateCapsule() dla systemu Windows.

    Aby uzyskać szczegółowe informacje na temat implementowania obsługi platformy aktualizacji oprogramowania układowego UEFI systemu Windows, zapoznaj się z następującą dokumentacją: Platforma aktualizacji oprogramowania układowego UEFI systemu Windows.

    Kapsułki aktualizacji mogą znajdować się w pamięci lub na dysku. System Windows obsługuje aktualizacje pamięci.

    1.3.6.1 Kapsuła (Kapsuła w pamięci)

    Poniżej przedstawiono przebieg zdarzeń dla działania kapsuły aktualizacji w pamięci.

    1. Kapsuła jest umieszczana w pamięci przez aplikację w systemie operacyjnym
    2. Zdarzenie dotyczące skrzynki pocztowej jest ustawione, aby powiadomić BIOS-u o zbliżającej się aktualizacji
    3. Komputer się restartuje, weryfikuje obraz kapsuły, a następnie system BIOS wykonuje aktualizację.

  • 1.3.7 Przepływ pracy typowej aktualizacji oprogramowania układowego

    1. Pobierz i zainstaluj sterownik oprogramowania układowego.
    2. Ponowny rozruch.
    3. Moduł ładujący systemu operacyjnego wykrywa i weryfikuje oprogramowanie układowe.
    4. Moduł ładujący systemu operacyjnego przekazuje binarny blok danych do UEFI.
    5. UEFI wykonuje aktualizację oprogramowania układowego (ten proces należy do dostawcy układów scalonych).
    6. Wykrywanie modułu ładującego systemu operacyjnego zakończyło się pomyślnie.
    7. System operacyjny kończy rozruch.

1.4 Bazy danych podpisów (Db i Dbx)

  • 1.4.1 Autoryzowana baza danych sygnatur (db)

    Zawartość bazy danych EFI _IMAGE_SECURITY_DATABASE kontroluje, jakie obrazy są zaufane podczas weryfikowania załadowanych obrazów. Baza danych może zawierać wiele certyfikatów, kluczy i skrótów w celu zidentyfikowania dozwolonych obrazów.

    Aby umożliwić ładowanie modułu ładującego systemu operacyjnego Windows, należy uwzględnić następujący certyfikat w bazie danych:

  1. Windows UEFI CA 2023
    • Skrót certyfikatu SHA-1: 45A0FA32604773C82433C3B7D59E7466B3AC0C67.
    • WłaścicielPodpisu GUID: {77fa9abd-0359-4d32-bd60-28f4e78f784b}.
    • Microsoft udostępni certyfikat partnerom i może on zostać dodany jako podpis typu EFI_CERT_X509_GUID lub EFI_CERT_RSA2048_GUID.
    • Certyfikaty UEFI dla systemu Windows 2023 można pobrać stąd: https://go.microsoft.com/fwlink/?linkid=2239776.

Z wyjątkiem systemów, które są zablokowane do rozruchu wyłącznie systemu Windows, producent OEM powinien rozważyć uwzględnienie certyfikatów UEFI stron trzecich Microsoft oraz certyfikatów ROM opcji Microsoft. Pozwoli to na uruchamianie sterowników UEFI i aplikacji od innych firm na komputerze bez konieczności wykonywania dodatkowych kroków przez użytkownika.

  1. Microsoft Corporation UEFI CA 2011

    • Skrót certyfikatu SHA-1: 46DEF63B5CE61CF8BA0DE2E6639C1019D0ED14F3.
    • WłaścicielPodpisu GUID: {77fa9abd-0359-4d32-bd60-28f4e78f784b}.
    • Microsoft udostępni certyfikat partnerom i może on zostać dodany jako podpis typu EFI_CERT_X509_GUID lub EFI_CERT_RSA2048_GUID.
    • UEFI CA Microsoft Corporation 2011 można pobrać tutaj: https://go.microsoft.com/fwlink/p/?linkid=321194.

  2. Microsoft UEFI CA 2023

    • Skrót certyfikatu SHA-1: B5EEB4A6706048073F0ED296E7F580A790B59EAA.
    • WłaścicielPodpisu GUID: {77fa9abd-0359-4d32-bd60-28f4e78f784b}.
    • Microsoft udostępni certyfikat partnerom i może on zostać dodany jako podpis typu EFI_CERT_X509_GUID lub EFI_CERT_RSA2048_GUID.
    • Urząd certyfikacji Microsoft UEFI 2023 można pobrać tutaj: https://go.microsoft.com/fwlink/?linkid=2239872.

  3. Microsoft Option ROM UEFI CA 2023

    • Skrót certyfikatu SHA-1: 3FB39E2B8BD183BF9E4594E72183CA60AFCD4277.
    • WłaścicielPodpisu GUID: {77fa9abd-0359-4d32-bd60-28f4e78f784b}.
    • Microsoft udostępni certyfikat partnerom i może on zostać dodany jako podpis typu EFI_CERT_X509_GUID lub EFI_CERT_RSA2048_GUID.
    • Opcja Microsoft ROM UEFI CA 2023 można pobrać tutaj: https://go.microsoft.com/fwlink/?linkid=2284009.

  • 1.4.2 DbDefault: dostawca platformy musi podać domyślny zestaw wpisów dla bazy danych sygnatur w zmiennej dbDefault. Aby uzyskać więcej informacji, zobacz sekcję 27.5.3 w specyfikacji UEFI.

  • 1.4.3 Zabroniona baza danych sygnatur (dbx)

    Zawartość EFI_IMAGE_SIGNATURE_DATABASE1 dbx należy sprawdzić w trakcie weryfikacji obrazów przed sprawdzeniem bazy danych, a wszelkie dopasowania muszą uniemożliwić wykonanie obrazu. Baza danych może zawierać wiele certyfikatów, kluczy i skrótów w celu zidentyfikowania zabronionych obrazów. Wymagania dotyczące certyfikacji sprzętu systemu Windows stanowią, że dbx musi być obecny, więc każda fikcyjna wartość, taka jak skrót 0SHA-256 , może być używana jako bezpieczny symbol zastępczy, dopóki firma Microsoft nie rozpocznie dostarczania aktualizacji dbx. Kliknij tutaj , aby pobrać najnowszą listę odwołania UEFI od firmy Microsoft.

  • 1.4.4 DbxDefault: dostawca platformy może udostępnić domyślny zestaw wpisów dla bazy danych sygnatur w zmiennej dbxDefault. Aby uzyskać więcej informacji, zobacz sekcję 27.5.3 w specyfikacji UEFI.

1.5 Klucze wymagane do bezpiecznego rozruchu na wszystkich komputerach

Uwaga / Notatka

Producenci urządzeń, przedsiębiorstwa i klienci mogą znaleźć zalecane pliki binarne PK, KEK, DB i DBX firmy Microsoft w repozytorium open source secure boot firmy Microsoft. Pliki binarne są formatowane zgodnie z oczekiwanym formatem EDKII, aby łatwo zintegrować je z oprogramowaniem układowym.

Nazwa klucza/bazy danych Zmienna Właściciel Notatki

PKpub

PK

producent oryginalnego wyposażenia (OEM)

PK: tylko 1. Musi być RSA 2048 lub silniejszy.

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

Microsoft Corporation KEK 2K CA 2023

Klucz szyfrowania kluczy

Microsoft

Zezwala na aktualizacje bazy danych i dbx:

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

Windows UEFI CA 2023

baza danych

Microsoft

Urząd certyfikacji (CA) w bazie danych sygnatur umożliwia rozruch systemu Windows: https://go.microsoft.com/fwlink/?LinkId=2239776

Zabroniona baza danych podpisów

dbx (Biblioteka Danych

Microsoft

Lista kluczy, urzędów certyfikacji lub obrazów firmy Microsoft, które są znane jako nieprawidłowe

Bezpieczny klucz aktualizacji oprogramowania układowego

producent oryginalnego wyposażenia (OEM)

Zaleca się, aby ten klucz różnił się od klucza PK

Tabela 1. Klucze/baza danych potrzebne do bezpiecznego rozruchu

1.6 Wymagania dotyczące konfiguracji bezpiecznego rozruchu UEFI dla urządzeń z systemem Windows 11 w wersji 25H2+

Producenci OEM muszą upewnić się, że konfiguracja bezpiecznego rozruchu UEFI aprowizowana i dostarczana na urządzeniach z systemem Windows 11, 25H2+ ze wstępnie załadowanym systemem Windows obejmuje następujące elementy:

PK

OEM lub Microsoft PK

Klucz szyfrowania kluczy

Microsoft Corporation KEK 2K CA 2023

DB

Windows UEFI CA 2023

DBX

Najnowszy pakiet dbx

W przypadku urządzeń, które mają obsługiwać system Linux, inne aplikacje UEFI innych firm lub obejmują specjalny sprzęt wymagający opcji ROM, producenci OEM mogą dostarczać urządzenia z tą alternatywną konfiguracją:

PK

OEM lub Microsoft PK

Klucz szyfrowania kluczy

Microsoft Corporation KEK 2K CA 2023

DB

Windows UEFI CA 2023
Microsoft UEFI CA 2023
Microsoft Corporation UEFI CA 2011
Microsoft Option ROM UEFI CA 2023

DBX

Najnowszy pakiet dbx

Producenci OEM muszą dostarczyć urządzenie z menedżerem rozruchu systemu Windows z podpisem UEFI CA 2023 zarówno na urządzeniu, jak i na nośniku rozruchowym dostarczonym z urządzeniem. Dzięki temu urządzenie będzie korzystać z Menedżera rozruchu systemu Windows, który będzie nadal serwisowany po wygaśnięciu certyfikatów z 2011 roku.

Chociaż nie zaleca się wysyłania urządzeń ze wstępnie załadowanym systemem Windows, mogą być używane następujące konfiguracje:

  • Microsoft Windows Production PCA 2011, Microsoft Corporation UEFI CA 2011 i Microsoft Corporation KEK CA 2011 mogą być uwzględnione tylko w celu zachowania zgodności rozruchu ze starszymi lub jeszcze nie zaktualizowanymi systemami i aplikacjami UEFI innych firm.
  • W razie potrzeby urząd certyfikacji UEFI OEM może zostać uwzględniony w bazie danych dla każdej z powyższych konfiguracji.

Aby zapoznać się z zalecaną zawartością dla wszystkich zmiennych UEFI bezpiecznego rozruchu, zapoznaj się z repozytorium otwartoźródłowym bezpiecznego rozruchu firmy Microsoft. W przypadku zawartości dbx odwołania zostaną podzielone i zastosowane na podstawie certyfikatów podpisywania znajdujących się w zmiennych KEK i DB urządzenia.

Rozwiązania w zakresie zarządzania kluczami

Poniżej podano niektóre metryki użyte do porównania.

2.1 Użyte metryki

Poniższe metryki mogą pomóc wybrać komputer HSM na podstawie wymagań specyfikacji UEFI 2.3.1 Errata C i Twoich potrzeb.

  • Czy obsługuje on rsa 2048 lub nowszy? - Specyfikacja UEFI 2.3.1 Errata C zaleca, aby klucze były na poziomie RSA-2048 lub lepsze.
  • Czy ma możliwość generowania kluczy i podpisywania?
  • Ile kluczy może przechowywać? Czy przechowuje klucze na HSM lub na dołączonym serwerze?
  • Metoda uwierzytelniania do pobierania kluczy. Niektóre komputery obsługują wiele jednostek uwierzytelniania, które mają być obecne na potrzeby pobierania klucza.

Ceny

  • Jaki jest punkt cenowy? Moduły HSM mogą wahać się w cenie od $1,500 do $70,000 w zależności od dostępnych funkcji.

Środowisko produkcyjne

  • Szybkość pracy na hali produkcyjnej. Procesory kryptograficzne mogą przyspieszyć tworzenie kluczy i dostęp.
  • Łatwość instalacji, wdrażania, konserwacji.
  • Wymagany zestaw umiejętności i szkolenie?
  • Dostęp do sieci na potrzeby tworzenia kopii zapasowych i wysokiej dostępności

Standardy i zgodność

  • Jaki poziom zgodności ze standardem FIPS ma? Czy jest odporny na manipulacje?
  • Obsługa innych standardów, na przykład interfejsów API kryptograficznych MS.
  • Czy spełnia wymagania rządu i innych agencji?

Niezawodność i odzyskiwanie po awarii

  • Czy zezwala na tworzenie kopii zapasowej kluczy?

    Kopie zapasowe mogą być przechowywane zarówno lokalnie w bezpiecznym miejscu, które znajduje się w innej lokalizacji fizycznej niż komputer urzędu certyfikacji i moduł HSM, jak również poza lokalem.

  • Czy umożliwia wysoką dostępność na potrzeby odzyskiwania po awarii?

2.2 Opcje zarządzania kluczami

  • 2.2.1 Sprzętowy moduł zabezpieczeń (HSM)

    Na podstawie powyższych kryteriów jest to prawdopodobnie najbardziej odpowiednie i bezpieczne rozwiązanie. Większość modułów HSM ma zgodność ze standardem FIPS 140–2 na poziomie 3. Zgodność ze standardem FIPS 140–2 na poziomie 3 jest ścisła w przypadku uwierzytelniania i wymaga, aby klucze nie zostały wyeksportowane ani zaimportowane z modułu HSM.

    Obsługują one wiele sposobów przechowywania kluczy. Mogą być przechowywane lokalnie na samym module HSM lub na serwerze dołączonym do modułu HSM. Na serwerze klucze są szyfrowane i przechowywane i preferowane w przypadku rozwiązań, które wymagają przechowywania wielu kluczy.

    Zasady zabezpieczeń modułu kryptograficznego określają zasady zabezpieczeń fizycznych, w tym fizyczne mechanizmy zabezpieczeń, które są implementowane w module kryptograficznym, takie jak uszczelnienia umożliwiające wykrycie naruszenia, blokady, reagowanie na naruszenia i przełączniki zerowe oraz alarmy. Umożliwia również określenie akcji wymaganych przez operatorów w celu zapewnienia, że bezpieczeństwo fizyczne jest utrzymywane, takie jak okresowa inspekcja uszczelnień widocznych dla manipulacji lub testowanie reakcji na naruszenia i przełączników zerowania.

    • 2.2.1.1 Moduł HSM sieci

      To rozwiązanie jest najlepsze w swojej klasie pod względem zabezpieczeń, zgodności ze standardami, generowaniem kluczy, magazynem i pobieraniem. Większość tych komputerów obsługuje wysoką dostępność i ma możliwość tworzenia kopii zapasowych kluczy.

      Koszty tych produktów mogą być w dziesiątkach tysięcy dolarów na podstawie dodatkowych usług, które oferują.

    • 2.2.1.2 Autonomiczny moduł HSM

      Te funkcje doskonale sprawdzają się w przypadku serwerów autonomicznych. Można użyć programu Microsoft CAPI i CNG lub innego bezpiecznego interfejsu API obsługiwanego przez moduł HSM. Te moduły HSM są dostępne w różnych formach obsługujących magistrale USB, PCIe i PCMCIA.

      Opcjonalnie obsługują one tworzenie kopii zapasowych kluczy i wysoką dostępność.

  • 2.2.2 Dostawcy rozwiązań niestandardowych

    Kryptografia klucza publicznego może być trudna i wymagać zrozumienia pojęć kryptograficznych, które mogą być nowe. Istnieją dostawcy rozwiązań niestandardowych, którzy mogą pomóc w zapewnieniu bezpiecznego rozruchu do pracy w środowisku produkcyjnym.

    Istnieją różne niestandardowe rozwiązania oferowane przez dostawców BIOS, firmy HSM i firmy konsultingowe PKI, aby zapewnić działanie Secure Boot PKI w środowisku produkcyjnym.

    Poniżej wymieniono niektórych dostawców:

  • Moduł TPM (Trusted Platform Module) 2.2.3

    Moduł TPM (Trusted Platform Module) to układ sprzętowy na płycie głównej, który przechowuje klucze kryptograficzne używane do szyfrowania. Wiele komputerów obejmuje moduł TPM, ale jeśli komputer go nie zawiera, nie można go dodać. Po włączeniu, moduł Trusted Platform Module może pomóc w zabezpieczeniu produktów pełnego szyfrowania dysków, takich jak funkcje Microsoft BitLocker. Przechowuje dyski twarde zablokowane lub zapieczętowane, dopóki komputer nie ukończy procesu weryfikacji systemu lub uwierzytelniania.

    Moduł TPM może generować, przechowywać i chronić klucze używane w procesie szyfrowania i odszyfrowywania.

    Wadami modułów TPM jest to, że może nie mieć szybkich procesorów kryptograficznych w celu przyspieszenia przetwarzania w środowisku produkcyjnym. Nie są one również odpowiednie do przechowywania dużej liczby kluczy. Kopie zapasowe, wysoka dostępność i zgodność ze standardami FIPS 140-2 na poziomie 3 mogą być niedostępne.

  • 2.2.4 Karty inteligentne

    Karta inteligentna może generować i przechowywać klucze. Udostępniają one niektóre funkcje, które obsługują HSM, takie jak uwierzytelnianie i zabezpieczenie przed manipulacją, ale nie mają za dużo miejsca na przechowywanie kluczy czy kopii zapasowej. Wymagają one ręcznej interwencji i mogą nie być odpowiednie do automatyzacji i użycia w środowisku produkcyjnym, ponieważ wydajność może być niska.

    Wady kart inteligentnych są podobne do TPM. Mogą nie mieć szybkich procesorów kryptograficznych w celu przyspieszenia przetwarzania w środowisku produkcyjnym. Nie są one również odpowiednie do przechowywania dużej liczby kluczy. Kopie zapasowe, wysoka dostępność i zgodność ze standardami FIPS 140-2 na poziomie 3 mogą być niedostępne.

  • 2.2.5 Certyfikat rozszerzonej weryfikacji

    Certyfikaty EV to certyfikaty o wysokiej gwarancji, których klucze prywatne są przechowywane w tokenach sprzętowych. Pomaga to ustanowić silniejsze praktyki zarządzania kluczami. Certyfikaty EV mają te same wady co karty inteligentne.

  • 2.2.6 Podejścia skoncentrowane na oprogramowaniu (NIEZALECANE)

    Użyj interfejsów API kryptograficznych do zarządzania kluczami. Może to obejmować przechowywanie klucza w kontenerze kluczy na zaszyfrowanym dysku twardym oraz ewentualne dodatkowe użycie maszyny wirtualnej do sandboxingu i zwiększenia zabezpieczeń.

    Te rozwiązania nie są tak bezpieczne, jak używanie modułu HSM i uwidaczniają wyższy wektor ataku.

    2.2.6.1 Makecert (NIEZALECANE)

    Makecert jest narzędziem firmy Microsoft i może być używany w następujący sposób na potrzeby generowania kluczy. Aby upewnić się, że powierzchnia ataku jest zminimalizowana, może zajść konieczność fizycznego odizolowania komputera. Komputer osobisty z kluczem PKpriv nie powinien być połączony z siecią. Powinna znajdować się w bezpiecznej lokalizacji i najlepiej używać co najmniej czytnika kart inteligentnych, jeśli nie rzeczywistego modułu HSM.

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

    Aby uzyskać więcej informacji, zobacz Narzędzie do tworzenia certyfikatów (Makecert.exe).

    To rozwiązanie nie jest zalecane.

2.3 Generowanie kluczy HSM i przechowywanie kluczy Secure Boot

  • 2.3.1 Przechowywanie kluczy prywatnych

    Wymagania dotyczące miejsca dla każdego klucza RSA-2048 to 2048 bitów. Rzeczywista lokalizacja magazynu kluczy zależy od wybranego rozwiązania. Moduły HSM są dobrym sposobem na przechowywanie kluczy.

    Fizyczna lokalizacja komputerów na hali produkcyjnej musi być obszarem chronionym z ograniczonym dostępem użytkowników, takimi jak bezpieczna klatka.

    W zależności od wymagań te klucze mogą być również przechowywane w zróżnicowanej lokalizacji geograficznej lub kopii zapasowej w innej lokalizacji.

    Wymagania dotyczące ponownego instalowania tych kluczy mogą się różnić w zależności od klienta (zobacz dodatek A dla federalnych wytycznych dotyczących ponownego instalowania kluczy przez urząd certyfikacji mostka).

    Można to zrobić raz na rok. Może być konieczne uzyskanie dostępu do tych kluczy przez maksymalnie 30 lat (w zależności od wymagań dotyczących ponownego klucza itp.).

  • 2.3.2 Pobieranie kluczy prywatnych

    Z wielu powodów może być konieczne pobranie kluczy.

    1. Może być konieczne odzyskanie klucza PK, aby wydać jego zaktualizowaną wersję z powodu naruszenia bezpieczeństwa lub zgodności z przepisami rządowymi i innymi regulacjami agencji.
    2. KEKpri będzie używane do aktualizowania db i dbx.
    3. Bezpieczny klucz aktualizacji oprogramowania układowego — pri będzie używany do podpisywania nowszych aktualizacji.

  • 2.3.3 Uwierzytelnianie

    Zgodnie z FIPS 140-2 uwierzytelnianie jest oparte na poziomie dostępu.

    Poziom 2

    Poziom zabezpieczeń 2 wymaga co najmniej uwierzytelniania opartego na rolach, w którym moduł kryptograficzny uwierzytelnia autoryzację operatora, aby objąć określoną rolę i wykonać odpowiedni zestaw usług.

    Poziom 3

    Poziom zabezpieczeń 3 wymaga mechanizmów uwierzytelniania opartych na tożsamościach, zwiększając bezpieczeństwo zapewniane przez mechanizmy uwierzytelniania opartego na rolach określone dla poziomu zabezpieczeń 2. Moduł kryptograficzny uwierzytelnia tożsamość operatora i sprawdza, czy zidentyfikowany operator jest autoryzowany do przyjęcia określonej roli i wykonywania odpowiedniego zestawu usług.

    Komputery PC, takie jak HSM, obsługują poziom bezpieczeństwa 3, który wymaga opartego na tożsamości uwierzytelniania 'k z m'. Oznacza to, że jednostki k mają dostęp do modułu HSM z tokenem, ale w danym momencie co najmniej k z tokenów m muszą być obecne, aby uwierzytelnianie działało w celu uzyskania dostępu do kluczy prywatnych z modułu HSM.

    Na przykład do uzyskania dostępu do modułu HSM należy uwierzytelnić 3 z 5 tokenów. Członkowie ci mogą być funkcjonariuszami ochrony, autoryzatorem transakcji i/lub członkami zarządu wykonawczego.

    Tokeny modułu HSM

    Możesz mieć zasady dotyczące modułu HSM, które wymagają obecności tokenu:

    • Lokalnie

    • Zdalnie

    • Skonfigurowane do zautomatyzowania

    Dobrym rozwiązaniem jest użycie kombinacji standardowego tokenu oraz hasła przypisanego do każdego tokenu.

2.4 Bezpieczne uruchamianie i podpisywanie przez strony trzecie

  • 2.4.1 Podpisywanie sterowników UEFI

    Sterowniki UEFI muszą być podpisane przez urząd certyfikacji lub klucz w bazie danych UEFI, zgodnie z opisem w innym miejscu dokumentu, lub zawierać skrót obrazu sterownika dołączony do tej bazy danych. Firma Microsoft będzie świadczyć usługę podpisywania sterowników UEFI podobną do usługi podpisywania sterowników WHQL, wykorzystując Microsoft UEFI CA 2023. Wszystkie sterowniki podpisane za pomocą tego będą bezproblemowo działać na wszystkich komputerach, które posiadają certyfikat UEFI firmy Microsoft. Istnieje również możliwość podpisania zaufanych sterowników przez producenta OEM i dołączenia urzędu certyfikacji OEM do bazy danych lub uwzględnienia skrótów sterowników w bazie danych. We wszystkich przypadkach sterownik UEFI (Opcja ROM) nie jest wykonywany, jeśli nie jest zaufany w bazie danych.

    Nie trzeba ponownie weryfikować wszystkich sterowników zawartych w obrazie oprogramowania układowego systemu. Bycie częścią obrazu systemowego zapewnia wystarczającą pewność, że sterownik jest zaufany na komputerze.

    Firma Microsoft udostępniła to każdemu, kto chce podpisać sterowniki UEFI. Ten certyfikat jest częścią testów bezpiecznego rozruchu HCK systemu Windows. Śledź [ten blog]((https://blogs.msdn.microsoft.com/windows_hardware_certification/2013/12/03/microsoft-uefi-ca-signing-policy-updates/), aby dowiedzieć się więcej na temat polityki podpisywania i aktualizacji UEFI CA.

  • 2.4.2 Programy rozruchowe

    Certyfikat podpisywania sterowników UEFI firmy Microsoft może służyć do podpisywania innych systemów operacyjnych. Na przykład program ładujący system Linux Fedora będzie podpisany.

    To rozwiązanie nie wymaga dodania więcej certyfikatów do bazy danych kluczy. Oprócz bycia opłacalnym, można go stosować w każdej dystrybucji Linuksa. To rozwiązanie działałoby w przypadku dowolnego sprzętu, który obsługuje system Windows, więc jest przydatny dla szerokiego zakresu sprzętu.

    UEFI-CA można pobrać tutaj: https://go.microsoft.com/fwlink/p/?LinkID=321194. Poniższe linki zawierają więcej informacji na temat podpisywania i przesyłania w systemie Windows HCK UEFI:

3. Podsumowanie i zasoby

W tej sekcji zamierzasz podsumować powyższe sekcje i przedstawić podejście krok po kroku:

  1. Zaprojektuj bezpieczny urząd certyfikacji (CA) lub zidentyfikuj partnera do bezpiecznego generowania i przechowywania kluczy

    Jeśli nie używasz rozwiązania innej firmy:

    1. Zainstaluj i skonfiguruj oprogramowanie HSM na serwerze HSM. Aby uzyskać instrukcje dotyczące instalacji, zapoznaj się z instrukcjami dotyczącymi dokumentacji modułu HSM. Serwer zostanie połączony z autonomicznym lub sieciowym modułem HSM.

      Aby uzyskać informacje o konfiguracji modułu HSM, zobacz sekcję 2.2.1, 2.3 i dodatek C.

      Większość modułów HSM oferuje zgodność ze standardem FIPS 140-2 na poziomie 2 i 3. Skonfiguruj moduł HSM do zgodności z poziomem 2 lub poziomem 3. Zgodność na poziomie 3 ma bardziej rygorystyczne wymagania dotyczące uwierzytelniania i dostępu do klucza, dlatego jest bezpieczniejsza. Zalecany jest poziom 3.

    2. Skonfiguruj moduł HSM pod kątem wysokiej dostępności, tworzenia kopii zapasowych i uwierzytelniania. Zapoznaj się z instrukcjami referencyjnymi modułu HSM.

      Postępuj zgodnie z wytycznymi dostawcy modułu HSM dotyczącymi konfigurowania modułu HSM pod kątem wysokiej dostępności i tworzenia kopii zapasowych.

      Ponadto sieciowe moduły HSM zwykle mają wiele portów sieciowych do segregowania ruchu, umożliwiając serwerowi komunikację z sieciowymi modułami HSM w sieci oddzielonej od zwykłej sieci produkcyjnej.

      Po zidentyfikowaniu członków zespołu będących częścią zespołu ds. zabezpieczeń i przypisaniu im tokenów. Należy skonfigurować sprzęt HSM na potrzeby uwierzytelniania k-of-m.

    3. Klucze bezpiecznego rozruchu i przedgenerowanie certyfikatów. Zobacz sekcje od 1.3 do 1.5

      Użyj interfejsów API modułu HSM, aby wstępnie wygenerować (generować z wyprzedzeniem) klucz PK i klucz aktualizacji oprogramowania układowego oraz certyfikaty.

      Wymagane — PK (zalecane 1 na model), Firmware Update key (zalecane 1 na model), Microsoft KEK, Db, Dbx UWAGA: Microsoft KEK, db i dbx nie muszą być generowane przez OEM i są wymienione dla kompletności. Opcjonalnie — KEK firmy OEM/innej firmy, db, dbx i inne klucze, które mogą być wprowadzone do bazy danych OEM.

  2. Zastosuj obraz systemu Windows do komputera.

  3. Zainstaluj bazę danych firmy Microsoft i bazę danych dbx. Zobacz Sekcję 1.3.6 i dodatek B – API bezpiecznego rozruchu.

    1. Zainstaluj Windows UEFI CA 2023 w bazie danych.

    2. Zainstaluj pusty dbx, jeśli firma Microsoft go nie udostępnia. System Windows automatycznie zaktualizuje dbX do najnowszej wersji DBX za pośrednictwem usługi Windows Update podczas pierwszego ponownego rozruchu.

    Uwaga / Notatka

    Użyj poleceń cmdlet programu PowerShell, które są częścią testów HCK systemu Windows lub używają metod dostarczonych przez dostawcę systemu BIOS.

  4. Zainstaluj Microsoft KEK. Zobacz sekcję 1.3.3.

    Instalowanie klucza KEK firmy Microsoft w bazie danych UEFI KEK

    Ostrzeżenie

    Użyj poleceń cmdlet programu PowerShell, które są częścią testów HCK systemu Windows lub używają metod dostarczonych przez dostawcę systemu BIOS.

  5. Opcjonalny krok — składniki bezpiecznego rozruchu producenta OEM/podmiotu trzeciego. Zobacz sekcję 1.3.4 i 1.4.

    1. Zidentyfikuj, czy potrzebujesz utworzyć klucz KEK, bazę danych db i dbx dla OEM lub innej firmy.

    2. Podpisz bazę danych producenta OEM/innej firmy i bazę danych dbx przy użyciu klucza KEK (wygenerowanego wcześniej) przy użyciu interfejsu API modułu HSM.

    3. Zainstaluj oprogramowanie OEM/innej firmy KEK, db i dbx.

  6. Podpisywanie sterowników UEFI — zobacz sekcję 2.4.

    Jeśli chcesz obsługiwać karty rozszerzeń lub inne sterowniki/aplikacje/bootloadery UEFI, zainstaluj Microsoft UEFI CA 2023 i Microsoft Corporation UEFI CA 2011 w bazie danych UEFI.

  7. Klucz aktualizacji oprogramowania układowego bezpiecznego rozruchu — zobacz sekcję 1.3.5.

    1. Tylko komputery z systemem Innym niż Windows RT: zainstaluj klucz publiczny aktualizacji bezpiecznego oprogramowania układowego lub jego skrót, aby zaoszczędzić miejsce.

    2. Tylko na układach SoC może być konieczne zrobienie czegoś innego, na przykład zapisanie zabezpieczonego klucza aktualizacji oprogramowania układowego: publicznego lub jego skrótu.

  8. Włączanie bezpiecznego rozruchu. Zobacz Dodatek B — bezpieczne interfejsy API rozruchu.

    1. Zainstaluj PKpub OEM/ODM (preferowany certyfikat, ale klucz jest w porządku) w kluczu PK UEFI.

    2. Zarejestruj klucz PK przy użyciu interfejsu API bezpiecznego rozruchu. Komputer powinien być teraz włączony na potrzeby bezpiecznego rozruchu.

    Uwaga / Notatka

    Jeśli zainstalujesz klucz PK na końcu, klucz MS KEK, db, dbx nie muszą być podpisane — nie jest wymagana informacja SignerInfo. Jest to skrót.

  9. Testowanie bezpiecznego rozruchu: wykonaj wszystkie zastrzeżone testy i testy HCK systemu Windows zgodnie z instrukcjami. Zobacz Dodatek B — bezpieczne interfejsy API rozruchu.

  10. Platforma wysyłkowa: PKpriv prawdopodobnie nigdy nie będzie używany ponownie, zachowaj bezpieczeństwo.

  11. pl-PL: Obsługa: przyszłe aktualizacje oprogramowania układowego są bezpiecznie podpisane przy użyciu prywatnego klucza do bezpiecznej aktualizacji oprogramowania układowego, co zapewnia usługa podpisywania.

3.1 Zasoby

Oficjalny dokument strategii zabezpieczeń — https://go.microsoft.com/fwlink/p/?linkid=321288

Nadsyłanie HCK systemu Windows —https://go.microsoft.com/fwlink/p/?linkid=321287

Dodatek A — lista kontrolna PKI bezpiecznego rozruchu dla produkcji

Poniżej znajduje się lista kontrolna wysokiego poziomu podsumowująca kroki wymagane do włączenia bezpiecznego rozruchu na komputerach spoza systemu Windows RT.

Konfigurowanie bezpiecznego rozruchu

  1. Zdefiniuj strategię zabezpieczeń (zidentyfikuj zagrożenia, zdefiniuj strategię proaktywną i reaktywną) zgodnie z oficjalnym dokumentem w sekcji 4.

  2. Zidentyfikuj zespół ds. zabezpieczeń zgodnie z białą księgą w sekcji 4.

  3. Ustanów bezpieczny urząd certyfikacji lub zidentyfikuj partnera (zalecane rozwiązanie) w celu bezpiecznego generowania i przechowywania kluczy.

  4. Zidentyfikuj zasady dotyczące częstotliwości ponownego generowania kluczy. Może to zależeć od tego, czy masz jakiekolwiek specjalne wymagania klienta, takie jak instytucje rządowe lub inne agencje.

  5. Jeśli klucz bezpiecznego rozruchu zostanie naruszony, należy mieć plan awaryjny.

  6. Określ liczbę kluczy PK i innych kluczy, które będą generowane zgodnie z sekcją 1.3.3 i 1.5.

    Będzie to oparte na bazie klienta, rozwiązaniu magazynu kluczy i zabezpieczeniach komputerów.

    Jeśli używasz zalecanego rozwiązania do zarządzania kluczami przez zewnętrznego dostawcę, możesz pominąć kroki 7–8.

  7. Pozyskiwanie serwera i sprzętu do zarządzania kluczami. — sieć lub autonomiczny moduł HSM zgodnie z sekcją 2.2.1. Zastanów się, czy potrzebujesz jednego lub kilku modułów HSM w celu zapewnienia wysokiej dostępności i strategii tworzenia kopii zapasowej klucza.

  8. Zidentyfikuj co najmniej 3–4 członków zespołu, którzy będą mieli token uwierzytelniania na potrzeby uwierzytelniania w module HSM.

  9. Użyj modułu HSM lub innej firmy, aby wstępnie wygenerować klucze i certyfikaty związane z bezpiecznym rozruchem. Klucze będą zależeć od typu komputera: SoC, Windows RT lub innej niż Windows RT. Aby uzyskać więcej informacji, zobacz sekcje od 1.3 do 1.5.

  10. Załaduj firmware odpowiednimi kluczami.

  11. Zarejestruj klucz platformy bezpiecznego rozruchu, aby włączyć bezpieczny rozruch. Aby uzyskać więcej informacji, zobacz Dodatek B.

  12. Wykonaj wszystkie zastrzeżone testy i testy bezpiecznego rozruchu HCK zgodnie z instrukcjami. Aby uzyskać więcej informacji, zobacz Dodatek B.

  13. Wysyłka komputera. PKpriv prawdopodobnie nigdy nie będzie używany ponownie, zachowaj bezpieczeństwo.

Obsługa (aktualizowanie oprogramowania układowego)

Może być konieczne zaktualizowanie oprogramowania układowego z kilku powodów, takich jak aktualizowanie składnika UEFI lub naprawianie naruszenia bezpieczeństwa klucza bezpiecznego rozruchu lub okresowe ponowne tworzenie kluczy bezpiecznego rozruchu.

Aby uzyskać więcej informacji, zobacz sekcję 1.3.5 i sekcję 1.3.6.

Dodatek B — interfejsy API bezpiecznego rozruchu

  1. API Bezpiecznego Rozruchu

    Następujące interfejsy API są powiązane z UEFI/Secure Boot:

    1. GetFirmwareEnvironmentVariableEx: pobiera wartość określonej zmiennej środowiskowej oprogramowania układowego.

    2. SetFirmwareEnvironmentVariableEx: ustawia wartość określonej zmiennej środowiskowej oprogramowania układowego.

    3. GetFirmwareType: pobiera typ oprogramowania układowego.

  2. Ustawianie klucza PK

    Użyj polecenia cmdlet Set-SecureBootUEFI, aby włączyć bezpieczny rozruch. Po ustawieniu klucza PK, wymuszanie funkcji bezpiecznego rozruchu nie będzie aktywne aż do następnego ponownego uruchomienia. Przed ponownym uruchomieniem kod może wywołać metodę GetFirmwareEnvironmentVariableEx() lub polecenie cmdlet programu PowerShell: Get-SecureBootUEFI w celu potwierdzenia zawartości baz danych bezpiecznego rozruchu.

  3. Weryfikacja

    Aby sprawdzić stan zmiennej bezpiecznego rozruchu, możesz użyć Msinfo32.exe lub poleceń cmdlet programu PowerShell. Brak interfejsu WMI. Można również przetestować, wstawiając niepoprawnie podpisany rozruchowy dysk USB (na przykład z testu ręcznego logowania bezpiecznego rozruchu systemu Windows HCK) i sprawdzić, czy nie można go uruchomić.

  4. Polecenia cmdlet programu PowerShell bezpiecznego rozruchu

    • Confirm-SecureBootUEFI: czy bezpieczny rozruch UEFI jest "WŁĄCZONY", prawda czy fałsz?

      SetupMode == 0 && SecureBoot == 1

    • Set-SecureBootUEFI: ustawianie lub dołączanie uwierzytelnionych zmiennych interfejsu UEFI SecureBoot

    • Get-SecureBootUEFI: Uzyskiwanie uwierzytelnionych wartości zmiennych UEFI SecureBoot

    • Format-SecureBootUEFI: tworzy serializacji EFI_SIGNATURE_LISTs i EFI_VARIABLE_AUTHENTICATION_2

  5. Windows HCK i instrukcje bezpiecznego rozruchu

    Poniższe kroki dotyczą testów systemowych oraz testów komputerów z niestandardowymi sterownikami.

    1. Wyłącz zabezpieczenia bezpiecznego rozruchu.

      Wprowadź konfigurację systemu BIOS i wyłącz bezpieczny rozruch.

    2. Zainstaluj oprogramowanie klienckie HCK.

    3. Uruchom wszystkie testy HCK systemu Windows, z wyjątkiem następujących:

      • Testy modułu TPM BitLocker oraz haseł odzyskiwania przy użyciu protokołu PCR[7]
      • Testy modułu TPM oraz haseł odzyskiwania BitLocker dla komputerów ARM z Bezpiecznym rozruchem
      • Test logo bezpiecznego rozruchu
      • Test ręcznego logo Bezpiecznego Rozruchu

    4. Wprowadź konfigurację systemu BIOS, włącz bezpieczny rozruch i przywróć bezpieczny rozruch do konfiguracji domyślnej.

    5. Uruchom następujące testy funkcji BitLocker i bezpiecznego rozruchu:

      • Testy modułu TPM BitLocker oraz haseł odzyskiwania przy użyciu protokołu PCR[7]
      • Testy modułu TPM oraz haseł odzyskiwania BitLocker dla komputerów ARM z Bezpiecznym rozruchem
      • Test logo bezpiecznego rozruchu (zautomatyzowany)

    6. Wprowadź konfigurację systemu BIOS i wyczyść konfigurację bezpiecznego rozruchu. Spowoduje to przywrócenie komputera do trybu konfiguracji przez usunięcie klucza PK i innych kluczy.

      Uwaga / Notatka

      Obsługa czyszczenia jest wymagana dla komputerów x86/x64.

    7. Uruchom test ręczny logo bezpiecznego rozruchu.

      Uwaga / Notatka

      Bezpieczny rozruch wymaga sterowników podpisanych przez Windows HCK lub VeriSign na komputerach innych niż te z systemem Windows RT.

  6. Zautomatyzowany test logo Bezpiecznego Rozruchu Windows HCK

    Ten test sprawdzi poprawną konfigurację bezpiecznego rozruchu. Obejmuje to:

    • Bezpieczny rozruch jest włączony.
    • Podany PK nie jest znanym, testowym PK.
    • Klucz KEK zawiera produkcyjny klucz KEK firmy Microsoft.
    • baza danych zawiera produkcyjny urząd certyfikacji systemu Windows.
    • dbx obecny.
    • Wiele zmiennych 1kB jest tworzonych/usuwanych.
    • Zmienna o wielkości 32 kB jest tworzona/usuwana.

  7. Układ folderu testowego dla ręcznego testu Secure Boot w Windows HCK

    Układ folderu testowego Windows HCK Secure Boot Manual Logo został opisany poniżej:

    • "\Test" folder ma następujące elementy:

      • Test produkcji i obsługi
      • Programowe włączanie bezpiecznego rozruchu w konfiguracji testowej
      • Testy obsługi
      • Dołączanie certyfikatu do bazy danych, weryfikacja funkcji
      • Dołączanie skrótu do dbx, funkcja verify
      • Dołączanie certyfikatu do dbx, weryfikacja funkcji
      • Dodaj ponad 600 skrótów do dbx, zweryfikuj rozmiar
      • Programowa zmiana klucza głównego

    • "\Generate" Folder zawiera skrypty, które pokazują następujące elementy:

      • Jak zostały utworzone certyfikaty testowe

      • Dołączone są certyfikaty testowe i klucze prywatne

      • Jak zostały utworzone wszystkie testy

      • Przekształcanie certyfikatów i skrótów w podpisane pakiety

      • Możesz uruchomić to samodzielnie, zastąpić własne certyfikaty

    • "\certs" Folder zawiera wszystkie certyfikaty potrzebne do rozruchu systemu Windows:

      Uwaga / Notatka

      Nie używaj metodologii używanej w programie "ManualTests\generate\TestCerts" do generowania kluczy i certyfikatów. Jest to przeznaczone tylko dla celów testowych HCK systemu Windows. Używa kluczy przechowywanych na dysku, które są bardzo niezabezpieczone i niezalecane. Nie jest to przeznaczone do użytku w środowisku produkcyjnym.

  • "ManualTests\example\OutOfBox" Folder zawiera skrypty, których można użyć do instalacji bezpiecznego rozruchu na komputerach produkcyjnych.

    Pokazuje to, "ManualTests\generate\tests\subcreate_outofbox_example.ps1" jak te przykłady zostały wygenerowane i zawierają sekcje "TODO", gdy partner może zastąpić swój klucz główny i inne metadane.

  1. Windows HCK UEFI podpisanie i złożenie

    Poniższe linki zawierają więcej informacji:

Dodatek C — mapowania kontroli certyfikatów urzędu certyfikacji mostu federalnego

  1. Podstawowy

    Ten poziom zapewnia najniższy stopień zapewnienia tożsamości osoby. Jedną z podstawowych funkcji tego poziomu jest zapewnienie integralności danych podpisywanych informacji. Ten poziom jest istotny dla środowisk, w których ryzyko złośliwego działania jest uważane za niskie. Nie jest odpowiednia dla transakcji wymagających uwierzytelniania i jest ogólnie niewystarczająca w przypadku transakcji wymagających poufności, ale może być używana w przypadku tych ostatnich, w których certyfikaty o wyższym poziomie zapewnienia są niedostępne.

  2. Podstawowa

    Ten poziom zapewnia podstawowy poziom bezpieczeństwa w środowiskach, w których istnieją zagrożenia i konsekwencje naruszenia danych, ale nie są uważane za istotne. Może to obejmować dostęp do informacji prywatnych, w których prawdopodobieństwo złośliwego dostępu nie jest wysokie. Zakłada się, że na tym poziomie zabezpieczeń użytkownicy prawdopodobnie nie będą złośliwi.

  3. Średni

    Ten poziom jest istotny dla środowisk, w których ryzyko i konsekwencje naruszenia bezpieczeństwa danych są umiarkowane. Może to obejmować transakcje o znacznej wartości pieniężnej lub ryzyko oszustwa lub związane z dostępem do informacji prywatnych, w przypadku których prawdopodobieństwo złośliwego dostępu jest znaczne.

  4. Wysoki

    Ten poziom jest odpowiedni do użycia, gdy zagrożenia dla danych są wysokie lub konsekwencje awarii usług zabezpieczeń są wysokie. Może to obejmować bardzo wysokie wartości transakcji lub wysoki poziom ryzyka oszustwa.

Generowanie i podpisywanie klucza bezpiecznego rozruchu przy użyciu modułu HSM (przykład)

Wskazówki dotyczące walidacji interfejsu UEFI i ROM opcji

Omówienie bezpiecznego rozruchu

  • Last updated on